2009 DBIR: Unknown Unknowns
Peter TippettApril 14th, 2009
I am totally fascinated that, as sophisticated as our enterprises are, computer crime follows the same basics as water (seeks the lowest point, leaks from the softest spot) and chains (that break at their weakest link). We chant and rant these sort of ditties endlessly, yet our spending and protection strategies often make security stronger where it is already strong, and ignore, or don’t even look for, the weak spots.
Figure 30 in this year’s study shows that in over half of all cases (and a much higher percent of records lost) the data that was breached involved relatively simple things that took the victim company by complete surprise. In Figure 30 (pg 34), “Unknown Data” was a problem in over 1/3 of cases and about 2/3 of all records lost.
When we get called in to handle a case we typically meet with the IT staff on the first morning to reassure them and to get some basic information so that we can quickly diagnose the issue. Usually someone knows that records were lost, but doesn’t know how. We ask: “Where would records like those be stored and processed??” The staff answers something like “over there on machines A, B, C and D.” We ask if we can put a sniffer on the network among machines A, B, C, and D. When we do, we typically see 95%+ of the traffic moving among these devices, but we often see a small percent of traffic also going to machines “P,Q, R, S, and T.”
“Where are P,Q, R, S, T?” “Well,… they are not critical….” “Yes, but where are they?” “They are over in the next building…” So we go over to the next building, and by noon (commonly) we find that the attack happened at P,Q, R, S, or T.
The company knew they had the sensitive data. They knew it was important to protect it. They worked hard and had many protections around A, B, C, and D, but the attack didn’t happen there. Instead, in 38% of our cases, representing 67% of all records breached, the attack happened (on servers) where the company didn’t expect the data to be. In other words, on P,Q, R, S, and T. This is what we mean by “Unknown Data.”
In another 24% of cases we found a dedicated internet connection to an ex-partner, or to a strange country (or somewhere else unexpected). A typical response is: “Huh?” or “We fired those guys four years ago!”
In another relatively common scenario (17% of our caseload representing over half of all lost data) the breached server had default accounts (accounts with the same password as hundreds of others), or extra accounts that had no business being there. These weren’t stealth accounts. No trickery. They were just there for anyone to discover.
These are the “unknown, unknowns”. But unlike some unknowns, these are eminently knowable.
The common characteristic is that these things are relatively easy to discover. After all, we discover them usually in the first half of the first day with something as simple as a sniffer. If we can do that, why can’t these victim enterprises?
As security professionals, we often don’t do the simple things to find simple problems such as these. I think it has to do with the “perfection problem.” The simple approaches typically won’t find every case since none of the quick and easy techniques are anywhere near perfect. And people won’t buy (or sell) tools that would miss 5-10% of the problem. So we wind up doing nothing.
Just as the doctor “screens” people for heart disease, not by doing the expensive (more perfect) test on everyone, but by quickly assessing age, smoking, obesity, cholesterol, and family history. If you have all five indicators, you are going to get further tests. If you have none of these attributes, the value of doing the “gold standard test” is practically nil.
Discovery is very easy (if you use 80/20 indicators), but very difficult if you are trying for 99.99. My vote: go for the 80/20 and get it done. A dozen years ago we discovered this UU problem and, sometime later, began scoring each computer among our “Security Management Program (SMP)” customers. We have had more than 1,000 customers and have a huge amount of data from these simple “inference scans.” This year we developed a network based assessment (Virtual Discovery) that evaluates our customer’s internet traffic patterns. Both can be done even in very large enterprises in 2-3 weeks. In nearly every single case we found things that made the IT staff cringe. Virtually all could spell trouble. Nearly always, they are easy and quick to fix. They are the weak links.
Tell us what made you cringe. How do you use the 80/20 rule to discover big problems that are easy to fix?
Peter Tippett
Tags: 2009 Data Breach Report, Computer Crime, Cybercrime, Data Breach Report, Data Breaches, Data Compromise, forensics, Information Security




