 |
Prat Moghe is the founder and CEO of Tizor who led the launch of its product into the data auditing market. Prat is responsible for driving corporate strategy, technical vision and day to day operations.
Read More »
|
|
|
 RSS Feed
Often enterprises think of monitoring tools as a way of providing visibility into breaches that might be happening under their noses.This use is like a “whistle-blower” or early warning system that alerts you to risks. There is however another value proposition around monitoring tools which is as critical but often gets overlooked. It is what I call the use of monitoring for breach-validation or breach-verification or correctly for verification of lack of breach. Monitoring tools can actually quantify or substantiate a data breach in terms of how many data records or systems were compromised. This can help separate minor incidents from major devastating incidents.
Here is a recent case in point. The Best Western hotel chain incident is in the news. Apparently the The Sunday Herald reported that August 21 , "a previously unknown Indian hacker successfully breached the IT defenses of the Best Western Hotel group's online booking system and sold details of how to access it through an underground network operated by the Russian mafia." The report claims that records of every customer to have booked a room at one of the Best Western's 1,312 continental hotels since 2007 -- 8 million -- were taken. The Best Western hotel chain has responded by accusing the paper of being sensationalistic. It counts a mere 13 records that may have been exposed as a result of "suspicious activity." In a public statement, Best Western questioned the Sunday Herald's story, saying that it "is grossly unsubstantiated" and that the paper's claims about its customer records "are not accurate." "We have found no evidence to support the sensational claims ultimately made by the reporter and newspaper," the statement says. "Most importantly, whereas the reporter asserted the recent compromise of data for past guests from as far back as 2007, Best Western purges all online reservations promptly upon guest departure." In an e-mail, a Best Western spokesperson said,"There was one instance of suspicious activity at a single hotel with respect to 13 guests, who are being notified. We are working with the FBI and international authorities to investigate the source of the other claims, which were never presented to us for investigation prior to publication of the Herald story. We have found no suspicious activity to support them." A data activity monitoring (DAM) system or a DLP system with audit logs could very well have validated this breach (or its absence).
The recently published Verizon Data Breach Study, 2008 Data Breach Investigations Report, has some remarkable analysis on data breaches. Based on analyzing a collection of 500 forensic investigations over four years, the study describes interesting patterns that emerge from detailed understanding of data breaches. It is important to note that while the Verizon study has a large sample size; it is biased because it only contains investigations of Verizon customers. Even so, this study has a few statistics that are worth noting. One interesting statistic deals with the threat of "unknown unknowns" and the need for data risk assessment.
What is an unknown unknown?
The Verizon study defines an unknown unknown along one of four dimensions - a system, a data store, a network connection, or privileged access.
1. Unknown system - a system unknown to the organization or business group affected by the breach
2. Unknown data - a data store that the organization did not know existed on that system
3. Unknown network connection - an unknown network connection or access used by the data breach
4. Unknown privileged access - a system that had unknown accounts or privileges
How often is there an unknown unknown involved in a data breach?
90% of data breaches involve an unknown unknown! This, I think, is a truly remarkable statistic. In essence, unknown unknowns seem to be a lead indicator for data breaches.
How is the threat of unknown unknowns distributed?
The figure shows the distribution of unknown unknowns. 66% of data breaches involve unknown data, 27 % involve unknown network connection, 10% involve unknown system, while 7% involve an unknown privileged access. Vast majority involve unknown data - data that the organization did not know was present on the system.
Implications for risk & threat management: What can we do about unknowns?
Threat management may be more black and white than gray
In a sense this points out that most breaches are caused because of an inadequate visibility of the most critical elements of an organization system - its critical applications, its critical data assets, its network connectivity, or privileged access flows. This problem is relatively straightforward to fix since it involves visibility of a relatively small number of critical elements. This is good news. Imagine if this were not the case. If data breaches had involved mostly known elements, both detection and risk mitigation would have had to become more sophisticated around behavior.
Step 1 - Data: The dominant unknown
This analysis shows that 66% of data breaches have an element of unknown data or data store. This points to the need for data discovery (to find databases) and data classification (particularly for critical data assets like SSN, credit cards, and PII information). If such stores were to be found and inventoried, their security would automatically be raised. The simplest first step is to discover the unknown data. It also covers dominant number of breaches, so this step has a huge return on investment.
Step 2 - Data activity risk assessment: cover all unknown unknowns
The next important step is to do a data activity risk assessment - that is to monitor the flows around critical stored data in databases & fileservers (discovered in step above). These flows can show all access activity around stored data. From these activities, simple risk assessment reports can be generated that shed light on the remaining three unknowns accounting for 44% of data breaches:
- Unknown privileges - Discovering and classifying privileged activity with roles should be part of a basic risk assessment exercise. Additionally, high risk privileged activity (such as failed logins, privilege escalation, error codes, access to customer data) should be framed as high priority risks and escalated.
- Unknown connections - Discovering and tracking connections based on access protocols, applications, IP addresses, and hosts should be another part of risk assessment. High risk connections (such as ad hoc activity outside normal applications, activity outside typical set of hosts or IP addresses, etc.) should be framed as high priority risks and escalated.
- Unknown system - Discovering all systems (such as databases and fileservers) that have critical assets should be a basic part of risk assessment.
Very few people actually know how the TJX breach happened. Here is the sequence based on Attorney Joel Lisker's testimony in US District Court (Master Docket No. 07-10162-WGY). Joe Lisker is the Senior Vice Chairman of Dudinsky Lisker & Associates, LLC. Previously he was the SVP for Security and Risk Management for MasterCard International.
As we see below, the attack itself happened in two phases. In phase 1, the attacker penetrated and found the target - in this case, the stored Track 2 data. The attacker also managed to extract this data out of the TJX network. In Phase 2, the attacker actually installed software on servers to get at all Track 2 data being transacted. This data was subsequently retrieved without setting off any alarms.
Actual Sequence
The figures below show a highly simplified picture of the TJX infrastructure and illustrate the attack in steps.
Phase 1: Breach initiation
(1) Initial breach of the TJX system likely happened as a result of deficiencies in the wireless network used by TJX. At the time of the attack, TJX employed WEP wireless encryption at the store location, with some known deficiencies. Part of the problem was that the network broadcast SSIDs - the service set identifier name assigned to the wireless network by the administrator.
(2) After breaching the TJX wireless system, the attacker was able to gain administrative privileges to the RTS servers located at the TJX corporate headquarters in Framingham, MA. The RTS servers hold all cardholder data that is processed centrally for most TJX stores.
(3) Once the attacker was able to gain administrative privileges to the RTS servers, he was able to find historic Track 2 data improperly stored by TJX on these servers.
(4) The attacker then used FTP to copy this Track 2 data to another machine on the Internet, utilizing TJX's high-speed internet connection.
Phase 2: Breach escalation
(5) Until this point, the attacker could only get at historical stored Track 2 data. Now it gets audacious. To get at new data, the attacker actually installed custom written traffic capture software on the servers!
(6) The attacker used the software to record live TJX transaction data. The software tool was configured to extract the payment card track data from the transactions. This track data was then stored in tool's log file, unpretentiously called just "log".
(7) The attacker used this tool to copy and extract Track 2 data from payment card transactions from May 2006 to December 2006.
The net impact of this attack?
Estimated likely 100 million unique account numbers affected by the breach, of which one attack alone compromised 42 million payment cards (12 million MasterCards, over 25 million Visa cards).
In a subsequent post, I will outline security technologies that could have caught the TJX breach in action.
By now, everyone has heard about the Hannaford breach. As always, there is confusion of facts and the effect on consumers as well as retailers, banks, and service providers. I am going to do a series of posts around this breach since it has special implications for several reasons:
1. Hannaford was the first big retailer to have a breach in spite of (allegedly) being PCI Compliant.
2. Hannaford apparently did not store any customer names, yet the data theft resulted in fraud
3. Since many of the chain's customers use debit cards to purchase groceries, this breach could have more painful fallout for consumers than the TJX breach (which was focused on credit cards).
Today, I will explore the first theme - the breach and PCI Compliance.
Background:
According to Digital Transactions (March 17). 4.2 million credit and debit card numbers were exposed in a breach that happened between Dec. 7 and March 10. As a result, 1,800 cases of fraud are believed linked to the breach.
Hannaford's president and chief executive, Ronald C. Hodge, indicated that the hacker or hackers obtained card numbers and expiration dates during the authorization process, implying possible illicit access as data moved between point of sale terminals, electronic cash registers, or servers.
Apparently, Hannaford vice president of marketing Carol Eleazer told Digital Transactions News, "We were certified [as PCI-compliant] last spring and we were re-certified in February". Hannaford's PCI assessor is not known at this point. Eleazer did not have further details on Tuesday about exactly how the fraud happened, saying it is under investigation by the U.S. Secret Service and experts inside and outside the company. But she does say that Hannaford had been using data encryption all of last year. In fact, she adds, "in 2007 we had just recently upgraded our wireless encryption."
Breach & PCI Compliance:
The question is if Hannaford was indeed PCI compliant, why did the breach happen? Does it mean that PCI compliance is worthless? I have seen some talk about this in the blogosphere. See Rich Mogull's incisive comments at securosis. I maintain that the reality is actually exactly the opposite.
Many people think of PCI Compliance as "fool proofing" their environment against breaches. It is not. PCI Compliance is actually the lowest common denominator of security - it is a practical program of basic security that any environment that handles large number of customer and credit/debit cards should have in place. Unfortunately, most environments are so broken that they view this program as a "white elephant" they cannot afford to take seriously. It is natural in that case that the few who do take PCI seriously, expect it to work wonders and keep data safe. The reality is that PCI Compliance gives them the foundation of security that allows them to "know" where they are. Without PCI Compliance, they would be completely lost.
Think about it - PCI Compliance should not be a big deal. For the core infrastructure, it asks for a firewall, basic segmentation of the network, IDS (monitoring the network), a quarterly scan for vulnerability, strong passwords on key servers, and monitoring cardholder systems. For any data being handled it recommends storing only need-to data and using encryption or masking. This is not extreme security; this is basic common-sense security.
But why doesn't PCI compliance ensure against breaches? Simple - breaches can happen as long as there is a single weak point that can be compromised in a long complicated chain of data flow. It is not a question of if. It is a question of when and how much effort is applied. In response, the level of security has to rise -- though this usually happens slowly. As an analogy, think of terrorist attacks. In spite of huge spending, there is no way to guarantee an attack from happening. This does not minimize the value of basic airline security checks.
Why not make PCI about extreme security? Some have argued for new security controls to be added to PCI requirements - see Eric Ogren's PCI post as early as April of last year in Dark Reading. For a longer discussion on this check out my old post Why data security cannot stop data theft.
Recently I was chatting with Avivah Litan, VP Distinguished Analyst at Gartner. Avivah is well-known for her commentary on privacy, fraud and breaches. She mentioned that one statistic we lack in the security industry is the actual probability of a breach and, subsequently, a conservative average cost or fallout. Well, we may have the makings of this statistic in the model discussed in my last post
(a) Assuming – and this is an approximation (but one that is easily refined by measuring the size of companies in the Attrition database) – that the breach stats discussed in my last post are measured over the last three years, across Fortune 5000 companies. There were a total of 813 breaches. This means that the probability that a Fortune 5000 company will see a breach is roughly 813/5000 or 16%.
(b) If a breach happens we know that on average we lose 50,000 records per moderate breach. I am ignoring large events, because they are rare enough to skew this analysis and create skepticism on the part of business risk management. For many organizations, the probability of a large loss breach may be less than the probability of other business risks occurring. This means that the organization will give those other business risks higher priority--investing money in mitigating the non-breach business risks first.
(c) Using public data records stating that cleaning up one data loss costs $182 we can determine that on an average a breach costs 50,000*$182 or $9MM per year. This means that, conservatively, breached organizations will lose $9MM.
(d) Combining (a) and (c), we can find the “expected value” of breach-related financial cost, or the expected “risk” in dollars. The expected yearly cost of breach-related losses for an enterprise is 0.16*$9MM or $1.4MM.
What conclusions can we draw?
(1) Data breaches and security spend: It is clear why, in spite of all the hype, breaches do not drive security spend. As we can see with the results above, the expected dollar risk of breaches is less than $2MM yearly. For a Fortune 5000 company, the choice between making security investments, that could cost several million dollars in addition to FTE, versus suffering a moderate breach, that will cost less than $2MM yearly, is a simple one.
(2) Compliance and security spend: In the absence of breach risk, compliance will continue to drive security spend in the foreseeable future. The reason behind this is that compliance may be tied to contractual obligations (ex. if you are an outsourcer who cannot do business without a clean compliance certificate, you are much more likely to take it seriously.)
(3) Will breaches ever be taken seriously? I think so – there are two ways that I see this occurring. First, in a circular way, compliance may force the laying of a monitoring/auditing foundation which will make breaches much more visible. (There is a general feeling that breaches are underreported. Part of the problem is that technologies to monitor data disclosure are just now being put in place.) With higher visibility, both the frequency of breaches and expected losses may increase. At the point where the expected value of annual breach losses increases beyond say $20MM – you will see a clear shift in spending priorities. Second, if the large loss incidences continue to increase and reach the point where they are not perceived as rare (today it is at 3%), there may be a psychological shift.
50K: The Magic Data Loss Number
If you haven't already seen it, the ITRC (Identity Theft Resource
Center) put out their year-end press release. It noted that 2007 was a
year of record breaches. They concluded that 2007 had 443 breaches with
127MM losses, vs. 315 breaches and 20MM losses in 2006. This means 40%
growth in breaches between 2006 and 2007.
After reviewing the ITRC data, I started digging through public
records. I wanted to understand if there was some pattern here and what
it meant for security practitioners. The more I dug, the more
interesting it got. I am still digging and analyzing, but here are some
preliminary findings. As always, I'd like to get your take.
I used the Attrition database, which reports slightly different numbers than ITRC. My analysis spreadsheet is posted here,
feel free to download and double-check my math. To start with, the raw
numbers look alarming. Based on the Attrition data, raw data losses are
163MM (2007) vs. 46MM (2006) vs. 55MM (2005). Also, the numbers of
incidents are 330 (2007) vs. 346 (2006) vs. 137 (2005).
This data is interesting, but I was curious as to how the number of
losses was distributed. As we know, the large loss events cause more
notification problems & expense, as well as embarrassment and brand
risk. When I plotted the loss distributions across the three years,
what jumped out was that there were very few large incidents that
completely skewed the statistics. Take a look at Figure 1 vs. Figure 2.
Figure 1 shows loss distribution across all incidents. It is clear that
events with more than 10MM losses dominate the distribution in Figure
1. Next, I decided to filter the picture and take out all events with
more than 1MM losses. Why 1 MM? This is an arbitrary cutoff, but it
feels natural that any incident with more than a million losses will
have sufficient punitive and visibility factors to cause a structural
impact on the enterprise that suffers it. Lets call such events "large
loss incidents" versus incidents that have less than one million losses
("moderate or damped loss incidents"). If we filter Figure 1, and
remove all large loss events, we end up with Figure 2 - the moderate
loss distribution. I ran some stats on both these distributions and
here is what I found.
Moderate loss incidents vs. Large Loss incidents: The vast
majority of incidents fall into the moderate losses category in Figure
2. Over 97% of incidents are moderate in size! In fact, of the 813
incidents over the past three years, only 21 incidents are large loss
events -- over 1 MM losses. Further, only 4 incidents have crossed 10
MM mark - perhaps the catastrophic large loss threshold. Why is this
important? Because if the vast majority of events are moderate in size,
this is going to influence the security spend in the field. Large
events can cause media hype, but if they are so rare, they may have
little operational impact on security. By the way, the number of large
events have gone up from 5 (2006) to 10 (2007), but I don't think this
is a meaningful enough number to change the perception that large
events are rare.
Moderate losses have not increased much year to year: The
total number of moderate losses has not increased a whole lot - 12MM
(2007) vs. 14MM (2006) vs. 6MM (2005). In fact, the total number of
such losses in 2007 was lower than that in 2006.
50K - The Magic Loss Number: One final question is - how much
data do we lose in each moderate loss incident? It turns out that the
average loss per moderate loss incident is roughly constant! Yes -
across all three years - it is roughly 50,000 losses per incident.
(Precisely, this loss was 55K (2005) vs. 50K (2006) vs. 45K (2007)). It
is premature to call this a "loss constant", but it feels like there is
something structural behind this. By the way, the moderate loss
distribution has a very high variance- the standard deviation is
typically way over 100,000. This means that moderate loss events have
either very little loss, or high loss - they are not necessarily
clustered around the average.
In my next post we will take a look at the probability and financial
risk of a breach. In the meantime, take a look at these numbers and let
me know what you think.
Diana Kelley’s Background:
Diana Kelley is the service director and vice president of Burton Group. Among her areas of specialization are information security; compliance, policy and risk management; and software and application security. She has over 16 years of experience creating secure network architectures and business solutions for large corporations. Her previous positions include CA, KPMG, Safe3W (acquire by iPass), Hurwitz Group, and Symantec. She is the co-author of “Cryptographic Libraries for Developers”.
Prat: How did you get into the security line of work?
Diana: Actually, I was an English major and trained and worked as editor. Out of the blue, I got an opportunity to pick up networking in late 80’s when my publishing house wanted to network sites. In five years, I was heading network mgt, figuring out email, firewalls and secure ftp. Next, I started my consulting company to help companies figure out how to get access to the internet. Many of the companies in Boston were first wired with TIS Gauntlets – some of which my consulting company installed. Then I went to KPMG where I got exposed to a whole variety of security and risk management technologies such as the early IDS, radius, and web access management systems.
Prat: What’s the role of a good analyst?
Diana: A good analyst enables a good “forward conversation” between marketing, customers, and products. She helps sort out “Does it do what is supposed to do”? Buyers are confused and aggressive marketing/sales by vendors don’t help.
Prat: Do you think the security industry has more confusion compared to other technologies?
Diana: In security, the goal is to “secure” – this is a hard objective to quantify. In other technology areas, such as say “collaboration software”, the goal is relatively concrete. For example, “Does the software support 100 users or 1000 users?” This is much easier to evaluate. In contrast, how do you easily quantify network, database, or application security?
Prat: What are the major changes you have seen in the security industry in the last 2-3 years?
Diana: First, compliance has created a compelling driver for IT/security spend. Previously, security spend was based on “fud” (fear, uncertainty, doubt) and the “cost thing” – reaction was always “why are we doing it?” Now compliance is saying “if we don’t do it we will suffer”. This has created drivers to help enterprises think of security in a more planned way. Second, GRC (governance and risk controls) are also framing this discussion at an executive risk management level. It is no longer just about adjusting the WAP settings on an access point at the bottom level -- but linking this from the top level down to the IT level.
Prat: If it is all about compliance and governance, how come we are seeing increased data leakage spend now? How do the data breaches play into the compliance spend?
Diana: Data breaches are really spurring “breach notification” – where if disclosure happens the enterprises have to report the disclosures. That drives the data leakage market. In that sense, this is still driven by “privacy compliance”.
Prat: A while back, I did an analysis (How is data lost?) of data breaches and found that over 60% of losses happen from databases – the core datacenter, way ahead of laptops or classic email leakage. What’s your take on this?
Diana: I buy it at a macroscopic level. “Why do bank robbers rob banks? Because that’s where the money is”. I see three reasons behind this:
- Insiders have fewer controls than outsiders – it is an easier task to subvert these
- Data is exposed much more widely now, so newer attacks can penetrate more easily (SQL injection)
- Databases mean larger data in one place – this means more risk. It is easier to get at this than try to hack an SSL session.
Prat: Where is security headed?
Diana: In a perfect world, security is seamlessly embedded within the fabric of business – like risk management. In reality, it will probably continue as a separate organization for the next 10 years.
Comments (0 )
This week it was reported that Monster Inc. was breached. Check out the following links:
ID Attack Widens with 1.6M Records Stolen from Monster.com
Monster attack steals user data
Data thieves hit Monster.com site
What is interesting about this breach is that it exposed relatively mundane customer data – probably not social security data or credit card data (though we won’t know for sure until the investigation bears results). However, the impact was still significant, since the customer data was used to launch a Phishing attack on the unsuspecting resume owners, to ultimately subvert their PC’s and gain access to their financial data or extort them.
Many of the enterprise IT and security staff seem surprised, including the Monster folks who are reported to have said “this was not an identity theft, this was legitimate customer information”. In reality, this type of attack is nothing new but every bit as dangerous as a critical data breach. I remember two years back when there were a series of email Phishing attacks that started with a relatively innocuous data attack. The sequence is always the same:
- Some form of a masquerading (as a credentialed user) compromises legal accounts
- Use of account information in #1 to gain access to legitimate data stores containing customer data of varying sensitivities
- Use of customer data in #2 to establish trust with customers
- Using the trust in step #3 to install software and gain malicious control, or possibly gain even more sensitive data and account information
Interestingly I had written about this topic 2 years back in one of the security magazines where I hypothesized that if the loop between step 4 and step 1 were to successfully close, this would lead to truly massive and intensive data and asset/identity theft. It is not clear in the Monster case whether this loop closed. But it does make us security practitioners aware of the pitfalls of any breach, even if it does not expose truly sensitive data.
Comments (1 )
Certegy has just announced that its data theft by an internal DBA was much worse than they thought. Apparently 8 million records were compromised, instead of 2.2 million as believed earlier. This led me to revisit the incident and its interesting implications around forensics. There are two observations worth noting around the Certegy data theft. The first observation is well-known: traditional security tools did not detect the data theft when it happened. The second one is not as obvious: after data theft was suspected, forensics could not prove this theft. This is an important implication that all incident investigators need to understand about data breaches. As many data breaches happen at the "database-level", traditional forensics tools that focus on PC or outbound electronic channels (emails etc.) may not capture evidence of the breach.
To understand the Certegy incident, check two sources out:
- Ben Worthen of Business Technology News interviews the SVP of marketing and corporate communications at Fidelity National Information Services (FIS)
- FIS put out a fairly detailed press release on July 3. It is worth reading.
Forensics did not identify or prove the root-cause of the breach. In fact, after FIS/Certegy was alerted by customers of a potential breach, they used forensics focused on firewall activity. Naturally, they didn’t detect any external breaches. This absence of firewall activity pointed to the possibility of an internal breach. However, forensics could not prove this conclusively nor identify where the breach occurred. A separate "non-electronic" investigation proved the linkage between an internal DBA and the theft. As it turns out, all of the check-paying customers were receiving communication from one company, which happened to be the company started by a Certegy employee - the malicious DBA. Were it not for this direct linkage, the root cause may have never been found.
How to bridge the "forensic gap"
If Certegy had used database auditing, they could have had access to "non-repudiable" database access logs. This could have directly identified and proved that the DBA’s hand was in the cookie jar. In fact, with the combination of auditing and analytics, such tools could proactively alert. For example, the moment the DBA accessed more than X customer names in a transaction or over time, an alarm could have been tripped. In my conversations with enterprises I have learned that the focus of data loss prevention is moving rapidly to the core databases. The forensics gap is critical and must be addressed.
Comments (0 )
Richard Stiennon talks about the need to monitor data activity of insiders, particularly around the database. The Certegy data theft incident originially related by Ellen Messmer is interesting. A trusted Database analyst walked away with millions of customer records from his employer, Certegy. He sold the data to a broker who in turn sold it to marketers. Like many other incidents, this one only came to light after one of Certegy's check-processing customers alerted Certegy to the correlation. Much after the incident. Database activity monitoring could have caught this in real-time. One more for the "could have, should have" records.
Comments (0 )
Previous Page | All Posts | Next Page
Error sending email
Email sent successfully
|
|