Information Security Services
Log Management:
The purpose of this whitepaper is to provide the reader with guidance on developing a strategic approach to managing and monitoring logs that enables more efficient compliance with regulatory mandates and more effective defence against security threats.
Executive summary
The amount of data collected by network and security devices is growing at an astounding rate. From compliance requirements to data gathering for forensic purposes, companies have opened up the floodgates to log data. Based on audit findings and internal investigations, many have deployed expensive technologies and lots of personnel without a full understanding of what to log and why. Others simply lack the resources and expertise for this, leaving their company vulnerable to audits, penalties and breaches. Organisations need a business-based approach to creating a log management strategy that will help them detect attacks, deal with mounds of data collected by network and security devices, and meet compliance requirements. This more strategic approach reduces the complexity associated with this process, enables more efficient and
transparent compliance with regulatory requirements, and provides more effective identification and response to security threats.
In addition, current security monitoring approaches rely too heavily on the collection of data at the network layer, generating volumes of data and leaving the application layer at risk. Network monitoring can complement and enhance host and application-based monitoring, but rarely substitutes for it. After all, the typical end result of an attack is access to a host or application such as a credit card database. Host- and application-based monitoring identify events that actually did occur, not what could occur. The combined analysis of network events with log data from critical applications and hosts can point to high risk activity that may be overlooked in network-only analysis. The key is to know which systems to monitor, for what, how frequently, and what to do about
exceptions and anomalies.
This white paper helps security and IT executives design a strategy for more effective log management with a five step process:
1. Identify the key drivers for log management at your company.
2. Identify the systems and applications that fall into the scope of monitoring efforts. 3. Determine log monitoring security and retention requirements.
4. Determine what types of events and transactions require monitoring. 5. Define review and response requirements for detection and prevention.
A business-focused log management strategy matrix helps guide decisions about technology, processes and services, instead of the reverse. The result is better compliance with information security regulations and the ability to effectively respond to information security threats, through a more focused collection and retention of data.
Current state of log monitoring
Because applications are difficult to monitor, companies have neglected to include them in their log monitoring efforts, hoping to catch an intrusion at the network layer. Applications log via different means, in different formats, and capture different variables, making it difficult to centralise information for analysis and reporting. Some applications are not configured to generate security logs at all. Those that are may generate logs that only make sense within the application and cannot be read by a centralised analysis tool. This complexity has kept auditors from focusing in on application logging… until now.
Concerns about control of financial information, unauthorised access to confidential information, and identify theft, have led to information security regulations such as Sarbanes-Oxley (SOX), and industry standards such as the Payment Card Information Data Security Standard (PCI DSS). These laws and industry standards require log monitoring of systems that collect or store personal information and store financial records, but rarely offer specific guidance about what types of data to collect and how long to keep it. While PCI has some specificity, SOX takes a materiality-based approach, leaving interpretation and the ultimate state of controls varying from company to company.
Five steps to a log management strategy
Studies have found that most CIOs believe that their organisations 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 step-by-step process leads to the creation of a log management strategy matrix, an essential planning tool for your organisation.
1. Identify the key drivers 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 matrix 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 key drivers. For example:
• SOX compliance requires log monitoring of financial statement and processing systems • PCI compliance requires log monitoring on credit card processing
In addition to compliance requirements, the scope should include systems that are of high risk to the organisation 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 organisation. 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 authorised
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.
The log management requirements matrix serves as a documented set of business requirements around log management. The matrix should be regularly reviewed to update standards and include new applications and systems. Most importantly, companies should use this tool to guide
Sample log management requirements matrix
Following is a sample log management requirements matrix for a company that processes credit cards.
Part I: Background/drivers
Company X has identified the following key drivers for our log management strategy: • Data protection of sensitive company information
• Data retention for forensic investigations in case of an incident
• Compliance with the Payment Card Industry Data Security Standard (PCI DSS), and Sarbanes-Oxley (SOX)
Part II: Monitoring scope
Company X has prioritised monitoring of the following applications and systems: • Financial systems: accounting software, Oracle database environment, finance
department file servers
• Credit card processing systems: POS application, POS databases, AS-400 servers storing card numbers
Part III: Retention requirements
Company X has reviewed applicable regulations, industry standards and our intellectual property policy, and identified the following retention requirements:
Source PCI SOX Best practices Intellectual property
Minimum required
Raw logs 90 days online/1 year offline
Often 1 year*
90 days online/1 year offline
– 1 year online
Exception events 90 days online/1 year offline
7 years** 3-5 years 1 year 3 years offline
Reports 1 year 7 years 3-5 years 7 years 7 years offline
Tickets 1 year 7 years 3-5 years 7 years 7 years offline
* varies by auditor
Part IV: Security requirements
Company X has reviewed applicable regulations, industry standards and our intellectual property policy, and identified the following security requirements:
Requirement PCI SOX Best practices Intellectual property Company X Access Control R R* R – R Read-only access to raw logs R R R – R Integrity Checking R R R – R Notification of changes to log files
R R R – R
Log file encryption R O O – O
C = collect for future review P = conduct periodic review A = alert for immediate review
Note: Most of the regulatory requirements and standards do not specify event types. The events listed above are interpretations based on the intent of the control requirements.
Event PCI SOX Best
Practices
Company X
Access
User successful login C C CP CP
User failed login CP CP CP CP
Privileged successful login CP CP CP CP Privileged failed login CP CP CP CP
Object access CP CP CP CP
Accounts
Account create/modify/delete C CP CP CP Privileged account create/modify/delete CP CP CP CP
Remote Connections
Remote access (VPN, SSH, etc.) CP C C CP Connections to Web site C C C C
Configuration Changes
Security Policy changes CP CPA CPA CPA
Permission changes CP CP CP CP
Firewall/IDS
Malicious traffic (exploit) CPA CPA CPA CPA
Denied connections CP CP CP CP
Accepted connections C C C C
Anomalous traffic CPA CP CP CP
Meta-Events (Combinations of Events)
Multiple failed logins (5 over 30 minutes) CPA CP CPA CPA Successful logins from different sources CPA CP CPA CPA Malicious traffic followed by account
creation within 1 hour
CPA CPA CPA
Administrative activity by persons not identified as administrators
CP CP CPA CPA
Part V: Event collection requirements
A phased approach to implementation
The log management requirements matrix defines what you need to monitor and how to use the information, based on business goals. The next step is to identify supporting technology and services to help implement the log management strategy with enough flexibility to meet future needs. Common platforms, such as Windows, UNIX and other standard networking device technologies, may require a few modifications to begin logging data quickly. Their logs integrate easily with most monitoring and analysis systems.
Customised databases and mainframes require more flexibility and creativity. Some applications are not configured to generate security logs, while others generate logs that can only be read by the application, not a centralised analysis tool. At the highest degree of difficulty are the applications where data types, formats, organisation and meaning all differ. There may be several ways to retrieve logs that need to be balanced with performance and ongoing management requirements, working closely with the system administrators.
Finding the needles in the haystack
Assigning inexperienced system administrators to sort through volumes of data for anomalies is neither an efficient, nor particularly effective, strategy for ongoing monitoring. Correlation and analysis tools filter raw logs to identify exception events based on the terms defined in the matrix. They can also identify combinations of events or meta events within an application or across
applications, platforms and security devices. Early alerts to exceptions and events that require further review give experts the information needed to respond more quickly and discretely to potential threats and incidents.
Logging the results to improve visibility
Collecting and analysing logs is important, but what key business actions and decisions are undertaken as a result of the review? Having a matrix that articulates the types of reports needed, their frequency, and the process for reviewing and responding to them helps companies manage the workflow of log monitoring in a more consistent manner. Many analysis tools have filters and customisable reporting tools to generate reports based on event type or asset groups. For example, a PCI auditor may need to see a credit card processing audit log. The security officer responsible for SOX compliance may review financial statement control logs. Log reports should have assigned reviewers who review, approve or potentially flag the reports for investigation. Last but not least, a record of the log collection and review helps the company substantiate to auditors that the reviews are taking place, and incidents responded to appropriately.
Conclusion
Dell SecureWorks’ log management service
Dell SecureWorks’ Log Management service extends visibility beyond the network perimeter to the application layer to help customers identify threats and comply with industry standards and government regulations. Our experts help you identify critical systems, determine what to log and create rules to identify exception events in customised applications. Dell SecureWorks’
comprehensive managed service collects, analyses and stores logs from networks, hosts and critical applications, with 24x7x365 monitoring and real-time security alerts. Web-based, secure access to reports and event data via the Dell SecureWorks Portal enables managers to assign log reports for specific users to approve or flag for further investigation, tracking workflow and creating an audit trail. The service leverages best-of-breed technology, operational excellence and world-class expertise to deliver a flexible, highly scalable solution that addresses security and compliance needs.
About Dell SecureWorks
Dell Inc. (NASDAQ: DELL) listens to customers and delivers worldwide innovative technology and business solutions they trust and value. Recognised as an industry leader by top analysts, Dell SecureWorks provides world-class information security services to help organisations of all sizes protect their IT assets, comply with regulations and reduce security costs.
For more information, visit http://www.secureworks.com/uk
THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.
Availability varies by country. © 2011 Dell Inc. All rights reserved.
