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, but we often gloss over compliance issues during high-level checklist security audits.
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 HIPAA Security Rule requirements are very clear as well:
The GLBA Safeguards Rule is a little more vague, but audit logging is implied:
The Sarbanes-Oxley Act, section number 404, is even more vague, but again, audit logging is implied and assumed:
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 sens
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
itive 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 kbeaver@principlelogic.com.
