In reading the Verizon Business 2011 DBIR, one point stands out for me: relative to last year’s report, attacks are happening faster (point of entry to compromise) and attack recognition is slower (compromise to discovery).

2011 Verizon Business Data Breach Investigations Report

 This is yet another reminder that proactive log analysis is an under-utilized weapon in the fight against data breaches. Real-time consoles are great and represent an important part of any effective SIEM solution. But all of the gray area in the chart above denotes activity that is happening beyond the focus of most real-time consoles. Meaning, there are plenty of attacks that take days, weeks or years to compromise our defenses and that means a broader and deeper log management and review process can help us prevent, contain and/or more quickly discover any given breach.

Zooming in on attack timing from the 2011 report, we see that 44% of the attacks took days from point of entry to compromise. In these cases, daily log data exception filtering and alerts would improve prevention, containment and discovery effectiveness. 9% of the attacks took weeks or months; in these cases, even weekly exception filtering and report reviews would improve prevention, containment and discovery effectiveness.

Zooming in on discovery timing from the 2011 report, we see that only 4% of the breaches were discovered in minutes or hours while 96% took days, weeks, months or years. Zooming in further, 38% took weeks and 36% took years to discover! Clearly, even weekly log analysis could have helped these companies to discover their breach and either contain it or at least begin the damage control process in a timely fashion.

We all know that enterprise-wide log collection, storage, filtering and analysis can be challenging. But the evidence continues to suggest that proactive efforts in this area can significantly reduce IT security risks. In a domain that requires us to depend upon many intangible technologies (best effort algorithms) and skills (craft), proactive log analysis represents a very tangible effort/reward proposition.

permalink

Verizon Business recently published its 2011 Data Breach Investigations Report (DBIR) and I am once again stunned by the apparent correlation between getting breached and myopic log management:

• 69% of the breaches had log evidence available for forensics
• <1% of the breaches were discovered by internal log analysis and/or review

The report makes a halfhearted attempt to look on the bright side: “…discovery through log analysis and review has dwindled down to 0%…so the good news is that things are only looking up from here.” CEOs reading this will not be amused, particularly if they are among the 86% of breached companies whose internal efforts failed and were notified of the breach by a third party.

When I force myself to think about what choices could lead to this miserable outcome, I come up with three types of companies:

• Type 1 companies don’t read these reports and therefore have no clue that they can help themselves (not a great place to be)
• Type 2 companies have deployed log management products and commit real resources to log analysis, but simply haven’t succeeded in this effort (a better place to be, but not great)
• Type 3 companies read these reports, know that they can help themselves, but have failed to act (probably the worst place to be)

If you are a Type 1 or if you know one, perhaps this latest report and my humble rant will help you and yours open your eyes to the reality of modern day threats, the realities of imperfect security and the necessity of log management and analysis as a compensating control. If you are a Type 2, you should challenge your log management vendor to help you succeed. Chances are, you are struggling with a log management technology that lacks flexibility to include all relevant sources, scalability to store all of the relevant data for extended periods of time, and analytical strength to help your finite staff automate exception filtering. If you are a Type 3, I can’t help you yet, but perhaps I will read more about you in the next DBIR.

permalink

SenSage recently conducted a survey of 383 information security professionals and found that two out of three had encountered obstacles to security data access and analysis while performing their security duties. This clearly validates the need for open data analysis architectures in the SIEM and Log Management market. According to the same survey, the tasks impacted by these obstacles are critical to the perceived effectiveness of log management, compliance reporting, real-time monitoring, forensic investigation and incident response processes in their organizations. I would place the impeded tasks into two groups: traditional but underwhelming and emergent but immature.

In the traditional but underwhelming category we have basic things like “trying to better understand a compliance exception or real-time console alert.” You would think that these tasks would have matured and evolved to a point of effectiveness by now but they haven’t because most SIEM and Log Management offerings do not enable the end user to drill into data behind compliance reports and real-time alerts. In the emergent but immature category, we have more holistic things like “trying to understand how a certain metric is changing over time” and “trying to compare security effectiveness across different groups or environments.” Again, we can trace the struggle here to weak data management scalability and weak data analysis capabilities of most SIEM and Log Management offerings. SenSage specializes in delivering these scalability, drill-down and trend analysis capabilities within its SIEM and Log Management offering, and is encourage by the fact that the industry is starting to acknowledge these challenges and demonstrating an interest in tackling them in order to improve their security postures.

This second annual survey also indicated minor progress in security management process evolution. Specifically, coordination across log management, compliance reporting, real-time monitoring, forensic investigation and incident response processes has improved slightly but remains a challenge. We know that process coordination is challenged by the usual “organizational dynamics” in large companies and government agencies. But we also know that data (fact) helps stimulate cooperation across teams because it cuts through subjective and political behaviors. Other findings include:

• Measurement of these processes is basically flat year over year (measurement is hard, especially when you don’t have the tools
• Consistency of process improvement has increased, but finding the resources needed to implement process improvements remains a challenge
• Perceived effectiveness of these processes has improved slightly year over year, but 57% still believe that they are infective or only somewhat effective

SenSage conducts these surveys to keep tabs on how the problem set is evolving in our market. We continue to believe – and these surveys continue to confirm – that effective data management, scalability and analysis is critical for success in proactive security organizations.

SenSage will present a webinar detailing the survey results, changes in the past year, interesting correlations and emerging use cases for data-driven security management. If you would like to attend, please register here.

permalink

There was much talk about cloud security at the RSA Conference last week. On multiple occasions, I was asked for my opinions about log management in the cloud, so I thought I would repeat my replies here. Note that I see log management in the cloud as more of an outsourcing decision than a technology decision. Overall, I see cloud-based log management services on the rise, but with a few key qualifiers that impact the forecast ahead.

The Choice Comes Down to Personality.
Just as we’ve seen with general outsourcing trends over the years, the companies that are willing to outsource log management are those that have an outsourcing personality type…willing to jettison anything that fails the “core versus context” test. While initiatives related to security have tended to be seen as “sensitive context” and therefore tend to stay in house, tight capital budgets and staffing resources have driven more companies to consider outsourcing log management. On the other side of the coin, I do not see many proactive security organizations outsourcing log management because for them, log management, exception reporting and security data analysis are core to their business or government missions.

The Choice May Be a Short-sighted One.
Some organizations see log management outsourcing as an opportunity to avoid non-compliance risks, hoping to blame the outsourcing provider as a first line of defense in dealing with lapses. This is obviously a short-sighted approach, but it happens and may in some cases deliver the intended benefits.

Outsourcing Works Best in a Vertical Context.
This principle often trumps the first two and creates a situation that makes outsourcing superior to insourcing, even for security functions. This is particularly true in the defense industry, where information access policies (e.g., Unclassified, Classified, Secret, Top Secret) and other control structures (e.g., mission, branch, command) are well established, and where defense integrators have established the individual skill sets and large-scale project management competencies necessary for success. We have also seen this in the health care market, where we have partnered with Cerner to embed our log management, audit and compliance reporting capabilities into their health care IT platform Millennium.

More in the U.S., Less in Europe.
In the U.S., we’ve seen a gradual but persistent warming to the thought of handing security data over to security service providers. Not so much in Europe, where privacy concerns and regulatory obligations make this proposition less attractive. Since the primary drivers in the U.S. are also present in Europe (e.g., compliance mandates amidst staffing and budget pressures), it will be interesting to see if the tendencies shift over time.

In summary, log management in the cloud can make sense in the right situations. Make sure the technology behind your service provider can scale to meet your needs and keeps your data separate from other customers’ data. You should also make sure that the technology will help the service provider reduce costs via data compression and storage optimization, because these advantages will help keep your provider in business or reduce the cost of the service or both. Finally, make sure that you will get standard and custom reports, the latter being delivered via a direct interface of your own. Of course, all of these requirements are satisfied by SenSage SIEM and Log Management solutions for managed security service providers. If you’d like to learn more, send us a note.

permalink

Verizon’s 2010 PCI Compliance Report published earlier this month provides yet another reminder that most organizations are not keeping up with “known good” security practices. Only 22% of organizations achieved a passing grade on their initial report on compliance, and Verizon found that these tended to be “year after year” compliance masters that view PCI as demanding a “lifestyle change” rather than compulsory acquiescence. This reminds me of a related statistic…90% of people diagnosed with heart disease are unable to change their lifestyle to reduce their risk…they’d literally rather die than change. Fortunately PCI is not a matter of life and death, but you get the point.

Like most other compliance regulations in the security industry, PCI was established for a specific purpose (protecting payment card data), but comprises requirements that can help any organization in any industry take a more methodical approach to information security. The report’s analysis of compliance by requirement illustrates that organizations are better at planning (Requirement 12) and doing (Requirements 1-9) than checking (Requirements 10-11), based on average compliance rates of 44%, 54% and 39%, respectively. Those of us that have studied quality know that you must “check” or “measure” to learn what to change and then follow through and repeat to maintain the cycle of continuous improvement. The most proficient information security organizations have applied at least basic quality principles and have established continuous improvement processes to cope with the ever-changing threat horizon.

The two lowest compliance rates were found in PCI Requirement 10, Track and monitor all access to network resources and cardholder data and PCI Requirement 11, Regularly test security systems and processes. I will leave the latter to other bloggers, but I have a vested interest in helping the industry do a better job with the former. Verizon’s findings on why Requirement 10 challenges may be summarized as follows:

• Implementing logging is easy on networking devices and operating systems but is hard on applications, particularly legacy applications
• Securing the logs from alteration is hard, since the default configuration is to overwrite old log data as local log storage space is consumed
• Maintaining an audit history for all logs is hard because this requires a comprehensive and timely logging infrastructure and centralized log file integrity monitoring
• Daily monitoring and review of logs is hard because “…the amount of information far exceeds our ability to extract meaning from it.”

These challenges are daunting but can be overcome with effective people, process and technology aimed at log management and analysis. Organizational commitment is essential, but it often requires an executive to step up and articulate a vision for comprehensive and continuous monitoring, analysis and adjustment. SenSage customers tend to have such a champion that has helped their organization realize that these challenges can be mastered and that the payoff is not only regulatory compliance but real reduction of risk. Applications – even homegrown legacy applications – can be monitored, if you have a technology that accepts native log data without the need to add agents to the applications. Once this application logging is established, you need a central repository to store this data along with all of the “easy logging” data from network devices and operating systems. The central repository should be “append only” to ensure that no log data can be changed (this is needed to satisfy PCI Requirement 10.5.5). And finally, the central repository must support a business intelligence layer that enables you to filter the data and isolate the conditions of concern. While some of these conditions are known in advance and therefore can be “shrink-wrapped,” most are the result of applying continuous improvement principles in the context of your unique environment. This approach is particularly effective when extended beyond the sphere of tracking and monitoring, and into the world of regular testing (PCI Requirement 11, the other weak area cited by the report). For example, in between quarterly network vulnerability scans (Requirement 11.2) and annual penetration tests (Requirement 11.3), log data may be filtered for conditions that caused prior test failures, such as inconsistent configuration settings and/or security patch levels.

The Verizon 2010 PCI Compliance Report highlights the need for progress, but also provides useful lessons from the ongoing effort. PCI Requirement 10 has presented particular challenges in application log enablement, log file integrity monitoring, system scalability and log data analysis that most log management solutions have been unable to address. Organizations that find themselves in the 61% not complying with Requirement 10 should consider SenSage Security Intelligence solutions that solve these issues as noted above. Together, we can do this!

permalink