Are you ready for your audit?
A security audit by any other name would not be so intimidating
Before you can begin securing your systems and networks, it's a good idea to know how secure they are currently. The security audit is a powerful tool to this end. As forebodingly-formal as it sounds, the audit can be your friend. Be sure to give us feedback, this month's questionnaire is focused on audit readiness.
Welcome back to Pete's Wicked World. The topic this month is the security audit, and I hope to show you why it's a topic you should care about. Also in this episode is an extensive set of pointers to useful security information on the net. Finally, we have our first taste of viewer mail as I share the results of last month's reader survey.
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
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:
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:
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:
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.
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:
Checking your systems for security problems:
Protecting your systems and networks:
Pointers to more information:
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.
There were some interesting results from the first reader survey of this column, and some obvious ones:
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! And don't forget to fill out this survey focusing on your audit readiness.
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 firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com