 |
Prat Moghe was the founding CEO of Tizor and led the company from 2002 to 2006 including driving the launch of its product into the data auditing market. Prat led Tizor through two financing rounds and established its security and compliance market strategy.
Read More »
|
|
|
 RSS Feed
DLP and DAM are two technologies related to discovery, monitoring & protection of data that are in the news, but often confused.
- Where: DLP is focused on the edge/egress and is evolving towards end-points. DAM is focused on the core data center, around the databases and file servers.
- What: DLP is becoming a security mainstay for many enterprises struggling to assess their edge leakage risk. DAM is has been focused more on compliance of databases, but it is rapidly evolving into broader, core data risk management.
Some good news to help clear up this confusion. Rich Mogull of Securosis is doing a Webinar focused on this topic on Tuesday, July 29, 2008 at noon EDT.
The Webinar is sponsored by Tizor. Check it out: information/registration. I have known Rich for a while now, he is one of the most perceptive security analysts around.
To reference some of my past posts on this topic, check out:
Data Auditing & Protection (DAP) vs. Data Leak Prevention (DLP) – Theft vs. Leaks
DLP is Dead. Long live DLP!
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.
The incident reported yesterday by ABC News has created waves. Apparently the computer engineer who worked at Motorola was caught with hundreds of proprietary documents in her possession. Interestingly, she was caught not because of any data security monitoring within Motorola but because the customs agents at the airport found she was carrying too much cash. This was an example of how weak the general state of monitoring is within enterprises. Three implications: 1. If you are not monitoring, start to monitor sensitive data for theft and leakage I read an interesting study conducted by the Verizon Business Risk team that surveyed over 500 data breach incidents. Apparently 82% of the data breaches could have been detected before the actual compromise, had there been monitoring of event logs. Enterprises need to turn on their data cams. 2. What to monitor? Egress, users, or servers? A related question is where to point the data cam? At each enterprise user? At the egress? At the sensitive data servers? Each of these locations has implications in terms of cost and effectiveness of seeing specific types of data theft attacks. - This particular incident would not have been caught by egress monitoring (DLP – data leak prevention) because the engineer downloaded all the documents to portable drives.
- Laptop-level endpoint agent monitoring could have caught this, but this type of technology is expensive to deploy and maintain. Think of 50,000+ laptops at Motorola.
- Monitoring data servers (DAM - data activity monitoring) would have been an efficient way to catch this theft. Why? Lets do the math.
3. Using DAM to detect Motorola theft in real-time - Monitoring footprint: Motorola has probably 1000+ sensitive servers. 20-30 DAM appliances can monitor all these servers. Not a big expense considering the value of this theft (estimated at $600M).
- Based on the indictment documents, the engineer downloaded 200+ documents between 9 am and 2 pm on Feb 26, 2008. A simple DAM threshold that tracked the number of documents downloaded on sensitive file servers could have caught this in real-time. (Threshold can get more sophisticated, but again most egregious attacks are high volume.)
- The DAM appliance could have sent an alert to the security team. A simple phone call to her boss would have confirmed that this was suspicious.
After a long gap that included much travel, it is time to pick up on my previous TJX post.
But first I got distracted by a post around DLP by Richard Stiennon (Don't think that data leak prevention technology will stop leaks - http://www.networkworld.com/community/node/28864) and Mike Rothman's response to this (What? Data leak prevention actually stop leaks? http://securityincite.com/blog/mike-rothman/the-daily-incite-june-17-2008 ) is as usual interesting.
I see huge benefit to data protection if it can be pragmatic and cut down on big risk items. The problem usually is with expectations - that we expect a zero data risk. This is a complete fantasy which will always end up the way fantasies end - with a rude awakening or usually by taking it out on vendors.
This thread also led me to the question of what really IS an effective data protection technology? As a first step to this, I began to classify key data protection technologies such as DLP, DAM, etc. in terms of where they sit and what attacks are visible to them. The next question was how effective were these technologies in terms of cost and manageability? This led me to develop a framework which can rank protection technologies in terms of both risk and cost. I will describe this framework in the next post.
Stay tuned.
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 the next post, I will outline security technologies that could have caught the TJX breach in action.
In case anyone is wondering how data activity monitoring is supposed to work, the recent passport file breaches are a classic example. With both Senators Clinton and Obama, the breaches were detected because the computer system detected file access out of the norm. We do not have details on whether this norm was based on who they were, or based on pattern of access. The important point is that the systems caught unusual access, probably in real-time – apparently on January 9, February 21, and March 14 in three separate incidents.
Usually enterprises lead security and IT innovation and the government follows. Here, for once, enterprises can take a lesson from the government. Enterprise databases are notorious for not being monitored. It is commonly believed that data breaches (such as TJX, Monster, Hannaford, etc.) are vastly underreported because we do not monitor how data is being accessed. If only enterprise databases were wired with data activity monitoring, we would find out how many critical breaches really happen.
Regardless of the political fallout of the passport breach incident, I do see a valuable technical lesson in security for enterprises.
Comments (0 )
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.
Comments (0 )
I did an article that just appeared in SC Magazine. It is relevant to our recent thread of data security and compliance for two key reasons.
First, I have seen an increase in media inquiries around security of SaaS. This might be a good time for a discussion of this topic.
Second, there has been a general confusion of what's a good security model for securing outsourcing activity. The notion that only non-critical data should be outsourced has clearly been thrown out. Look at the practical success of salesforce.com. Consider how many BPO outsourcers have access to your critical financial and credit data today.
My SC article introduces two observations that are based on analogies:
- Access control vs. access auditing: illusion of control vs. real control that comes from knowledge
- Outside-in security vs. inside-out security: security vs. risk management.
I could describe these in detail, but for now a quick example from real-life should drive the point home. Recently I was visiting an enterprise customer who had deployed Mantra DAM to audit their privileged users on Oracle. I was interested in understanding if they would be interested in extending their use to incorporate automated security capabilities (such as terminating users, etc.). I expected the customer to be a whole-hearted fan of this. But the customer shook his head vigorously and said, "Wait a minute - stop!" What I heard from him was very interesting. The fundamental problem of users and how and what they access goes to guts of understanding business & IT activity. This requires some on-going interaction and periodic reviews. The moment the product becomes a self-healing application firewall, this stops happening. At this point, the customer was concerned that they would stop gaining further insight into risks, because the deployment of a system would be perceived as a firewall - eventually making it a black-box with false sense of security and insight. The beauty of a DAM solution is that it gives you insight into what makes sense and what does not - this is the definition of real control provided you use it as such. Access control on the other hand might give you a sense of hard control, but is illusory. Ultimately protecting data while maintaining seamless business transactions is about risk management. Security becomes a by-product, not the means.
I meant to educate the customer, but he ended up educating me.
Comments (0 )
There was an interesting article by John Markoff in NY Times
on Felten's study at Princeton. Felten used an inexpensive can of
coolant to freeze DRAM chips and read private keys. Most disk
encryption products save keys in RAM. Clearly, a simple and elegant way
to beat file encryption.
If you are interested, check out Felten's paper.
Comments (0 )
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.
Comments (0 )
Previous Page | Next Page
|
|