Você está na página 1de 12

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

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

1
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


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

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
Log Management | How to Develop the Right Strategy for Business and Compliance

Part III: Retention Requirements

Company X has reviewed applicable regulations, industry standards and our intellectual property policy, and identified the
following retention requirements:

Intellectual Minimum
Source PCI SOX GLBA Best practices
Property Required

90 days online / 90 days online/


Raw logs Often 1 year* -- -- 1 year online
1 year offline 1 year offline

Exception 90 days online /


7 years** -- 3-5 years 1 year 3 years offline
events 1 year 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.

Part IV: Security Requirements

Company X has reviewed applicable regulations, industry standards, our intellectual property policy, and identified the
following security requirements:

Intellectual
Requirement PCI SOX GLBA Best Practices Company X
Property

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
CPA CPA CPA CPA CPA
1 hour
Administrative activity by persons not identified as
CP CP CP CPA CPA
administrators

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
Log Management | How to Develop the Right Strategy for Business and Compliance

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
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 1 855 299-7050
visit allstream.com/security
or email us at connect@allstream.com

About Allstream About Dell SecureWorks


Allstream is the only national communications provider working SecureWorks is now a part of Dell. Dell SecureWorks is recognized
exclusively with business customers. Our focus is helping as an industry leader, providing world-class information security
you simplify IT operations to improve productivity, maximize services to help organizations of all sizes protect their IT assets,
performance and manage costs. Our IP solutions are delivered on comply with regulations and reduce security costs. To learn more,
a fully managed, fully secure national network and backed by our visit www.secureworks.com.
industry-leading commitment to customer service: The Allstream
Service Guarantee.

Allstream
200 Wellington Street West
Toronto, Ontario M5V 3G2

Call, visit or follow us at:


1 855 299-7050
www.allstream.com
blog.allstream.com

Copyright © 2009-2011 SecureWorks, Inc. All rights reserved. All other products
and services mentioned are trademarks of their respective companies.
WP_22175 V2 11/14 ® Allstream Inc.

Você também pode gostar