- 15 Non-Certified IT Skills Growing in Demand
- How 19 Tech Titans Target Healthcare
- Twitter Suffering From Growing Pains (and Facebook Comparisons)
- Agile Comes to Data Integration
The CIO-level business angle on the latest tech
The 2010 Data Breach Investigations Report published by the Verizon Business RISK Team is out, and it's a gold mine of information. This year's report includes investigations conducted by the U.S. Secret Service, dramatically increasing the scope of the breaches that have been analyzed for root cause. The reason this report is so valuable is that it gives us an opportunity to see where other organizations have failed to protect their data and systems, so that we can learn from others' misfortune.
There are always some surprising statistics and details in the report. For example, the 2010 report states, "We consistently find that nearly 90% of the time logs are available but [breach] discovery via log analysis remains under 5%."
Does this mean that collecting log data isn't worth the effort? No, not at all. But the report suggests that maybe a change in strategy is needed; instead of looking for a needle in a haystack, perhaps it's time to look for haystacks. The report says there are three major tip-offs (i.e., haystacks) that could be signs of a breach:
* Abnormal increase in log data
* Abnormal length of lines within logs
* Absence of (or abnormal decrease in) log data
The investigators write, "We've seen log entries increase by 500% following a breach. We've seen them completely disappear for months after the attacker turned off logging. We've noticed SQL injection and other attacks leave much longer lines within logs than standard activity. Those are more like haystacks than needles." Furthermore, "just finding the haystacks would be a very real improvement."
Tools like security information event management (SIEM) systems can help you find the needles as well as the haystacks so that you increase your chances of not only detecting but perhaps even mitigating a breach or other violation of policy. Bill Roth, executive vice president of global marketing at LogLogic offers his suggestions for best practices for SIEM deployments:
Understand your data and what you want it to do for you.
You have to understand the size, frequency and behavior of your log data before you deploy. This means knowing where your data comes from (e.g., systems, routers, switches) and how it's delivered. You also want to identify your goals for implementing a SIEM system. Is your SIEM project primarily to support day-to-day operations? Is it for security and keeping logs as an audit trail? Or is it for meeting a specific compliance mandate? Understanding what you want the SIEM system to do for your organization will help you define the policies and procedures you'll need to adhere to, as well how long to retain your log data.
Identify the scope of devices you want to log (e.g., syslog, systems, routers, firewalls). Depending on the above mentioned use cases, you may have a specific set of devices in mind. Keep in mind that you can log things beyond just network equipment. For example, you can also collect from physical logins like security access into a building. Also, on the compliance side, PCI-DSS requires you to log all devices that are involved in payment card transactions. Often, enterprises will segregate that network, and keep a year audit trail on just those devices. To play it safe, log everything to ensure you are covered across your entire network and enterprise.