Answer:
Dear Searching Screensaver,

The data does not have an exact answer for you due to several reasons, but there is some information on related threat events that I hope will be helpful. First of all, if you’ve read the DBIR, you’re aware we use the VERIS framework to classify incidents. One of the things we classify about an incident is the particular threat actions involved. The threat actions related to what you describe below would be “local access” and “snooping” (see definitions here). In fact, your scenario below is the exact example we give for “local access”. Both of these are in the Physical threat action category.

In terms of frequency, these are not among the most common of all threat actions tracked across our IR investigations and cases supplied by our law enforcement partners. We’ve seen a little over 30 incidents in the last several years involving one or both of these threat actions. However, the majority of those did not specifically trace back to screen/session timeouts (e.g., snooping also includes rummaging through one’s desk for sensitive info).

While 30-ish may seem low, it should also be noted that such events are less likely to require a paid forensic investigation by Verizon. There’s a caseload bias here. Plus, most organizations have a timeout policy, and if they didn’t, I imagine the number of related incidents would go up.

I am fairly conservative in recommending or requiring controls, but I tend to put this one in the “essential” category. There’s decent evidence available outside our case data to support the benefits of screen timeouts. For instance, lost and stolen devices are among the most commonly-reported incidents leading to data exposure on lists that track public disclosures like datalossdb.org. Not only does it prevent unauthorized access from curious or malicious insiders, but it’s an effective control against the office prankster who likes to send embarrassing emails (or worse) when you head for a coffee refill. I won’t go into detail, but let’s just say I have a decent set of priors on this one. Furthermore, I consider it a must have for portable devices like laptops that are used in public settings (I recommend keeping the device with you during potty breaks, but it always amazes me how many folks leave their laptops active and unattended).

Maybe you could respond to those complaining about the policy with “perhaps you should just consider doing some work at least every 15 minutes” and CC their supervisor.

I’m Jay Jacobs and I joined the Verizon RISK Intelligence team in January of this year.  It was good timing because it was right after the (tedious) data collection for 2011 was completed and right before the (fun) data analysis and writing commenced on the 2012 Data Breach Investigations Report (DBIR).  While the VERIS framework has a lot of obvious things to say (see the DBIR), I suspect there are quite a few subtle secrets still hidden in the data just waiting to be discovered, and discussed.

To that end I wanted to roll up my sleeves and attempt to shed some light on a question I was asked around how many breaches were discovered through active log monitoring and analysis.   Within the VERIS framework, we ask the question “How was the incident discovered?” and in 2011, the answer is overwhelmingly from external entities.  In 2011, Law Enforcement and external fraud detection topped the list contributing to the 92% of breaches that were notified by external entities, but what about that other 8%?  Could we learn something by looking at some successful and active incidents being internal discovered?

VERIS contains a list of 20 ways a breach can be discovered, of which we classify 9 as an “internal active” method.  Which means the victim was actively seeking information or implementing a process intended to educate the organization about their environment.  Of those 9 methods, I’m going to focus the 7 incidents (out of 855 in 2011) that were discovered from “Log analysis and/or review process”.  That’s right, we had a record setting 7 breaches in this category.

The first thing that jumps out is company size: 5 of the 7 organizations have over 1,000 employees and the remaining 2 were in the “101 to 1000” employees, so still not small organizations.   With only 7 cases it’s hard to attribute meaning to these numbers, but could this indicate that actively watching or reviewing logs is challenging for smaller organizations? Possibly, but let’s keep going.

The next odd little set of numbers that stands out is that all of the attacks were carried out by external agents and 6 out of the 7 were targeted attacks.   The external isn’t so surprising (98% of 2011 data is external agents), but 6 out of the 7 being targeted makes one my eyebrows rise up a bit.  To throw more weirdness on that,  6 out of the 6 incidents (one didn’t provide data on the question), listed the actions after initial compromise as either “moderate” or “high” difficulty.  Let me repeat those stats: 6 out of 7 were targeted, 6 out 6 were moderate or high difficulty (after initial compromise).  While my mind races with all sorts of reasons why that could be, I’m going to let that stand all on its own.

The final data point I looked at was the timeline of the attack.  Surely, if the company found out about the breach through an internal active method, it’d have a shorter time from compromise to discovery, right?  Nope, only 2 were ranked as the expected “days” between initial compromise and discovery.  Four of them still listed “months” in that category.  Digging into those 4 specific cases I think I figured how that could be plausible – remember we’re dealing mostly with larger organizations here.  In one of the cases, the review process didn’t even identify the evidence of the attack for over a month from the initial compromise (presumably it was a process executed monthly). In another case, evidence was found of malicious software shortly after the initial compromise, but discovery of the breach itself was delayed by (as best I can tell) underestimation of the incident and the malware chasing took some time. Even though analysis and responses were a bit delayed for these lucky 7, the review process triggered an investigation that helped remediate faster than any other method. 

Perhaps we should be taking solace in the fact there were seven breaches detected by an internal process like this.  Seven is more than double the amount we saw in 2010 and perhaps this is the start of an upward trend… right?

We welcome these collaborators and firmly believe the more data we can share with the industry, the better we can understand and prepare for the threats we collectively face.  With the addition of Verizon’s 2011 caseload and the combined data from our collaborating agencies, the DBIR series now encompasses  2,500+ breaches, 8 years and over ONE BILLION compromised records. As always, the DBIR includes only confirmed data breaches worked either by Verizon or one of the aforementioned agencies.  We believe that with each passing year, the data grows and evolves helping to paint a more complete picture of the current state of cybercrime. We always look forward to sharing the resulting analysis with our readers and hope you find it informative, enjoyable and helpful to the planning and implementation of your security efforts.  You can pick a copy up here. Please let us know what you think either via this blog, on twitter (#dbir) or at the email address listed in the report.

On Monday, we did a quick lightening talk at Mini-Metricon on some of the things we’ve been doing lately with respect to attack modeling and analysis. If you missed it, you can check out Appendix A in the soon-to-be-published 2012 DBIR for a recap.

At B-Sides, we presented a talk titled “Your IR Team: More than Firemen and Maids.” The central principle was that organizations should use their incident responders for more than putting out fires and cleaning up messes. Instead, also think of them as generators of valuable data that can inform security decision-making. In working with both the IR and risk
management sides of many organizations, we so often find that these two groups do not share information to the degree they could/should. Decision-makers constantly decry the lack of useful security data at their disposal, yet they have a “treasure trove” right under their noses. We’ll post the preso once the B-Sides crew has the chance the get it up. Until then, you can check out the hand-sketched version here.

Regarding that talk, one attendee had the following to say:

“By my count, the fourth B-Sides SF talk this year to heavily feature
statistics and suggest setting metrics. The presentation made an argument
for formally tracking and classifying incidents, for instance using the
VERIS framework. The talk was quite compelling and did a good job
illustrating how incidents can be charted and visualized.

Unfortunately, when I visited the VERIS wiki I found it rather
disorganized. To me, the wiki doesn’t do a good job of communicating how
the framework can be implemented and throws up a wall of words rather than
diagrams and practical implementations. In all fairness it is under
construction, and does give some example, but more concrete tools would be
welcome. If someone would release a spreadsheet template or simple app
(Python, Ruby, etc) to jump-start organizations on their incident
classification, that would be a huge public service.”

This is a fair critique, and not the first time we’ve heard these sentiments expressed. We definitely realize we have some work to do to make VERIS as usable as we know it can be. To start, we are updating the wiki to reflect the latest version of the VERIS Community framework. It is still, however, a “wall of words.” Over the last several months, we’ve made strides to change that. We’ve created an XML schema of the VERIS framework (currently in beta), a UML diagram to better help visualize the structure, and have begun conversations about open source tools. We’ve also realized that if we’re really going to achieve our goal of widespread VERIS adoption, we need to up our development and support of it. We’re making hires and prioritizing efforts to do that.

Bottom line – we hear you. We’re working on it. If you’d like to give us some input on what we can do to make VERIS more useful to your organization, please let us know. If you’d like to use and provide feedback on the beta XML schema, we’ll be glad to point you in the right direction. For either of these, or to register any other helpful criticism, we’re all ears at veris@verizon.com or @verisframework.