Verizon shares framework to gather, analyze security incident data

It's aimed at helping companies compare notes on security breaches

The idea behind the Verizon Business incident sharing metrics framework, which underpins the company's highly regarded data breach investigation reports, is that those who do not learn from security incidents are doomed to repeat them.

With that in mind, Verizon today released its Verizon Incident Sharing framework (VerIS), a move aimed at helping enterprises consistently analyze and share incident data, whether internally or with each other.

"This framework is what we have come up with to capture data about incidents that provides helpful information for risk management and understanding exactly what happened," said Wade Baker, Verizon Business' director of risk intelligence.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

The idea behind the Verizon Business incident sharing metrics framework, which underpins the company's highly regarded data breach investigation reports, is that those who do not learn from security incidents are doomed to repeat them.

With that in mind, Verizon today released its Verizon Incident Sharing framework (VerIS), a move aimed at helping enterprises consistently analyze and share incident data, whether internally or with each other.

"This framework is what we have come up with to capture data about incidents that provides helpful information for risk management and understanding exactly what happened," said Wade Baker, Verizon Business' director of risk intelligence.

"Everything in the framework is keyed to understanding how [an] attack took place from the standpoint of how might I prevent it, detect it, respond to it and correct it," he said.

Verizon puts a lot of emphasis on sharing and hopes organizations will use the framework as an apples-to-apples way of comparing incident information; it offers an advisory board and a framework site that allows companies to easily share ideas about using and refining VerIS.

The framework draws credibility from the 2008 and 2009 data breach nvestigation reports. Those reports are based on the collected metrics from hundreds of investigations covering hundreds of millions of records. The reports showed how attackers repeatedly exploited fundamental errors, such as unchanged default passwords and weak or misconfigured access control lists (ACLS) -- often in non-critical systems -- to gain a foothold in enterprise networks and steal sensitive data.

"People appreciate our framework," Baker said, "because they see the fruit of it in the data breach investigation reports. ...Using the framework produces useful, actionable information on an aggregate level."

The follow-up 2009 Data Breach Investigations Supplemental Report provided highly detailed information into the kind of data the framework could yield. It described 15 threat types, how each is used to infiltrate corporate networks, and how to detect the threats and mitigate the risk. It is in dealing with that last point that Verizon believes the framework can pay off.

The detection data yielded showed that organizations need to use the information from their incident reports to improve security. Breaches went undetected for an average of six months, as attackers collected data over time. Typically, third parties -- noticing for example, unusual credit card activity -- discovered the problem before the company that had been breached.

VerIS's foundation is an understanding of risk based on assets, threats, impact and controls. The framework is divided into four sections, each of which captures a different aspect of a security incident. Collectively, it's designed to help enterprises understand what happened and how bad it was. Those sections include:

• Demographics such as the date of the incident, how serious it was, the region in which it occurred and the vertical industry of the affected company.
• Incident descriptions using metrics to detail the series of events that comprise an incident, who was affected and what was done. For example, a database breach using SQL injection might describe the perpetrator as an outside organized crime group from Romania; the action as a SQL injection hack exploiting a Web application; the asset affected as 10,000 customer records on a database server; and the result as exposure/loss of confidential information.
• Discovery and mitigation details that analyze the events immediately following an incident and the lessons learned. Metrics include a timeline, how the incident was discovered,the resources used, the controls used and whether they were adequate.
• Impact analysis that details direct asset losses, business disruptions and response and recovery costs, as well as indirect losses affecting competitive advantages or marketplace damages. The impact section of the report would also estimate known and predicted losses and how a security incident is perceived.

Neil Roiter is a freelance writer who has covered technology and security issues, most recently for TechTarget.