How to Develop a Log Management Strategy

Transcription

1 Information Security Services Log Management: How to develop the right strategy for business and compliance

2 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 Several factors have put applications and data inside the firewall at greater risk. First, the growing use of Web-based applications for business-to-business and business-to-consumer transactions has increased the sheer volume of traffic for monitoring. Second, attackers have grown more sophisticated, moving beyond disruptive attacks, such as virus or denial of service attacks, to targeting applications and stealing high-value data.

3 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 and data storage systems

4 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 purchases of technology and other tactical means to meet business objectives. The technology should not drive the log management strategy.

5 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 ** unless details are captured in reports that are retained for 7 years

6 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 R= required O = optional

7 Part V: Event collection requirements Based on retention and security requirements, Company X has identified the following events for collection and assigned an appropriate review period: 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 Administrative activity by persons not identified as administrators CPA CPA CPA CP CP CPA CPA 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.

8 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 The word strategic is not often associated with information security, and even less so with compliance. Too often, companies solve security and compliance requirements for log monitoring through technology purchases or expanded staffing resources. It is clear that the cost and complexity of developing and maintaining an effective log management system draws focus and resources away from core business needs. A more cost-effective solution approaches log management like any other strategic planning exercise. By starting with the drivers, building the business requirements and executing against the plan, companies will have a monitoring capability that reaches deep into their systems and applications, focusing resources where the risks are greatest.

9 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 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 Dell Inc. All rights reserved. Dell and the Dell logo, SecureWorks, Counter Threat Unit (CTU), isensor, iscanner, Sherlock, Inspector and LogVault are either registered trademarks or service marks, or other trademarks or service marks of Dell Inc. in the United States and in other countries. All other products and services mentioned are trademarks of their respective companies. This document is for illustration or marketing purposes only and is not intended to modify or supplement any Dell specifications or warranties relating to these products or services. February 2011.