As the last in the series of tips of the day, I chose the subject Audit.

Audits might sound scary as they verify your work, but they really should not. They can be a great tool into doing the right thing and catching (and correcting) errors before they escalate and become a problem. As a matter of fact, you can audit your own work. Or do it in a team. We all know we cannot find errors in stuff we wrote ourselves while it's obvious if somebody else wrote it.

Audit yourself/co-worker

You can do various audits yourself of your work:

• Are backups actually able to be read?
• Can we actually restore a backup from a system if we loose all the harddisks or are we missing information?
  
• Are the dates/sizes of system files on all our computers still the same (poor man HIDS, but it can also detect failed patches etc.)
• Do logs from all our systems actually end up in our central log repository?
• Did managment acknowledge all incident reports you gave them? Where there changes implemented due to the incidents?
• Do we have blocklists? Do we update them regularly? Did we check if they are still relevant?
• Exposed scripts (such as e.g. cgi-bin perl scritps)? Who reviewed them for security? Where they changed afterwards?
• Is everything you do documented, can co-workers understand it and take over your tasks?
  
• ...
  

Internal Audits

Internal audits can go further:

• Are all our users in our user database(s) still rightfully there? Does the list match with what e.g. HR has as list of employees/contractors? Are the other users interactively used? Are they regularly re-confirmed as needed users? Do we have users that never log in?
  
• Can we actually start a Disaster Recovery without touching the existing equipment and information?
• Do people inside the company know where to find security policies? Do they know key content of the policies? When were they last reminded of the password policy? Are all our policies easy to read? Are all our policies short enough to be read in under 5 minutes?
  
• Is equipement we rely on for being warned about problems (availability, IDS, logs, ...) actually tested regularly? How are we sure?
• Are policies overruled? Why? By who? How often? Was it investigated? Did the policy change afterwards to fix the problem?
• Where are incidents logged? What were the conclusions? Do people know incidents that were not logged?
• If you need to find more cool audit ideas, check ISO27001 (or  ISO17799) it has a bunch of ideas that you can test to see if you have it or not. Without a policy or guideline to get it, this isn't a real audit check as in must have, but it's always good to look for some extra credit to go beyond the minimum what is implied by the policies.
• Is the inventory complete? Are network diagrams up to date?
  
• Is every thing labeled? Do machines with possibly confusing port have labels added to identify the ports? Are cables labeled on both ends with both sides of that they connect?
  
• Are logbooks used and filled out? Or are they filled out just before the audit?
  
• ...
  

External Audits

Well external audits generally should check the same stuff as the Internal audits do, but be independent. Sill they are valuable as they can give you the ultimate magic bullet: management support.

Typically this starts with regulatory and legal requirements, but it can check compliance with standards as well.

• Can grant a seal of approval.
  
• These audits can also audit those persons that are very hard to audit as an employee: the big chief: does (s)he feel the policies do not apply to him/herself?
  
• ...
  

Many times this latter type of audit comes up with the dreaded "logs shall be reviewed".

• First of all: logs are huge. You do not want them to schrink in size.
  
• Computers are pretty good at finding things in large amounts of data - if you can tell them what to look for.
• The "what to look for" however is lacking in the "review logs" assignment

This results in the equivalent of telling people to search for something "interesting" in a stack of hay, but not telling them what's interesting. For all you know they find pieces of hay exactly 56.789mm long interesting, and they were not looking for the obvious needles.
As soon as you know what to look for, you can automate it in less time than you do it manually once.

So that leaves?

• Create logs, the more the better, they might be the only trace you have of an incident.
• Do NOT review it manually, it is pointless.
  
• Automatically look through them
  
• for known problems (you learn them from past incidents).
  
• for never seen before entries using e.g. Marcus Ranum's nbs (never before seen) script/db so when something absolutely new occurred you get a chance to consider it interesting enough to treat as an incident or not.
  
• Keep them for the right amount of time
• Look through them for evidence and further understanding once you have an incident to deal with. 
  

That leaves dealing with external auditors that never saw how big a log gets and demand manual reviewing of all logs. The best solution is to show them. Print a few boxes worth of logs out on an old printer, ask them to show you what to look for. And then propose to do it smarter.


--
Swa Frantzen -- Section 66