Attacks/Breaches
2/26/2014
08:03 AM
Commentary
Commentary
Commentary
50%
50%

Lessons Learned From The Target Breach

The time is ripe for organizations to take a long, hard look at how they manage employee access and secure sensitive data in cloud environments

For Target, the dust still hasn't settled after its massive 2013 data breach. Months after the theft of 40 million customer credit and debit card numbers and the names and contact information of up to 70 million people, Target is still suffering the consequences. The latest consequence involves a number of lawsuits against the retailer by small banks looking to recover their losses.

According to the Wall Street Journal's Joel Schectman, "So far, seven financial institutions have filed class action suits against Target alleging the retailer didn't adequately protect customer data." The litigation will make the data breach even more expensive for Target than it already is.

For Target, the focus shifted to damage control some time ago. But for enterprises that secure customer, payment, and transaction data in compliance with PCI DSS and other data privacy regulations, the focus now should be on learning. The Target data breach offers a several valuable lessons.

Lesson One: Invest in protection now, or pay the price later (and more)

Data breaches are costly. In addition to fines of anywhere from $5,000 to $100,000 per payment brand, per month for PCI compliance violations, data breaches may also trigger lawsuits from other affected entities, as the litigation against Target shows. In Target's case, banks claim that they might have to "pay millions of dollars to reissue compromised cards and repay customers whose accounts were struck with fraud" thanks to Target's failure to prevent the data breach, Schectman reported.

The banks may also choose to sue for lost business due to customer reluctance to make card purchases after the breach. And speaking of business lost, Target's sales have been hit hard enough for the company to "cut its profit forecast," according to the Financial Times. Target may be able to absorb the damage and eventually recover, but can you imagine the damage a similar incident could do to your brand or reputation? Better never to have to find out.

Lesson Two: Protection must be comprehensive--no point solution is a silver bullet

Lost among the talk of Target's losses is any definitive answer on how the breach happened in the first place. Experts have posited a few compelling theories, each with their own lesson to impart.

The network segmentation theory.

According to Computerworld, the Target data breach "may have resulted partly from the retailer's failure to properly segregate systems handling sensitive payment card data from the rest of its network." Security blogger Brian Krebs claims to have traced the break-in back to login credentials stolen from an HVAC company with access to Target's network. What this teaches us is that network segmentation and tightly controlled access to sensitive data are critical. The "HVAC company" in question was authorized to access Target's network to carry out "tasks like remotely monitoring energy consumption and temperatures at various stores." Why did its login credentials grant access to payment card and customer information?

The takeaway is: Lock your sensitive data down so that stolen logins don't become a disaster. This is especially important in cloud environments, in which you may be sharing network and data center resources with other organizations entirely.

The malware theory.

Many analysts and experts say malware was most likely to blame for the Target data breach, whether that malware infected Target's network itself or the Point of Sale (POS) terminals that originally captured the stolen card information. This highlights an important point: malware defense is a critical part of your overall data protection strategy. Technologies like encryption, key management, tokenization, and DLP get more attention, but you need robust and up-to-date antivirus and malware prevention measures on your endpoints to stay safe from hackers, too. When endpoints can access the cloud, this becomes even more crucial, as infection points and vectors multiply.

The dust still hasn't settled from the Target data breach. More revelations are likely to come, and it wouldn't be a surprise to read about more bad news for Target's bottom line. In the meantime, organizations must take a long hard look at their own security postures, particularly when it comes to how they manage employee access and sensitive data in cloud environments.

What lessons have you learned from the Target breach? Let us know in the comments.

About the author:

Pravin Kothari is a security visionary with more than 20 years of experience building industry-leading companies and bringing innovative products to market. Pravin was the founder & CTO of Agiliance, a leading Security Risk Management company, and co-founder & VP Engineering of ArcSight, a leading security company, which was acquired by HP for $1.6 billion. He holds over a dozen patents in security technologies and is the inventor behind CipherCloud's groundbreaking cloud encryption technology.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
shjacks55
50%
50%
shjacks55,
User Rank: Apprentice
3/15/2014 | 10:14:27 AM
re: Lessons Learned From The Target Breach
By the time you share your intel with others its too late for you. Target breach was "top down". Like when you implement a bad group policy on the corporate top level domain: it spreads to every forest. Military manuals insist on physical security and no binary access to servers (software updates pushed down from Corporate IT to store server to POS should be by sneakernet.)
jmshipe
50%
50%
jmshipe,
User Rank: Apprentice
3/7/2014 | 6:59:40 PM
re: Lessons Learned From The Target Breach
I had the opportunity to read some of the debriefings from the security firm and the Secret Service. Honestly, I don't know how well I could have prepared for such an attack. The odds were certainly stacked against them. Target has a massive implementation of a very popular SIEM that I'm sure is well-tuned and watched carefully. That's how they were able to react in one day rather than in several months like most companies would.

While you can't necessarily prevent the attack, there are two important measures that could have safeguarded the data: point-to-point encryption (P2PE) and EMV technology.

P2PE would have encrypted the stripe data at the Point Of Interaction and kept it safe all the way back to the decryption engine. This wouldn't prevent them from stealing what was coming off of the swiper, but it would render it useless.

EMV technology would make the payload less valuable, because you need the chip that goes with the stripe data. It would make the cards much more difficult to forge.
h00d
50%
50%
h00d,
User Rank: Apprentice
3/6/2014 | 6:30:59 PM
re: Lessons Learned From The Target Breach
Some other comments I would make: In addition to separating sensitive systems from the rest of the network, also be sure to clamp down Internet access in accordance with the system's dedicated function. There may be no business need for employees to be accessing websites and e-mail from a PoS system. If you disallow this access, you greatly reduce the threat exposure.

Also, it is very important to make sure that anti-malware is not only installed, but also monitored and managed from a centralized console. If an attacker manages to disable the anti-malware agent running on a PoS system, or if for some reason, the system just isn't getting its signature updates, then management software will help the admins discover these issues ASAP.

And finally, PATCH. PATCH PATCH PATCH. Windows Updates are your friend!
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?