As a part of your organization's overall security posture, log retention should not be simply a box to check off.
With today's threat landscape, it is critical that you do not place too much emphasis on security tactics rather than security strategy. This holds true for all aspects of security from intrusion prevention to vulnerability protection and log monitoring. The following are five things to consider when developing a log management strategy that go beyond simply storing logs.
1. What is driving the need for log management at your company?
A log management strategy puts the emphasis on business priorities such as customer service, operations, legal protection and intellectual property. Developing a strategy starts with a list of the key drivers, or the reasons you need to collect, retain and monitor log data:
- Compliance requirements such as SOX or PCI
- Business objectives such as improving customer service or productivity
- Response requirements such as rapid remediation or customer notification
2. Identify the systems and applications that fall into the scope of monitoring efforts
The simplistic approach to log monitoring is to identify what can be captured easily and save it all. A strategic approach targets the scope and includes all systems and applications that will help monitor security events related to your key drivers. For example:
- SOX compliance requires log monitoring of financial statement and processing systems
- PCI compliance requires log monitoring on credit card processing and data storage systems
- GLBA compliance requires log monitoring on systems that store personal financial data
- HIPAA compliance requires log monitoring on protected systems that store personal health data
In addition to compliance requirements, the scope should include systems that are of high risk to the organization due to their intrinsic value, and systems related to intellectual property assets. Legal and compliance officers are often consulted during the data gathering process for this step.
3. Determine log monitoring retention and security requirements
Many regulations require retention of reasonable amounts of data for reasonable amounts of time, leaving interpretation up to security officers and auditors. Creating a matrix based on compliance as well as business goals, such as intellectual property requirements, offers a clear definition of reasonable. One way to limit the amount of data is to distinguish between retention of raw data and exception events.
Because the log data may contain sensitive information, PCI and other regulations require the protection of the logs themselves as well as their retention. Log security requirements may require access controls, encryption, integrity checking, and notification of changes. For example, Requirement 10.5 of PCI DSS mandates companies to "secure audit trails so they cannot be altered." This includes limiting access, protecting the logs from modification and having a means to know if the logs have been changed.
4. Determine what types of events and transactions require monitoring
The amount of information generated by most log monitoring tools can overwhelm a security organization. Limiting the types of events and transactions that require retention and review to those related to the key drivers makes the process manageable. Once again, regulatory requirements and security best practices provide a starting point. Events may include: certain login attempts, account modifications, remote connections, changes to policies and permissions, and firewall connections. Event combinations play a critical role in tracking intrusions into the unique infrastructure of each company.
A login from an unexpected source may indicate an imposter using authorized credentials. Malicious traffic followed by an account creation within a set time frame may point to the source of an attack, requiring a quick, targeted response. Meta events may occur within applications or across applications, platforms and network systems.
5. Define review and response requirements for detection and prevention
Each event should have a defined monitoring and response requirement. Event data may simply be collected for future review, or require periodic review and sign-off for compliance purposes. Security events that suggest a likely threat to critical systems should generate an alert for immediate review. The response should clearly articulate the process from detection to response, including appropriate ticketing and workflow documentation.
Your log management strategy serves as a documented set of business requirements around log management for your organization. The requirements should be regularly reviewed to update standards and include new applications and systems. Most importantly, companies should use it to guide purchases of technology and other tactical means to meet business objectives. The technology should not drive the log management strategy.