What's the Plan? Get a grip on improving security through a Security Plan

September  1995

Last month we examined the security audit as a tool for determining the security state of your system. This month we will take the next step and plan actions based on those findings. The actions range from the minimal ("everything is fine") to the extreme ("unplug and spend a lot of money"). How can you determine the right course for your site? (1,500 words)

Also in Pete's Wicked World this month: the cornerstones of the security reading list and our first bug-of-the-month.

Mail this article to a friend

The security of your systems should not be taken lightly. A well thought out plan will help you reach your security goals. You need to determine, either formally or informally, the level of security you want to achieve and then plot a course of action. Your plan can simply be to maintain the status quo, but after auditing your systems that's not likely to be the case. Perhaps you'll decide to educate users, close known security holes, install a firewall, or revamp your entire installation. A plan is the first step in this direction.

The good news is by doing a security audit you have already implemented phase 1 of the plan (if you haven't performed an audit, consult last month's column). During the audit the need was for documenting your system configuration, deciding what aspects to examine, and performing the necessary evaluation. Now the plan can be expanded to include the findings of the audit and the important decisions made based on those results.

Let's start our plan by considering the issues raised last month. How do each of these relate to your environment? If one is a non-issue, just ignore it. Reduce this list to the set of problems you need to address at your site:

• Privacy of data (user and system) -- What data can be read, what can be written?
• Data integrity -- What (and who) can change key data?
• System availability -- What can disable accesses to systems and resources?
• Change control -- How can changes be made?
• Isolation -- How can your systems be accessed?
• Physical security -- Is the machine, network, or site physically secure?
• Audit -- How are changes to systems tracked?
• Accountability -- Can problem-causers be located?

For each pertinent item, describe the current system state and the goal. Next month we'll look at the tools that could be used to reach that goal. There is an aspect of system changes that is sometimes overlooked: how changes will effect users. Once I have a set of problems and possible solutions, I try to get buy-in from the user community. Given the current state of computer security, users unhappy with restrictions being forced on them can find ways around them. Consider workers who put Post-it notes containing their passwords on their machines. Or the users that share an account because the system policies won't let them share files between accounts.

The more users are educated about a decision and the more input they have, the more they'll help -- rather than hinder -- your efforts. Have a meeting or circulate a memo describing:

• the issue and why it's an issue,
• the change you're advocating and the reasoning behind it,
• how it will affect users (more complicated login process, more paperwork, loss of features, loss of convenience),
• any options available to users in solving the problem.

Of course such an approach is not always possible, but in environments where it is feasible, it can prove invaluable.

For each of the above issues, consider your options:

• Leave it alone. In some cases you'll decide to make no changes. It's still useful to have a plan so you know why you decided to maintain the status quo and so you can determine if those circumstances have changed. For instance, you might not have been on the Internet when you wrote the plan, but are now.

• Educate users. The problem was that people didn't know when they were compromising security. Teach them and they (hopefully) won't cause the problem in the future.

• Fix the problem. If a problem in a given area was uncovered by the audit, fix it, document the fix, and monitor the fix.

• Get active. If the issue is an important one, for instance privacy of data on a payroll system, instrument the system so you'll know about problems as they occur. Install traps, monitors, firewalls, scanners, and perform periodic audits.

With the audit and plan done, you know the current state of your site and the goal. With the proper tools and knowledge, the site security can be improved to meet the goal.

SUBHEAD Bug of the Month Club

The bug-of-the-month club covers security bugs that you may need to know about. This month's victim is the crash command on all versions of Solaris 2. crash is a program that helps analyze system memory images of running or crashed programs. crash, out of the box (or off the CD, really) is setgid sys. That is, its group has the setgid bit set, as shown by an "s" in the permissions field of ls -l output. The result is that when crash is run, it elevates the users to be a member of group sys. Unfortunately, the kernel memory devices /dev/mem and /dev/kmem are readable by group sys. The net result is that crash can be used by any user to read from the kernel's memory.

Reading kernel memory is a security hole because user passwords are stored there while they are typed, chunks of kernel memory hold program text and data blocks, and network packets are buffered in kernel memory as well. Hackers could use the information gained through crash to gain considerable information about your system.

To solve this problem, use chmod to remove the setgid bit from the executable (in this case, on machine mickey):

mickey# chmod g-s /usr/kvm/crash

SUBHEAD The Bookstore

Security, perhaps more than any other system-administration area, is rife with books. This is a good thing because, as it turns out, there's a lot to know about security, from a lot of angles. I've read some, skimmed more, and avoided a lot. Feel free to send me the names of any that you feel are worthy, and I'll add 'em if I like 'em. Here is the start of a list of books you should consider adding to your library:

• Computer Security Basics by Russell and Gangemi Sr. (O'Reilly and Associates, 1992) is a very nice introduction to the topic for the novice. It's substantial enough to have on your bookcase even beyond the growing years. Useful information includes a list of acronyms and explanations of how DES, RSA, and the like work. The book is a bit dated, especially the section on computer law. It is also weighted toward government facilities, with loads of information on the Government's Orange Book security standard and Government security tools.

• Practical Unix Security by Garfinkle and Spafford (also from O'Reilly, 1991) is also a little out of date. A new edition is in the offing. This book runs the gamut from password vulnerabilities and policies, through Unix permissions, dangerous accounts, and log files, to modems, network security, NFS, and firewalls. The last section on handling security incidents is especially valuable.

• Firewalls and Internet Security by Cheswick and Bellovin (Addison Wesley, 1994) is currently the word on firewalls. It covers the various types of firewalls, and why you'd want one or the other kind. It also describes the types of attacks that might be thrown against your systems, and the tools hackers may use. It ends with a list of tools and sources for the tools. I'm especially fond of my copy because I met Bellovin at a conference and he digitally "signed" it with his PGP (Pretty Good Privacy; there are two FAQs: one on how to get it and one that chronicles the PGP saga) signature. The reason I say it is "currently" the best book is that firewall guru Brent Chapman has a firewall book coming due from O'Reilly at any moment. I'll let you know what I think of it soon.

Next Month, on "As Pete's Wicked World Turns"

Next month we'll delve into the tools available to help secure your systems, including a detailed look at several of them describing what they are good for and where they fall short.

Resources

• Tiger
  ftp://net.tamu.edu/pub/security/TAMU/ Computer Security Basics http://www.ora.com/gnn/bus/ora/item/csb.html
• O'Reilly and Associates
  http://www.ora.com/ Practical Unix Security http://www.ora.com/gnn/bus/ora/item/pus.html
• Addison Wesley
  http://www.aw.com/
• How to get PGP
  ftp://ftp.csn.net/mpj/getpgp.asc
• The PGP saga
  ftp://ftp.prairienet.org/pub/providers/pgp/pgpfaq.txt

About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a new Systems Integrator. He is also Systems Manager Emeritus of the Computer Science Department at Brown University. As a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at peter.galvin@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-09-1995/swol-09-security.html
Last modified: