Verizon Incident-Sharing Framework Brings Sanity to Security Checks
A document was just released
that could help IT managers avoid being a security statistic in 2010.
This week (March 9), Verizon Business released a beta version of the Verizon Incident Sharing Framework (VerIS), a version of the assessment document used by Verizon forensic investigators to systematically gather, categorize and report on data breach incidents. I think IT managers and business executives can use the VerIS to provoke a security discussion that focuses on understanding where information is and what can be done to protect it. VerIS provides a high-level view of the questions used by investigators to get to the heart of a data breach. Even so, the framework provides enough detail to make it well worth the time needed to glance through the 50 or so pages of the report. And one of the primary authors is a person that I think has a good idea about how to approach enterprise IT security.
I met Peter Tippett, vice president of research and intelligence in Verizon Business Security Solutions, several years ago at a security briefing. He planted two ideas in my mind: first, that airline safety developed the gold standard it maintains today by investigating, understanding and correcting errors that led to truly bad aviation accidents. Second, he dispelled the notion that organizations must continually add "super-patchulators"-meaning any security product-to their security arsenal. Rather, knowing where corporate data is and implementing security controls based on this knowledge was far more effective than blindly adding security products.
To be clear, Verizon has business based on using what I must assume is a much more detailed version of VerIS. With that said, the nuts-and-bolts checklists, along with the candid revelation of the methodology used by Verizon Business during investigations, raises VerIS far above a simple marketing tool to that of a really useful assessment framework.
VerIS is divided into four areas; demographics, incident classification, discovery and mitigation, and impact classification. Each area is further broken down into components that encompass detailed questions with specific, suggested answers. For example, in demographics, the incident date is made up of only month and year to allow trending and de-identification. The framework authors concisely discuss the pros and cons of using more and less specific date information. Because of the number of investigations and my favorable experience with Tippett, I'm inclined to go with the VerIS suggestions.
The VerIS framework was developed from looking over a data breach "crash site" as it were, but I think it can be useful for avoiding a breach in the first place. For example, there is a very interesting section on how a change in a person's position in the organization becomes an interesting avenue of investigation. Knowing that a promotion or other change can trigger a data-breach event, it's worth keeping in the back of your mind that vigilance should be increased during staff changes and can likely relax a bit in times of stability.
Having just lived through another RSA conference-and a teeming expo floor filled with vendors shouting "FIRE!"-I recommend the VerIS document as a security sanity check. The VerIS tool is quite candid in asking about the impact of the data breach. If the breach is "insignificant-impact absorbed by normal activities" then you could very likely not spend another moment on the investigation. Or at least shift focus and priority to an area where the impact would be "damaging-real and serious effect on the bottom line." In this sense, the VerIS questionnaire is good at suggesting how to put data security concerns into perspective.