 |
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
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.
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.
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.
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.
With the Super Bowl just a few days away let’s talk a bit about perfection when it comes to data security. In the AFC Championship game the New England Patriots didn’t play perfect football, but they did stop the San Diego Chargers from getting into the end zone and maintain their perfect record. The Patriots continually modified the game plan to overcome challenges, as they cropped up, to get to the Superbowl. Data security isn’t much different; enterprises need to continually make adjustments to the plan if they want to keep their data protection record perfect.
Traditional data security has been primarily focused on keeping the bad things (or the bad guys) out. That not only includes things like viruses and spam but also targeted attacks by hackers. Solutions such as firewalls, VPN’s, IPS, anti-x gateways, access control and encryption have all been important when it comes to securing data against threats, but they haven’t been perfect, especially when it comes to protecting against data breaches. This means that the game plan needs to change -- the defense needs to be adjusted to respond to the new offensive challenges (data threats).
Securing data against the insider threat (insiders gone bad or hackers masquerading as insiders by using pilfered credentials) has been a particularly challenging offensive move to beat. Overcoming it requires a modified game plan that includes a layered Inside-Out defense (core data servers to the edge). This play includes Making sure the core data servers are secured, monitoring and securing data as it leaves the organization, monitoring data on endpoints and encrypting data when appropriate. Making sure the core data servers are secured. As the Patriots know, protecting the critical assets--in their case the end zone-- is critical to winning the game.
Enterprises must realize that all layers play a specific and critical role in an effective defense. Monitoring and filtering the perimeter is important to secure messaging protocols, and web protocols to ensure that specific data doesn’t leave the company. Monitoring and securing the endpoint ensures that certain types of data are not copied onto peripherals and stolen. Encryption ensures that if content is stolen or lost its value is cannot be leveraged. Auditing, monitoring and securing data in the data center (structured and unstructured data) is the last, critical line of defense.
Inside the data center, databases and file servers contain the bulk of confidential, proprietary, customer related and critical data. This is the “red zone”. And, the red zone defense must be tough enough to stop the determination of the opposition. Adding data activity auditing and monitoring at this layer creates a solid red zone defense, which can help stop a breach, unauthorized access to the data and any misuse of data from privileged internal users.
So, the “Outside-In Defense” is one that all enterprises should add to their defensive play book if they want to stop the offense before they get to the data end zone. No score, no breach and the good guys have the ball back in their possession. Pass the nachos.
Lee Weiner is the director of product management at Tizor Systems and a New England Patriots fan
Comments (0 )
I spend quite a bit of time with enterprises describing the difference in philosophies between classical DLP and Data activity monitoring (DAM). While it is tempting to think of DAM as a core-level data protection (which it can be and is in fact very efficient at), in reality DAM solves a broader problem around business data governance than just leak prevention. The concept of risk, theft and fraud in DAM are much more elevated and contextual than they are for DLP. My previous posts on this went into some detail on this topic. Check out:
Data Auditing and Protection vs. Data Leak Prevention.
Rich Mogull has succinctly described this in his recent post, Definitions: Content Monitoring and Protection And Application and Database Monitoring and Protection.
He puts it so well, that I am just copying his words verbatim (he uses the acronym ADMP in place of DAM):
"More on this later, but I'm starting to see the data security market splitting along two lines. One focused on protecting content in user workspaces and productivity applications. It's starting with DLP but moving towards what I call Content Monitoring and Protection.
On the other side of data security is protecting content in business applications- from your web application stack to internal applications and databases. I'm starting to call this Application and Database Monitoring and Protection, and Database Activity Monitoring is where it's starting.
Since we need definitions, here's my first stab for ADMP: "Products that monitor all activity in a business application and database, identify and audit users and content, and, based on central policies, protect data based on content, context, and/or activity."
For CMP, I'm sticking with my DLP definition (DLP is a terrible term, but I'm not going to fight the market): "Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis."
From Rich Mogull, www.securosis.com
Comments (0 )
James Deluccia IV (Compliance Expert and Author of upcoming book on IT Controls) and I hosted an online seminar focusing on PCI Compliance last week. Bill Bartow moderated the session; Stephanie Weagle did an excellent job of managing the logistics. We had over one hundred Level 1 and Level 2 retailers, financial services organization and energy companies attend the session. All the participants were invited to ask us questions surrounding PCI –James and I went through these questions and provided our thoughts on how to address them. For an on-demand recording of the session, please check out: So you think you're compliant
Here are the top few popular questions (in no particular order):
- What are the key data protection technology investments we should make to keep credit card data safe?
- Should we be concerned with internal threat or external threat?
- What exactly are the retention and encryption requirements for data at rest and data in transit?
- What are the challenges around encryption projects and what are the compensating controls for encryption?
- How do we address PCI 10 Audit Trail requirement? Are log scraping tools or SIM solutions adequate for this?
- What are the expectations when it comes to securing the audit trail?
- How should we discover and inventory where the credit card data is stored?
- What type of reports should we generate and how should we manage the workflow with assessors and auditors?
If you have additional questions or comments, please email me below or at prat@tizor.com
Comments (0 )
Previous Page | Next Page
|
|