Log Management How to Develop the Right Strategy for Business and Compliance. Log Management

Transcription

1 Log Management How to Develop the Right Strategy for Business and Compliance An Allstream / Dell SecureWorks White Paper 1

2 Table of contents Executive Summary 1 Current State of Log Monitoring 2 Five Steps to a Log Management Strategy 2 Sample Log Management Requirements Matrix 4 A Phased Approach to Implementation 7 Finding the Needles in the Haystack 7 Logging the Results to Improve Visibility 8 Conclusion 8 Dell SecureWorks log management service 9

3 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 defense 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. Organizations 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: Identify the key drivers for log management at your company. Identify the systems and applications that fall into the scope of monitoring efforts. Determine log monitoring security and retention requirements. Determine what types of events and transactions require monitoring. 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. 1

4 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. 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 centralize 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 centralized analysis tool. This complexity has kept auditors from focusing in on application logging until now. Concerns about control of financial information, unauthorized access to confidential information, and identify theft, have led to information security regulations such as Sarbanes-Oxley (SOX), the Health Information Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley Act (GLBA) 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, HIPAA, GLBA and SOX all take materiality-based approaches, 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 organizations 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 organization. 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

5 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 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. 3

6 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. 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), Sarbanes-Oxley (SOX), and the Gramm-Leach-Bliley Act (GLBA) Part II: Monitoring Scope Company X has prioritized 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 4

7 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 GLBA Best practices Intellectual Property Minimum Required Raw logs 90 days online/ 1 year offline Often 1 year* days online/ 1 year offline -- 1 year online Exception events 90 days online/ 1 year offline 7 years** years 1 year 3 years offline Reports 1 year 7 years years 7 years 7 years offline Tickets 1 year 7 years years 7 years 7 years offline * varies by auditor. ** unless details are captured in reports that are retained for 7 years. Part IV: Security Requirements Company X has reviewed applicable regulations, industry standards, our intellectual property policy, and identified the following security requirements: Requirement PCI SOX GLBA Best Practices Intellectual Property Company X Access Control R R* R R -- R Read-only access to raw logs R R R R -- R Integrity checking R R R R -- R Notification of changes to log files R R R R -- R Log file encryption R O R O -- O R = required O = optional 5

8 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 GLBA Best Practices Company X Access User successful login C C C CP CP User failed login CP CP CP CP CP Privileged successful login CP CP CP CP CP Privileged failed login CP CP CP CP CP Object access CP CP CP CP CP Accounts Account create/modify/delete C CP C CP CP Privileged account create/modify/delete CP CP CP CP CP Remote Connections Remote access (VPN, SSH, etc.) CP C CP C CP Connections to Web site C C C C C Configuration Changes Security Policy changes CP CPA CP CPA CPA Permission changes CP CP CP CP CP Firewall/IDS Malicious traffic (exploit) CPA CPA CPA CPA CPA Denied connections CP CP CP CP CP Accepted connections C C C C C Anomalous traffic CPA CP CP CP CP 6

9 Meta-Events (Combinations of Events) Multiple failed logins (5 over 30 minutes) CPA CP CP CPA CPA Successful logins from different sources CPA CP CP CPA CPA Malicious traffic followed by account creation within 1 hour Administrative activity by persons not identified as administrators CPA CPA CPA CPA CPA CP 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. 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. Customized 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 centralized analysis tool. At the highest degree of difficulty are the applications where data types, formats, organization 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. 7

10 Logging the Results to Improve Visibility Collecting and analyzing 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 customizable 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. 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 customized applications. Dell SecureWorks comprehensive managed service collects, analyzes 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. 8

11

12 Connect with confidence through Allstream and Dell SecureWorks Together Allstream and Dell SecureWorks deliver managed security services that are unrivalled by other Canadian service providers. The combination of deep expertise in voice, data and IP networking, in conjunction with intense focus on intelligent defence and threat visibility, allow our customers to connect with confidence. Allstream is recognized as an industry-leading communications provider to Canada s Fortune 100 and mid-market businesses. Dell SecureWorks is a leading global provider of world-class information security services for Fortune 500 and mid-sized businesses. For more information about Managed Security Solutions Call now visit allstream.com/security or us at connect@allstream.com About Allstream Allstream is the only national communications provider working exclusively with business customers. Our focus is helping you simplify IT operations to improve productivity, maximize performance and manage costs. Our IP solutions are delivered on a fully managed, fully secure national network and backed by our industry-leading commitment to customer service: The Allstream Service Guarantee. About Dell SecureWorks SecureWorks is now a part of Dell. Dell SecureWorks is recognized as an industry leader, providing world-class information security services to help organizations of all sizes protect their IT assets, comply with regulations and reduce security costs. To learn more, visit Allstream 200 Wellington Street West Toronto, Ontario M5V 3G2 Call, visit or follow us at: blog.allstream.com Copyright SecureWorks, Inc. All rights reserved. All other products and services mentioned are trademarks of their respective companies. WP_22175 V2 11/14 Allstream Inc.