by Michael Desrosiers
This month's topic is about log monitoring in today's compliance regulated
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
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
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
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
If this page was useful to you, please help others find it:
More Articles by Michael Desrosiers
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. We appreciate comments and article submissions.
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.