In the good old days, regulatory compliance management meant monitoring system logs manually on an ad hoc basis or as system problems required diagnosis and root cause analysis. Traditionally, an organization's IT department controlled the logs, using them for occasional troubleshooting and system performance checks and deleting them when they were no longer needed. In most enterprises, however, those practices have changed. Compliance audits spurred on by regulations like FISMA, HIPAA and the Sarbanes-Oxley Act have increasingly identified deficiencies in an organization's log analysis procedures.
Log analysis has become to security management what data mining has become to data management. Analyzing logs and mining data can reveal valuable information that might otherwise be missed. Analysts can spot patterns that may signal anomalies and connect seemingly worthless data to reveal something meaningful. Data mining is often used to reveal information that can be helpful for marketing purposes, however, whereas log analysis techniques yield information that may be a telltale sign of a security breach. Improved security information and event management (SIEM) systems offer compliance officers important new tools for meeting regulatory mandates.
According to NIST SP 800-92, most logs contain events that are of interest from a security perspective. NIST SP 800-92 also states that, "Routine log analysis is beneficial for identifying security incidents, policy violations, fraudulent activity and operational problems."
While ISO 27001 supports the National Institute of Standards and Technology's position within its own set of standards, The SANS Institute attempts to clarify the details of NIST SP 800-53 log management controls. In its "20 Critical Security Controls," SANS recommends the deployment of a SIEM system for the satisfaction of an advanced level of controls.
Outside of these mandates, automated security monitoring has now become a necessity for a variety of reasons:
- System infrastructure changes can inadvertently open security holes.
- Unauthorized access can drain precious information assets.
- Data leaks can go undetected for years.
When that guidance is coupled with increased public interest in an organization's ability to manage its information assets, it's clear that compliance and security officers have to do all they can to identify security incidents before they happen.
Compliance management through log analysis
Why does log analysis matter? Many security experts believe that log events (individual entries in a log) may contain information about security controls or security incidents must be collected and saved. Saving log events enables an organization to analyze information in the event of a security breach investigation or to reveal a malicious activity in progress. That's a great idea, as a majority of security breaches take years to resolve due a lack of digital evidence and an abundance of misleading clues.
On the other hand, collecting, analyzing, storing and protecting relevant log events that can easily grow to millions in a short period of time is not a task humans can easily accomplish manually. That's where SIEM systems come into play. SIEM systems are built around strong log analysis, correlation and management capabilities that vendors promise will deliver what traditional log management has not been able to: rapid, useful analysis of anomalies or incidents.
When implemented properly, SIEM systems are valuable tools in gaining visibility into an otherwise invisible world of system activities.
SIEM systems are designed to facilitate the centralized collection, analysis and storage of system logs from a wide range of infrastructure sources, including firewalls, routers, switches, servers and wireless devices. When implemented properly, SIEM systems are valuable tools in gaining visibility into an otherwise invisible world of system activities. In addition, these systems are designed to do the same for security-related events, like attacks on virtual private networks or attempts to access or corrupt stored data. As events are stored, they can be analyzed through methodologies like correlation analysis to derive trends and manifested or potential security threats.
This ability to conduct forensic analysis of such events is extremely appealing to security managers and compliance officers. For many administrators, it's harder to streamline current event and log management processes and easier to justify bringing in new solutions. Many organizations, perhaps swayed by marketing literature from vendors promising ready-made compliance, are rushing to deploying SIEM without conducting proper due diligence.
This state of affairs would be fine if the only objective were to keep compliance auditors at bay. If the objective is to change the organization's security posture, however, additional work is needed.
Implementing SIEM systems without first setting realistic goals and establishing measurable objectives is likely to cause an organization to claim that it's "in the process of deploying a SIEM system" for years to come. Installing a new system into your infrastructure that will touch upon almost every device requires planning as well as management's commitment to resources for acquisition, implementation, testing and training. Savvy security managers and compliance officers already know that obtaining a go-ahead from the executive office requires serious homework.
In the second part of the tip, I'll explain exactly what homework is required for setting realistic goals for successful implementation of a SIEM system.
Meenu Gupta, CISA , CISM, CISSP, CIPP, is president of Mittal Technologies. Gupta is currently consulting with several federal agencies, including the departments of Health and Human Services and Homeland Security. She is also an adjunct professor at University of Maryland University College, where she teaches information systems management. Let us know what you think about the story; email email@example.com. Follow @ITCompliance for compliance news throughout the week.
This was first published in February 2010