E-Guide
Log management best practices:
Six tips for success
The right log management tool can go a long way toward reducing the burden of managing enterprise system log data. However, the right tool can quickly become the wrong tool unless an organization invests the time and effort required to make the most of it. Diana Kelley offers six log management best practices to ensure a successful
E-Guide
Log management best practices: Six
tips for success
Table of Contents
Log management best practices: Six tips for success
Log management best practices: Six tips for
success
By Diana Kelley, Contributor
The right log management tool can go a long way toward reducing the burden of managing enterprise system log data. However, the right tool can quickly become the wrong tool unless an organization invests the time and effort required to make the most of it. Diana Kelley offers six log management best practices to ensure a successful implementation. • A fool with a tool is still a fool – Don't spend millions on a log management
system if you're not prepared to invest the time in installing and managing it properly. Log management systems must be configured to parse events and data that matter to the organization so that reports have business and technical value. Another "fool" mistake is failure to look at and review the alert console, thereby missing critical security events. Don't make the mistake of committing to log management technology without committing the time necessary to use it well. • Pre-define requirements to streamline RFPs – Creating RFPs is a
time-consuming process, but some requirements, once defined, can be re-used in subsequent RFPs. This is often the case with logging requirements because the baseline of what's needed (format of the log file, data written to the log file, etc) remains the same. Another benefit of using pre-defined requirements is that it ensures the requirements remain consistent while streamlining the RFP cycle. • Make sure you have the information you need – To be able to write effective
correlation rules, the log management system must have enough contextual data to analyze. For example, where specifically did the traffic or activity come from? This requires knowledge of the source IP address, which means the log management systems must be logging that information in order for the engine to be able to parse it. What happened on the target device or application? If an organization wants to write log analysis rules and alerts for activity, the log data must record that activity. • Think beyond static reporting – The last thing most organizations need is another list or spreadsheet filled with rows and rows of data that has no overarching analysis model to help make sense of it all. Alerting should be done not just on "the
acceptable activity. Consider logins to a critical database. The normal baseline may be two failed logins, but if the password requirements for that system are changed from a simple dictionary word to an 8+ character non-dictionary string, login failures may be expected to increase while users get accustomed to the new rules.
Intelligently aware log management systems could be tuned to monitor trends and provide feedback to the administrators who may decide to use the trending
information to temporarily alter the alerting threshold.
• Use log data to figure out what is happening or what just happened – "Logs are wonderful for outages," because, very often, all of the information necessary to determine what is causing (or caused) the outage can be found in the log files themselves. During a crisis, staff often goes into reactive mode, sometimes relying on intuition, speculation, and atomic unrelated pieces of information to piece together what is going on or what happened. But logs are a record of what actually happened. Systems that allow staff to write and run reports in real-time based on outage information deliver the facts that response teams need to understand what's happening on the network.
• Think outside the security box – Log management systems are excellent for aggregating and analyzing information from security devices for security awareness, but the information being gathered can be used for other purposes as well. For example, an organization "can analyze the customer experience for [your] top ten business relationships." Many trending and click track type Web application-reporting systems don't provide a granular view of the actual customer experience. "Well-designed application logging would take the customer experience into account," and expands the utility of the log management well outside of the security box.
About the author:
Diana Kelley is a partner with Amherst, N.H.-based consulting firm SecurityCurve. She formerly served as vice president and service director with research firm Burton Group. She has extensive experience creating secure network architectures and business solutions for large corporations and delivering strategic, competitive knowledge to security software vendors.
Understanding PCI DSS compliance requirements
for log management
By John Kindervag, Forrester Research
The requirements of the Payment Card Industry Data Security Standard (PCI DSS) can be complex. However, taking a deeper look into some of its parts, particularly event log management, can help clarify some terms.
Many companies believe that logging is specified in PCI DSS so that they can discover threats to their networks. While this may be an ancillary benefit, logging was put into PCI for the benefit of the card brands. In the early years of credit card security, card brands put significant effort into determining the attack vectors of credit card breaches. Unfortunately, when they sent teams into retailers to find the root cause of breaches, they discovered only meager evidence to use in tracing attacks. Therefore, the brands introduced logging
requirements into their individual cardholder protection efforts so they could find out what happened when a breach occurred. Eventually these requirements found their way into the PCI DSS. Understanding this as the intent of the logging requirements can help companies understand how to implement event log management to best meet PCI DSS compliance requirements.
What must be logged to meet PCI DSS compliance requirements?
Just a few years ago, it was unusual to see an environment where logs were checked on a regular basis. Logs were stored on syslog servers until an event occurred that required attention, such as an attack or a network issue, but there were so many events that
information overload made log reviews unproductive. In order to reduce the logging burden, PCI focused on who did what and when they did it.
Therefore, the primary component of PCI logging involves logging user activity in a
cardholder environment, and making an audit trail of that activity available. Mandating user activity logging and audit log reviews allowed the PCI Security Standards Council (SSC) to provide critical information to forensic investigators and create a sense of situational
Additionally, PCI mandates that the data be available for auditing and forensic purposes, which requires that one year of data be accessible to auditors or investigators. Be sure to regularly test and review offline log data to ensure the data is available on demand for auditors or investigators.
Effective log management for PCI DSS
To create an effective event log management system to support a PCI DSS compliance initiative, identify the systems that must forward logs. This requires creating a list of assets and then mapping those assets to your PCI scope. Eliminate all assets that are out of scope, and then review the remaining assets to determine if they should have logging enabled. A minimum baseline of PCI logging compliance must be a priority, but many organizations acquire a full security information management (SIM) product to provide parsing and reporting on other important security information. Others will choose to outsource PCI log management -- an excellent option for companies with limited IT or security staff.
Once the company determines how it will implement log management for PCI, configure the devices that are being logged to send logs to the central log server.
Remediating log compliance issues
Since the PCI DSS log management requirements were designed with the forensic
investigator in mind, try to think like one: If you were sent to your company to investigate a credit card breach, what would you want to see in the logs? This will shift the company's paradigm from logging threat events to logging user access events, which is paramount in PCI.
Look at logging as a process and design a workflow around that process. Too often logging is done ad hoc, with engineers enabling the log functionality without consideration as to how this information can be used to have a positive effect on the business.
Maintaining log compliance with PCI DSS
Many organizations underestimate the vast amount of storage capacity necessary to meet PCI. Estimate the volume of log data generated per logged device per day, and then get more storage than anticipated. Logs are always bigger than you think they will be.
The cost of storage can be an important factor when considering an outsourcing or Software as a Service (SaaS) model for log management, since service providers and data centers are designed to add capacity seamlessly. Also, the three most important elements of the log management process -- reviewing logs on a daily basis, archiving them for the right amount of time, and pulling the reports for your QSA as needed -- all lend themselves to
outsourcing.
Over time, it will become tempting to ignore the logs; other priorities will leap past log reviews. You can, however, guarantee a more effective logging operation if you put a reporting structure in place that not only requires logs be viewed regularly, but also generates and delivers daily reports to key executives.
About the author:
John Kindervag, CISSP, CEH, former QSA, CPISM and CCNA, is a senior analyst with Cambridge, Mass.-based research firm Forrester Research. A 25-year veteran of the tech industry, his focus areas include network and wireless security, security information management and PCI DSS data security. John will be speaking at Forrester's Security Forum, Sept. 10-11, in San Diego, Calif.
