Spam: SPF and Grey Listing Analysis
Author: Jerry Benton

Why Audit?
Having the ability to step back and examine oneself is truly a unique quality.  It doesn’t take an expert in psychology to realize people side with themselves when it comes to their actions and have a hard time admitting when they are wrong. Combine this with the fact that some people are less than honorable, everyone makes honest mistakes, and the world changes and you have more than enough reason to audit your computer systems. The sole purpose behind auditing anything is to make sure that things are the way they are supposed to be and this is not different when it comes to information technology.

Who Audits?

Most everyone that has worked in information technology for a long period of time has more than likely seen some sort of audit. However, there are many people that have worked in the field for decades that have not ever seen an audit. The push to audit usually doesn’t come from the IT department, but rather management. Of course, a good information assurance analyst will recommend to management that an audit of IT systems should be done on a reoccurring basis, but there is always a hitch: auditing costs money. It doesn’t matter if the auditor is an organizational resource or a third party, either way it is going to directly have a financial impact or indirectly have an impact through hours dedicated to the project. The end result is that auditing is often not done for very long periods of time or just totally ignored.

With the common scenario outlined above, a system of checks and balances through auditing is frequently going to be left those that administer the assets on a daily basis. However, this does present the dilemma of being honest with oneself. It’s hard to do sometimes, but just keep in mind that you’ll be the only one that knows if you do find a mistake when auditing yourself. Of course, that’s only until someone farther up the food chain does decide to do an audit one day. That’s where being tough on yourself will pay off.

Auditing yourself isn’t as hard as you may think. The absolute best way is to keep a record of everything you do on a system. However, this can become a real time sink and actually end up taking more time that the actual work. Combine that with the fact that some people (like me) are just lazy when it comes to this type of thing and the result can be a half-baked record of events. I’ll jump to the exciting part and just state that automating your record keeping as you go is the fastest and easiest method to keep a trail that can be examined at a later date if required. And the best part is that it isn’t hard.

Lazy is Key
When I first started my endeavor into that deep dark abyss known as the Unix command prompt, a great man taught me that “lazy is key”. And the more I work on enterprise systems, the more I whole-heartedly agree with him. When I build any system, automation (laziness) is absolutely key for me to be able to take vacations and actually be able to spend my entire weekend not at work. And since no one to date has ever come behind me to audit my work, I have found it necessary to audit myself.

To accomplish my self-audit I take a handful of simple steps. The first step is fully document my project. Although this step’s primary goal is to give my replacement some sort of clue in the event that I get hit by a bus or win the lottery, it does serve as a good baseline in case I need to revisit things a year down the road. The second step I take is to log everything I do. Considering my signature is no more than a squiggle these days because I am too lazy to sign my entire name, I had to come up with a system to log my work. The easiest solution for me was to turn on logging whenever I am connected to a system I am making modifications to. When I am finished I name the log file SystemName.Date.Time.log and squirrel it away on my workstation. This gives me not only a record of what I have done, but also a guide in the event I have to undo a “bad thing”. The third step is to make automated backups for both disaster recovery and rollback. And finally, I make sure that patches are applied in a timely manner and logged. However, I do deviate from the “lazy is key” philosophy of life for patches because patches can break things. Patches should be done manually on critical systems and logged after being tested on a lab system if you have the resources.

Power Curves
Whenever you learn something new there is going to be a power curve associated with the experience. For example, I am typing this essay on a brand new Macintosh computer that I just bought yesterday. This is my first experience with this platform and it took me twenty minutes to figure out how to make a shortcut to the word processing program. Saving the file was also a new challenge. The result is that it has taken a significantly larger amount of time to be productive. This is not the situation you want to be in if you ever get audited. Know what you are doing before hand to avoid the “scramble dance” when the auditor management finally decided to hire shows up at your door.

How Not to Audit
Most audits I have been witness to in my organization are not audits at all. Most of them are nothing more than some clown showing up with a copy of Internet Security Systems’ (ISS) network scanner and running it against the network. Then the “consultant” will click print and hand me a pile of paper that outlines just how bad my network is. This is not an audit! Granted, the ISS scanner is a great tool for identifying issues, but is just one tool in the toolbox. Auditing is making sure that things work the way they are supposed to work. That involves human intervention. For example, one wicket on the audit list should be how your border router is configured and does it work in tandem with your firewall. You do have a firewall, right? That firewall is configured according to organizational policy, right? These are questions that must be answered by human intervention and not automated tools. Unless that tool can read organizational policy and translate the intent into a working network solution, it’s not really an audit.

Summary
A auditing is not an understood art when it comes to information technology. Could you imagine just running a computer program against the financial statements for an organization and calling that a complete audit? The Security and Exchange Commission wouldn’t buy that solution and neither should you for your network. Auditing is nothing more than making sure things are the way they are supposed to be. Although the intent is simple, executing a plan to meet that intent is not. And imposing a self-audit plan against your own work will pay for itself many times over if a real audit ever comes your way.

Back to Articles and Tutorials