Are you ready for your audit?

Below I give some results from this column's first survey. After doing a search of the comments you entered, I find not one mention of security audits. Then why am I forging on with the security audit as the major topic of this month's installment?

No, it's not to antagonize you into breaking into my system. Rather, it's because security audits are important. I also hope to show you that a formal name (like "security audit") doesn't necessarily indicate a formal procedure. In fact, you may already be doing security audits, but in the name of poking around.

There are three pieces to a successful audit. You need to have

• A plan, ranging from a formal document to notes on the back of an envelope, listing what aspects of the system you're going to evaluate, and how.



• Tools, consisting of notes, books, unix commands, your own applications, public-domain security-checking programs, or commercial applications.



• Knowledge, of how to interpret the results of the audit and what changes to make.

The Plan

The detail and content of the plan depends on your needs. For instance, when I was in a university environment we had no formal plan. Rather, we had a set of system aspects we evaluated, and this set grew as the faculty decided to be more security conscious. The plan in this case was a set of scripts and cron jobs, tied to the quality and utility of the tools that were available to us.

An example of an informal plan for a security-conscious but not security-inhibited site could be:

• Consider the types of security problems we could have.



• Consider which ones we can and should fix or detect.

After due consideration of these aspects, you might expand the plan to include security steps you decided were prudent in the current circumstances. Adding information on why you decided to take those steps can help later when circumstances change or you need to reevaluate policies based on the reaction of your user community:

• Make sure users choose good passwords. Reason: We run NIS, which can allow users and outsiders to get hold of our password file. We should assume the passwords are in enemy hands and make sure they aren't easily breakable.



• Make sure the root password is even better. Reason: The root password is the most tempting one to break. We also have nosy users who may try to "shoulder surf" the password as we type it, and we need a password not easily discerned.



• Keep up with security patches and CERT advisories. Reason: Our systems are on the Internet, and security hole information is easily available there. We should fix known holes before they are abused.



• Scan the system for known holes, bad permissions, changing system files, and errors in configuration files. Reason: It's a good way to watch over the system without expending a lot of time and money. We'll use the COPS tool for this.

A note on policy and mechanism: Computing professionals know that it's a bad idea to tie together the policy and the mechanism, as is done in this case. Our policy was limited by the mechanism (tools) we had on hand or felt like writing. More formal policies demand a separation from the method. The policy is decided first: User passwords will be changed after thirty days. Next, the policy is implemented through public-domain, commercial, or custom code.

A site more concerned about security may have a more formal list. For instance, when I perform a security audit for a commercial site, I talk to the client about:

• Privacy of data (user and system) -- What data can be read, what can be written?



• Data integrity -- What can change key data?



• System availability -- What can disable system access and resource use?



• Change control -- How can changes be made?



• Isolation -- How can the system be accessed?



• Physical security -- Is the machine, network, or site physically secure?



• Audit -- How are changes tracked?



• Accountability -- Can problem causers be located?

Based on discussions around these topics, a more detailed plan can be developed. In these discussions, tradeoffs are determined, priorities decided, and the overall installation considered. For example, the client could improve physical security to the machine room, but people needing direct access would be inconvenienced. And because the system is on the Internet and no firewall is installed, the client must weigh the risk of an internal attack against that of an external attack. Perhaps both security problems need to be fixed, perhaps internal risks are less important. The result of this analysis is a firm set of goals, a way to judge success of the audit and any resulting security improvements, and knowledge of what kinds of tools are needed to do the job.

The Tools

Having the right tools available makes a job easier. Finding the right tools on the network can be a bit of a challenge, however. This list will be expanded over time (send in those suggestions!), but should get you started. Besides, it's a good excuse for surfing the net...

Password checking and cracking:

• npasswd Password security at password change time.
• Crack A compute-intensive password cracker.

Checking your systems for security problems:

• COPS A system security scanner.
• Tripwire A system file checksum verification package.
• SATAN A network security analysis tool (requires Perl 5).

Protecting your systems and networks:

• tcp_wrappers Provides a layer of security between your tcp-based network daemons (telnet, ftp, et al.) and those who connect to them.
• TIS A security company which provides a the free TIS firewall toolkit.
• The firewall mailing list Discussion of firewall-related issues.

Pointers to more information:

• CERT The Computer Emergency Response Team's documentation, tools, and pointers.
• Unix security information with lots of other pointers.
• BUGTRAQ Unix bugs mailing list, how to exploit them, and how to fix them.
• Yahoo A search engine with a large set of security links.
• Gene Spafford's Hotlist Contains pointers to all sorts of security related information.
• comp.security.announce newsgroup.

The Knowledge

Last month I mentioned our hypothetical and clueless user Bob. A system can be physically secure, have all known patches installed, have an up-to-date and reasonably secure operating system, and be constantly monitored. But, without knowledgeable systems staff, and knowledgeable users, the system's security will always be suspect. User Bob could mail the password file to an outsider, simply because he didn't know it could do any harm. Similarly, users can import code that contains worms or viruses (on PC's anyway) and cause problems.

Systems staff need knowledge, of course. But in this group you must include everyone who knows the root password. One slip of the keyboard as root can cause immeasurable damage to the system. Perhaps this person installs a new package as root and allows it to create an insecure setuid program. Or grants a user request to make the user's program setuid root. Holes can be introduced in more innocuous ways as well. The wrong option to the share command can export a file system to more systems than intended. A poorly chosen root password can give easy access to unwanted visitors.

How do you impart the base knowledge to users, staff members, and root-folk? That's the age-old struggle. Standard, easy-to-understand, short documents are the best way that I've found. Give you users a list of do's and don'ts. If you can, make everyone who knows the root password read and understand some simple guidelines.

Security is a complex issue, so even if you're well-versed in security procedures and knowledgeable about security holes, break-in methods, and tools, you still need to keep learning. New versions of operating systems can contain new holes, old holes can be discovered, and of course there's always sendmail to keep you busy.

Beyond these skills is another realm, another level of security existence. This one is born of experience, understanding of your environment, and a feeling for your users. At this level you consider which problems to solve and which to leave alone based on the context. If solving the problem will inconvenience users, the cost of someone exploiting the problem must be weighed against user time lost (and time you may lose), and the risk that users will implement a workaround if they are really put out. By forcing users to change passwords every month, you may encourage them to write down the password (and stick it to their workstations).

You may also waste time implementing software or policies that add nothing to the overall security. I find it useful to have an acid test in mind. For example, most environments have exposed network connectors and standard Unix network authentication (NFS with no NIS+ or secure RPC). Any user can bring in a PC, connect it to the network, and access any other user's files. The acid test in this case is asking yourself whether making a change would decrease or increase security in this circumstance. It's a very nice razor for splitting security decisions into to groups: changes to make and those which make no sense.

Viewer Mail

There were some interesting results from the first reader survey of this column, and some obvious ones:

• 94.% percent of you are worried about the security of your computer systems and networks.



• 41.8% of you know your systems have, at some point, been compromised.



• An impressive 81.% percent would admit that you had an intrusion.



• A surprising 45% or you feel the greatest security threat comes from inside your organizations.



• Most organizations are "somewhat concerned" while most of you people are "very concerned" about security.



• Finally, most sites have taken the precautions of lecturing users about passwords, installing security-related OS patches, and using SATAN or COPS.

Thanks for all the feedback, and be sure to fill out this month's survey!

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

Next month we'll look at the Security Plan. The Plan starts from the results of your audit. Based on the audit, you may want to proceed with changes. What changes should be made? Well, it depends on the level of security that's appropriate for your environment. The plan is your tool for determining where you want to go, and how to get there.

Sorry I didn't have "room" this month, so next month, we really will start the canonical security reading list, and will start the security-bug-of-the-month club. Stay tuned!