When it comes to audit logging, have you ever wondered what it takes to meet all the regulatory compliance requirements? This is something that's on a lot of network administrators' minds,
Does the fact that audit logging is enabled satisfy all the different regulatory compliance requirements? More importantly, do you enable audit logging enough to satisfy your organization's business needs and keep security risks at a minimum? In all but the most generic cases, the clear answer to this is no.
The majority of the Windows environments I've come across have some sort of security audit logging enabled. Certain logs are even generated through default installs of Windows. The problem is no one looks at these logs unless something bad happens. Unless you have a log management system such as GFI Software's EventsManager or the applications offered by TNT Software, you will never have enough downtime or be bored enough to consistently and proactively stay on top of things. But that doesn't matter. The expectations and requirements created by various government bodies and industry oversight groups are still here.
When it comes to most of the big regulations, there's certainly a lack of specifics, but audit logging is implied.
- The PCI (payment card industry) Data Security Standard is extremely clear and is security logging at its finest (if not overkill):
- "Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user."
- "Implement automated audit trails for all system components to reconstruct the following events…"
- "Record at least the following audit trail entries for all system components for each event."
- "Synchronize all critical system clocks and times."
- "Secure audit trails so they cannot be altered."
- "Review logs for all system components at least daily. "
- "Retain audit trail history for at least one year, with a minimum of three months online availability."
The HIPAA Security Rule requirements are very clear as well:
- "Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports."
- "Implement policies and procedures that, based upon the entity's access authorization policies, establish, document, review and modify a user's right of access to a workstation, transaction, program or process."
- "Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes."
- "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."
The GLBA Safeguards Rule is a little more vague, but audit logging is implied:
- "Detecting, preventing and responding to attacks, intrusions or other systems failures."
- "Design and implement information safeguards to control the risks you identify through risk assessment, and regularly test or otherwise monitor the effectiveness of the safeguards' key controls, systems and procedures."
The Sarbanes-Oxley Act, section number 404, is even more vague, but again, audit logging is implied and assumed:
- "State the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting."
So, where do you start? The only way to really know what needs to be logged and then subsequently protected and retained long-term is to perform an information risk assessment. What do you log? Do you look at successes and failures? How vulnerable are your logs once they've been written? How long do you keep your logs? Only you can answer those questions.
Look at the sensitive information and computer systems that apply to one, if not all, of these regulations and determine what's really at risk and what's urgent enough and important enough to focus your money and effort on. Try to look at a high enough level, one that allows you to enable logging to the point where you're reasonably complying with all the requirements.
Remember that logging doesn't have to be expensive. In fact, there are plenty of free logging tools, including the ones that Microsoft puts right inside Windows. For example, with Windows Server 2003 and above, logon events are logged by default. With Windows XP, audit logging is disabled by default, but you can still create and push out GPOs and configure any standalone systems manually.
With all the security built into Server 2003 and Vista, it's easy to assume that the default logging settings are sufficient. Don't be fooled -- they're not. It's not Microsoft's responsibility to tell you everything that needs to be logged. It's going to be up to you and (hopefully) your compliance or IT governance committee to determine what else needs to be enabled and monitored. You may also want to enable auditing of policy changes, privileged use and system events. Before you decide to log everything to its fullest extent, know that this can and most likely will bring Windows to its knees (especially on servers) given the processing and disk I/O requirements of logging everything.
As with a lot of IT and security purchases, you get what you pay for. Keep that in mind when it comes to trying to manage all of your security logs across all of your systems day in and day out. You won't go wrong with commercial log management tools and even the more advanced event correlation and security information management tools such as IBM Netcool/NeuSecure, CA eTrust Audit log repository and ArcSight Enterprise Security Manager.
Be conservative, but make informed decisions along the way. Don't start logging for the sake of logging or buying expensive tools for their coolness factor. Also, don't go into this with the goal of appeasing your auditors or simply complying with what the industry and government regulations say. You've got to do what's right for the business based on what risks you've discovered.
The most important thing to remember is that there is no right answer -- no one-size-fits-all solution -- to audit logging that will help you across the board. Deciding the what, when, why and how of audit logging is a critical business decision. Go ahead and bring in other people to help decide what's right -- such as your compliance manager and legal counsel. In the end, you don't want to be stuck holding the bag.
Audit logging is not just for compliance reasons. For better or worse, it helps with incident response and legal discovery, too. A good resource to get you rolling without having to design a new wheel is NIST's Guide to Computer Security Log Management.
About the author: Kevin Beaver, an independent information security consultant and
expert witness with Atlanta-based Principle Logic LLC, has spent six long years obtaining his degree in computer
engineering that included Blue Pill-like bit and byte manipulation. He has more than 18 years of
experience in IT and specializes in performing information security assessments for compliance and
IT governance. He has written six books including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy
and Security Compliance (Auerbach). You can reach him at
This was first published in December 2006