While the Sarbanes-Oxley Act of 2002 identifies financial reporting requirements, it does not define how to comply technically with respect to IT security. Specifically it does not identify the need for event log analysis as fundamental to compliance.
However, the IT Governance Institute has published an IT compliance interpretation of the Act called "IT Control Objectives for Sarbanes-Oxley," which does identify log analysis as one component of compliance.
The business and liability significance of event log analysis
Log analysis is simply reading and interpreting the logs that are automatically written by file servers (financial, engineering, etc.) and by security devices (firewalls, intrusion detection, anti-virus, etc). The servers constantly write to their logs significant events, much as the captain of a ship writes to the ship log significant events that occurred on his ship.
In the context of information security, event logs identify actual and potential security vulnerabilities. The significance of this security information is widely recognized by recognized security experts. For instance, detailed log analysis is prescribed in the certification training literature authored by best practices security organizations such as ISC2 (International Information System Security Certification Consortium, Inc.) and ISACA.
On a practical level, the two most revealing sources of security risks to a computer network are:
- Alerts (warning messages) created by security device (firewall, intrusion detection, anti-virus, etc.)
- Description of security events identified in logs of both file servers and security device logs.
The business driver for reading and analyzing these logs is obvious: gleaning information which can be used to minimize the liability associated with an existing or pending security breach.
Why logs are often ignored
The reader would conclude and perhaps erroneously perceive that daily reading and analyzing server logs, which are readily available to all IT departments, would be a foregone conclusion. Reality differs from perception in this case.
Logs are lengthy, detailed, boring documents, which are tedious to read. The reader must be able to interpret the significance of log messages with respect to information security, and then must create a list of remedial actions to deal with security vulnerabilities. An analogy to this task would be to read every classified add in multiple newspapers, on a daily basis, to understand the significance of all the content, and to create a resulting task list.
By comparison, it is far more palatable for an IT security department to receive and interpret clear alerts from security devices, and to act upon these alerts. Unfortunately, this process ignores a very significant portion of security intelligence, and does not serve the best interests of the corporation (or the "issuer" in the case of Sarbanes – Oxley compliance).
SOX security infrastructure compliance: statutory vs. practical implementation
Log analysis is understandably imperative for SOX compliance, particularly because financial data resides on financial servers. Not reading the logs of these financial servers is analogous to a doctor not bothering to read a medical report for the latest diagnostics performed on a patient, where the patient is a litigator.
While the SOX Act refers to internal controls with respect to compliance in Section 404, the act is not prescriptive in terms translating the goals into a technical process. However, the IT Governance Institute has published the document entitled "IT Control Objectives for Sarbanes-Oxley," (referred to as the Controls Document) which specifically details how to comply with SOX from a security implementation perspective.
Log analysis for SOX compliance
While the Controls Document covers a wide range of security issues, the scope of observations of the Control Document are restricted to issues of log analysis.
The Controls Document refers to the necessity of regularly parsing logs in order to enforce compliance, specifically to:
- Identify security vulnerabilities.
- Ensure the existence of audit trails.
- Ensure adequate evidence for forensic investigation.
- Preserve the ability to reconstruct incidents.
References to specific sections entries are identified below by (electronic) page number and by the actual reference wording.
- Page 65. Determine if an audit trail exists of all emergency activity and that it is independently reviewed.
- Page 72. IT security administration monitors and logs security activity, and identified security violations.
- Page 74. Review a sample of problem or incident reports, to consider if the issues were addressed (recorded, analyzed and resolved) in a timely manner.
- Page 74. Determine if the organization's procedures include audit trail facilities--tracking of the incidents.
- Page 74. Review a sample of problems recorded on the problem management system to consider if a proper audit trail exists and is used.
- Page 77. System event data are sufficiently retained to provide chronological information and logs to enable the review, examination and reconstruction of system and data processing.
- Page 77. Determine if sufficient chronological information and logs is being recorded and stored in logs, and it is useable for reconstruction of system if necessary. Obtain a sample of the log entries, to determine if they sufficiently allow for reconstruction.
It is abundantly clear that the Controls Document indicates the need for analyzing and retaining logs as a requirement for compliance with SOX.
Methods of log analysis
A large issuer could have hundreds or thousands of servers, 10 security devices, and 30 financial servers, all with logs. Not all the server logs are necessarily candidates for SOX compliance. For an example analysis, 30 financial servers, 10 security devices, and 10 routers 6will be considered as requisite candidates for log analysis. There are three ways to implement log analysis, as described below.
Several IT security specialists are tasked with reading the logs of all servers on a daily basis. This task requires typically ½ hour per log, so reading and analyzing 50 logs (logs of 30 servers, 10 security devices, and 10 routers) would require at least 25 hours, or at least 2.5 person-days per day of IT security specialists. Since it is impossible for any person to spend more than a few hours analyzing security logs, a team of specialists would be required to handle this process.
First year ballpark cost: $250,000 USD (Assuming the use of at least 7 IT security specialists, average annual salary of $80,000, average of 200 events per log, ½ hour to review each log, and logs are reviewed daily)
Time to implement: Immediately
- Employee turnover likely to be about 100%.
- Error prone due to the tedious nature of the process.
- A minimum of six IT security specialists would be required.
Purchasing technology to automate log analysis
Several US suppliers of log analysis and event correlation technology exist. An in-house solution can certainly be developed using purchased software licenses for the technology. A complete implementation requires hardware platforms for the log analysis software, training for end-users who will implement and run the technology, possibly on-site consulting from the technology manufacturer and at least one person-time for the first year, to manage the system.
First year ballpark cost: $425,000 - $500,000 USD (Assuming price of software license for a best of breed technology, associated hardware to support the example configuration, plus one person dedicated to run the service for the first year.)
Time to implement: Months – year(s)
Downsides: Log analysis and correlation technology is sophisticated, requires much training, and can be very difficult to implement.
Outsourcing a Service for Log Analysis
Vendors offer the turnkey service, with the benefits of the issuer not having to purchase any software licenses or hardware. The prices may be based upon a monthly fee plus a one-time implementation.
First year ballpark cost: $180,000 USD (Price based upon estimates from ERE Information Security (owned by the author).
Time to implement: 2 weeks.
Downsides: Ongoing expense.
Budget burden: CFO's SOX budget vs. IT security budget
Even with the advent of SOX, log analysis is still not usually found as a budget item in the IT security budget. Expense and difficulty of implementation are usually the reasons given by IT security management for this situation. Specifically the IT security department typically can not cost justify with an ROI analysis their budget requirements, and are usually operated under-funded. Log analysis falls off the radar of critical needs.
However, with CFOs and CEO facing potential imprisonment and onerous fines (section 8.01 of the SOX Act provides for remedial actions of imprisonment and financial penalties) as penalties for non compliance with SOX, the SOX compliance committee is well advised to provide funding for log correlation. Funding from outside of the IT security department for log correlation allows the issuer to meet two critical business needs: compliance with both SOX and with best security practices.
Log analysis is a fundamental requisite of a sound IT security process. This tedious activity nonetheless should be moving onto the radar of financial executives who are personally accountable responsible for SOX compliance. Even if IT security does not request budget for log analysis, the SOX compliance or CFO should give strong consideration to tabling the need for, and funding the process of log analysis.Ron Lepofsky is the President and CEO of ERE Information Security, who are information security and financial disclosure / privacy compliance auditors.
The wording of the SOX act may be found at http://financialservices.house.gov/media/pdf/H3763CR_HSE.PDF A summary of the Act may be found on the AIPCA web site at http://www.aicpa.org/info/sarbanes_oxley_summary.htm