APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Audit Logging

2007/03/21
by Michael Desrosiers

This month's topic is about log monitoring in today's compliance regulated world.

When it comes to audit logging, have you ever wondered what it takes to meet your regulatory compliance requirements? This is a subject that is on a lot of CIO and Network Administrators' minds, but we often overlook this issue during the initial checklist of a security audit. Does logging satisfy all the different regulatory compliance requirements, or is log monitoring in enough detail acceptable for your organization's business needs. Does this practice assist in keeping your security risks to an acceptable level? In most instances, the answer is no.

The majority of the Windows infrastructures I have come across have some form of security audit logging enabled. Certain logs are even generated through the default installs of Windows operating systems themselves. The problem is no one looks at these logs unless something bad happens. Unless you have a log management system, you will never have enough downtime to consistently and proactively stay on top of your logs. The expectations and requirements created by various government bodies and industry regulatory groups are here to stay. When it comes to the major regulations, audit log monitoring is a necessity.

PCI DSS (Payment Card Industry Data Security Standard) is extremely clear and precise about security logging with the following:

1) Establish a process for linking all access to system components, especially access done with administrative privileges such as root, to each individual user;
2) Implement automated audit trails for all system components to reconstruct events;
3) Synchronize all critical system clocks and times;
4) Secure audit trails so they cannot be altered;
5) Review logs for all system components at least once a day;
6) Retain audit trail history for at least one year with a minimum of three months availiable online.

HIPAA (Health Insurance Portability and Accountability Act) Security Rule requirements are very clear as well:

1) Implement procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports;
2) Implement policies and procedures that, establish, document, review and modify a user's right of access to a workstation, transaction, program or process;
3) Identify and respond to suspected or known security incidents and document security incidents and their outcomes;
4) Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain health information.

GLBA (Gramm-Leach-Bliley Act) Safeguard Rules are a little more vague, but log monitoring is still implied:

1) Detecting, preventing and responding to attacks, intrusions or other systems failures;
2) Design and implement information safeguards to control the risks you identify through risk and security assessments, and regularly test or otherwise monitor the effectiveness of your key controls, systems and procedures.

SOX (Sarbanes-Oxley Act) section number 404, is even more vague, but again, monitoring is implied and assumed:

1) State the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.

So, where do you begin? The only way to really know what needs to be logged and then subsequently protected and retained long-term is to perform an information technology security 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 the process from the 30,000 foot level, one that allows you to enable your logging to the point where you are complying with all the requirements, but the business is not suffering from it. Remember that audit logging does not have to be expensive. In fact, there are plenty of free logging tools, including the Microsoft Windows logon events that are logged by default.

With the logging that is built into Windows, it is easy to assume that the default settings are going to be sufficient. I am here to tell you, it is not Microsoft's responsibility to tell you everything that needs to be logged. It's going to be up to you and your organization 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 a crawl given the processing and disk requirements. As with a lot of IT and security products, 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 on a daily basis. You may need to implement a commercial log management tool or the more advanced SEM (security event management) or SIM (security information management) suites, to perform log aggregation and correlation. Make prudent and informed decisions along the way. Don't start logging for the sake of logging or buying expensive software just because it cost a lot of money. You have got to do what is best for your business based on what levels of risks that you have discovered and are willing to assume. There is no correct answer to log monitoring that will help you across the board. Deciding the what, when, why and how of audit logging is a highly critical business decision. Go ahead and bring in other people in your company to help decide what's right, including your Compliance Officer and Legal Counsel. This has to be an organizational decision.

There you have it. Log monitoring is not just for compliance reasons, but it will help with incident response and legal discovery as well. A very good resource to get you rolling without having to design a new process, is the NIST's Guide to Computer Security Log Management and it can be found at:

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

To respond to this or previous newsletters or to inquire about an on-site presentation, please feel free to call us at 508-995-4933 or email us at [email protected]



Got something to add? Send me email.





Increase ad revenue 50-250% with Ezoic


More Articles by © Michael Desrosiers



Kerio Connect Mailserver

Kerio Samepage

Kerio Control Firewall

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





The danger of computers becoming like humans is not as great as the danger of humans becoming like computers. (Konrad Zuse)

If we define Futurism as an exploration beyond accepted limits, then the nature of limiting systems becomes the first object of exploration. (Frank Herbert)












This post tagged: