Verizon Incident Metrics Framework Released
Wade BakerMarch 1st, 2010
Many of you who read our blog regularly are familiar with our ‘Data Breach Investigations Report’. We hope that you’ve found past reports informative, useful, and above all, actionable.
The production of the DBIR has been driven by our desire to help solve what we see as two of the most significant problems facing our industry:
- Uncertainty due to the lack of data
- Equivocality due to the lack of a common framework
Basically, we believe that until we can all be on the same page regarding what terms mean and why those terms are useful, we’re going to have a problem creating meaning from any data we *do* get.
One of the reasons we feel that the DBIR is so useful is because it translates the incident narrative (the attacker did this, then that, then the other thing) into a data set. To accomplish this translation, we used a set of metrics developed internally. Think of it as a framework of incident elements we believe will, when gathered consistently, help people better interpret data and manage risk.
Today we’re making a version of that framework, the Verizon Incident Sharing Framework (VerIS), available for you to use.
In the document that you can download here, you’ll find the first release of the VerIS framework. You can also find a shorter executive summary here. Our goal for our customers, friends, and anyone responsible for incident response, is to be able to create data sets that can be used and compared because of their commonality. Together, we can work to eliminate both equivocality and uncertainty, and help defend the organizations we serve.
We hope that you’ll use and even take an active interest in the VerIS Framework. To that extent, we’ve set up an online forum for questions and answers, and have put in place an advisory board of independent security experts to work with the community for the better growth and evolution of the framework as it’s used outside of Verizon.
We truly believe that together, we can begin to make a real difference, and it is our hope that this “common language” will be the first step towards creating an era of shared knowledge and collaboration for our industry.
Interesting work, but it ignores the body of work that currently exist. This seems to be a recreate the wheel.
Can you explain how this is better than IODEF, SCAP, SCCDF, OVAL, CAPEC, RID, CEE, etc. etc?
Posted by: Barry Greene on March 2nd, 2010 at 1:14 amBarry –
This is a good question and one that we most definitely asked ourselves. I will give an answer here and probably address this more fully in a separate blog post in the next week or so. It is an important question. The reason we’ve published the framework and believe that it does not recreate the wheel is two-fold:
1) The problem that it targets still exists. The community has not adopted and begun using a common framework to describe and share incidents. Either a suitable framework exists but people don’t know about it OR people do know about it but have decided that it does not meets their needs. We, of course, hope that people evaluate VerIS, find that it meets their needs, and widely use the framework.
2) The initiatives you list above are not all “VerIS-like” in nature. I’ll separate them into two camps:
Camp A – An actual comprehensive incident reporting framework. IODEF is the only one in this camp but – if I understand it correctly – it’s more about a common data format than “what do I need to know about an incident to inform risk management” (I’m willing to be corrected/enlightened here…). There have been some other similar-ish type initiatives. PREDICT from DHS had the same goal (facilitate information sharing) but I haven’t heard of an update on that project. It may be going on now but I haven’t been able to get an update on the success/failure of the initiative (again…would love for someone to enlighten me). Finally, NIST has several docs in the SP-800 series pertaining to incidents but they are more geared toward the incident response and forensic aspect than what VerIS is trying to accomplish.
Camp B – (**Note: I am stating my understanding of the following, which may be incorrect**) Each of the others target some specific piece of the puzzle rather than an entire post-incident classification framework for any security incident. SCAP is about OS configurations. OVAL is about machine states. CEE is about log data. RID is much lower level into network packet details than VerIS. CAPEC is a breakdown of what we would call “Hacking types”. We referenced it in the document but in the end chose to align VerIS to WASC (another attack classification system) instead of CAPEC (although we do pull from CAPEC to round out some areas not covered in WASC). Some of these may be a very interesting extension to VerIS as a “deeper dive” into certain components.
Again, VerIS is created to classify ANY type of incident (from network attack to physical theft to employee accident to a hurricane) and generate a data set that informs risk management. I don’t believe there are many frameworks out there with that broad scope and purpose.
Posted by: Wade Baker on March 3rd, 2010 at 2:29 amI know this overlaps with a lot of existing frameworks, but I like the direction this document is going. None of the existing frameworks are widely adopted, so I applaud you with coming up with something that might stick to the wall this time. I look forward to reading future revisions of this document and seeing what direction it goes. If I have any feedback or suggestions, I’ll be sure and let you know.
Posted by: Mike Epplin on March 4th, 2010 at 3:01 pmIODEF is essentially just a grammar for describing an incident from initial occurrence through handling. The enumerated lists tend to be where these types of things all fall down, in my experience, so being able to plug in other “dictionaries” like SCAP, CAPEC, (+ MAEC or VerIS values, one day?) is a necessity – aggregating finished data to provide the bigger “risk picture” can hopefully be supported with some automation at press time.
We need a common data exchange to talk about incidents on the fly, when we don’t know enough details to put everything into its color-coded bucket. Right now it sounds like IODEF is the APB/police report and VerIS wants to be more like NIBRS/UCR. I don’t see why one can’t support the other, though.
Posted by: Tom Millar on March 8th, 2010 at 3:15 pmThis does look interesting and it looks like there has been quite a bit of thought given to the details. I did a quick mapping of a small set of real-life incidents and I’d like to suggest a bit more granularity to the actors – Help Desk Staff can be internal or external and it is important to know which applies. Help Desk Staff can be further divided into Call Center Staff (external customer facing – usually has access to customer confidential information) and the more traditional call center that deals with internal staff. One other thing that we have found very useful is to have an actor type of departing/former employee.
Posted by: Dave Edelman on March 26th, 2010 at 2:55 pmLooking at the detailed document now. I’d suggest initially that the executive summary white paper should have a slightly larger typeface. While this might sound superficial (and probably for good reason), readability matters a great deal.
Posted by: Kyle Maxwell on March 31st, 2010 at 4:53 pmMany organizations use partners (contracted non-employees) for secure destruction of confidential data. I can’t find a way to describe such an actor. I would like to see an actor category called secure disposal provider.
Posted by: Dave Edelman on May 13th, 2010 at 1:46 amVery good point. Thanks. We’ll include that along with some other suggested changes when we roll out v1 in the next month.
Posted by: Wade Baker on May 14th, 2010 at 2:13 amI find the VerIS Mind-Map on the MindMeister web-site is a useful tool to visualise and summarise the Incident Classification. It provides you with a quick way to step through the threat modelling without having to re-read pages of documentation.
http://www.mindmeister.com/44961919/veris-incident-classification
Posted by: Philip Richardson on July 22nd, 2010 at 11:51 pm