Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics //

Security Monitoring

4/1/2014
09:00 AM
Craig Carpenter
Craig Carpenter
Commentary
Connect Directly
Twitter
RSS
E-Mail
100%
0%

Be Careful Beating Up Target

Target was actually better prepared than most retailers. The real problem lies with the current state of industry threat intelligence and IR practices.

A flurry of stories surfaced recently, including those in Bloomberg BusinessWeek and InformationWeek, highlighting signals of compromise that Target apparently "missed" or even "ignored," resulting in the theft of 40 million credit card accounts. Clearly the Target breach was serious and wide-ranging, as it affected a large number of customers and even hit Target’s fourth-quarter revenue and earnings

Before we get carried away with all that Target could or should have done to prevent its breach, we should examine all that was done and take a closer look at just how different Target’s preparation and response were from those of almost any other Global 1000 firm. What we’ll find is that Target was actually better prepared than the vast majority of its peers across all industries, leading to the clear conclusion that the problem lies not with Target, but with the current state of threat intelligence and IR (incident response).

First, Target did a lot of things right. It had dedicated security and IR teams using multiple advanced tools; according to Congressional testimony by Target’s CFO, the retailer "…spent hundreds of millions of dollars protecting… data and employed more than 300 people on the issue." This was an investment relatively few entities can match.

As with any breach, Target had some missteps and vulnerabilities. First, management was apparently unwilling to move to new, more secure smart-chip-based card systems common in Europe, due to cost concerns. Second, the retailer is alleged to have ignored pleas by its security team to do a more thorough review of its payment system -- likely in part due to the timing of the request, coming a short time before the critical post-Thanksgiving shopping season. Third, many have criticized Target’s failure to wall-off its payment systems from the rest of its corporate network, through which hackers were able to gain access to payment details. 

But was Target’s security posture and IR process really that much different from those of other large corporate and government entities? As The Wall Street Journal points out, "The sheer volume of warnings retailers receive makes it hard to know which to take seriously." But this dynamic is not unique to retailers: Every corporate and government entity today receives more alerts than they can handle -- even with sophisticated anti-malware systems and hundreds of employees dedicated solely to security. It’s the downside to big data: Too much information in a cybersecurity context can be, and often is, harmful.

Exacerbating this situation is the incredibly manual, ad hoc nature of today’s IR. An entity like Target likely gets hundreds if not thousands of alerts every day, from myriad systems, including anti-malware tools (e.g., FireEye), next-gen firewalls (e.g., Palo Alto Networks), and SIEMs (e.g., ArcSight, Splunk, etc.) to name just a few.  Alerts aren’t correlated across each other or typically checked against known good lists, bad lists, or indicators of compromise (IoCs), similar to criminal “watch lists” of mug shots with fingerprints and rap sheets. Each alert typically has minimal detail, is not confirmed against the system(s) in question, and is not prioritized. Thus alerts tell a security analyst very little and all look alike… yet they must be investigated to at least a minimal degree.

Worse yet, gathering even minimal investigative details requires an entirely manual process: Security analysts must manually compare the alert against IoCs, access the system(s) in question, manually confirm that the alert is real (i.e., the system in question are in fact compromised) by grabbing data from the system in question, and then manually comparing this evidence to other bits of data from completely different systems before forming a judgment as to the veracity and severity of the alert. 

For an entity like Target, this manual, error-prone process is replicated hundreds if not thousands of times each day, each a largely separate investigation. While hackers need only slip through once to wreak their havoc, Target must be right 100 percent of the time.  

The issue isn’t Target’s security team or investment in tools, but rather the current state of the threat intelligence and IR practices as employed by Target and virtually all enterprises and government entities globally. These IR practices can be summed up in two words: un-integrated and manual. Until both are fixed with more integrated and automated approaches, we will find ourselves continuing to wonder why firms like Target "missed" or "ignored" alarm bells.

Craig joined AccessData as Chief Marketing Officer in 2013. With the company split in November 2014, he was promoted to President and COO of the newly formed cybersecurity company, Resolution1 Security. Prior to joining AccessData, Craig was VP of Marketing and Business ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
Duane T
100%
0%
Duane T,
User Rank: Apprentice
4/1/2014 | 12:13:32 PM
False premise of manual processes
Target was certified via PCI DSS in September, so some might believe that they were doing what was necessary to secure their data. Unfortunately, Compliance ≠ Security, and malware detection is like a red flashing light and siren. If you do nothing about it, all you can say is that you were warned.

That's why it's about time that these companies all invested in automated incident response systems that lock down a detected threat. What's odd in this situation is that FireEye has an entire "mitigation" partner page for this on their website, and Target did not use any of them. Think about it - if they used automated detection tools, why not use automated incident response tools that reduce manual tasks and eliminate human error? This doesn't have to be that complicated.

Wait, in a few seconds I found NetCitadel, Bradford Networks, and ForeScout as mitigation options.
marcelbrown
100%
0%
marcelbrown,
User Rank: Apprentice
4/1/2014 | 11:43:41 AM
It's Windows, Stupid!
Target was better prepared than most of the industry, yet they still couldn't shake the one simple, inherent weakness that most of the industry still chooses to ignore - Microsoft Windows.

Until companies get serious about moving away from Windows, they aren't really serious about security. You can't be serious about protecting your company and your customers if you build your information technology infrastructure on top of a foundation that is full of security holes.

Sure, let's not blame Target because they seemed to do almost everything right - except the choice of their core technology.
speshul
100%
0%
speshul,
User Rank: Strategist
4/1/2014 | 9:52:31 AM
Seriously?
So we're supposed to take it easy on Target because other companies are just as bad? That's the most insane thing I've ever heard. So because other companies are just as bad at protecting our sensitive personal information, we should be nice?

 

We should be crucifying every last one of them. I can guarantee that all of these companies have I.T. teams that warn them about these problems, but the companies choose to ignore them due to budget or other reasons. Just like Target had been warned by it's team.

 

But yet, we are supposed to go easy on them. Because clearly Target's credit was screwed over right? Their negligence for their customers' information in some way hurt them financially right?! WRONG. The customers were the ones who lost in this, all because of corporate greed.

 

CRUCIFY THEM ALL!
<<   <   Page 2 / 2
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Cybersecurity Bounces Back, but Talent Still Absent
Simone Petrella, Chief Executive Officer, CyberVista,  9/16/2020
Meet the Computer Scientist Who Helped Push for Paper Ballots
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Latest Comment: Exactly
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-14180
PUBLISHED: 2020-09-21
Affected versions of Atlassian Jira Service Desk Server and Data Center allow remote attackers authenticated as a non-administrator user to view Project Request-Types and Descriptions, via an Information Disclosure vulnerability in the editform request-type-fields resource. The affected versions are...
CVE-2020-14177
PUBLISHED: 2020-09-21
Affected versions of Atlassian Jira Server and Data Center allow remote attackers to impact the application's availability via a Regex-based Denial of Service (DoS) vulnerability in JQL version searching. The affected versions are before version 7.13.16; from version 7.14.0 before 8.5.7; from versio...
CVE-2020-14179
PUBLISHED: 2020-09-21
Affected versions of Atlassian Jira Server and Data Center allow remote, unauthenticated attackers to view custom field names and custom SLA names via an Information Disclosure vulnerability in the /secure/QueryComponent!Default.jspa endpoint. The affected versions are before version 8.5.8, and from...
CVE-2020-25789
PUBLISHED: 2020-09-19
An issue was discovered in Tiny Tiny RSS (aka tt-rss) before 2020-09-16. The cached_url feature mishandles JavaScript inside an SVG document.
CVE-2020-25790
PUBLISHED: 2020-09-19
** DISPUTED ** Typesetter CMS 5.x through 5.1 allows admins to upload and execute arbitrary PHP code via a .php file inside a ZIP archive. NOTE: the vendor disputes the significance of this report because &quot;admins are considered trustworthy&quot;; however, the behavior &quot;contradicts our secu...