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.

Threat Intelligence

7/31/2019
10:00 AM
Brandon Levene
Brandon Levene
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

The Attribution Trap: A Waste of Precious Time & Money

Aiming for attribution doesn't help most organizations become more secure. It can actually have the opposite effect.

When it comes to cybersecurity, the world is obsessed with attribution. We see sensational headlines all the time that question, speculate on, and purport to confirm the identities of attackers. Often, there's an immediate impulse to answer "who" when triaging and responding to incidents, but that's not the correct path in most cases. Many security leaders operate under the false premise that "who" equates to "how," a notion that is not only counterproductive but dangerous.

Companies are under constant attack, often struggling to respond and mitigate quickly to assess the damage. Teams need to move fast to figure out how attacks happened so they can take steps to prevent them from happening again. This means directing attention to the impacted data and devices, the specific attack method, and how to shut the access points that may be left exposed. Fixating on the threat group behind the attack takes time, energy and resources away from performing the practical measures that are necessary to keep the organization's network secure.

Consider the following scenario: the CFO of your organization has fallen victim to a well-crafted request to transfer funds to a third party (a technique known as business email compromise). Trying to figure out who is behind the attack won't protect against similar attacks or help recover stolen funds, trade secrets, or other pilfered property.

Attribution research is a distraction that most IT and security teams can't afford, a waste of precious time and budget. Instead, teams should gain a thorough understanding of what happened and perform a technical analysis to answer questions like: How did the intruders get in? How did they access the data? Where was the money transferred to? Which accounts were used?

Let's use a ransomware attack as another example. As attackers move away from spray-and-pray techniques and toward more manual opportunistic attacks, organizations need to understand how ransomware is deployed, instead of focusing on which "Spider" group is deploying which malware. Organizations should address this risk from a perspective of "how does X facilitate Y?" In this case, understanding how externally accessible management protocols enable ransomware deployment is a far more critical consideration for defenders than researching attribution.

In my 10 years as a security analyst, I've found that the top priorities after an incident should be these:

1. Understand your assets.
Security teams are chronically understaffed, underfunded, and undersupported, and time is the most expensive and limited asset. Cycles spent on determining attribution are better spent elsewhere. Teams should be laser-focused on learning their networks, understanding how mistakes happen, and developing plans to prevent future incidents. They should ask questions about their network and endpoints, prioritize visibility, and learn from previous mistakes and known architectural quirks.

2. Use your threat data.
Most organizations don't capitalize on the massive wealth of threat data available to them or effectively use their own environments to validate threat data. Instead they rely on the data's source to dictate prevalence. But robust overall defense posture and threat assessment via hunting contribute more value than attacker identification.

Experienced threat hunters understand and distill fundamental, actionable intelligence and use this data to proactively identify potential compromise. To them, "who" is just one of many labels that can help organize tactics, techniques, and procedures (TTPs) and should be considered a postmortem activity, a component of an "after-action report" or lessons-learned phase.

3. When the "who" matters.
There are some exceptions to the "ignore attribution" rule. Knowing who is behind an attack can be helpful for mature organizations that have defined defensive practices, adequate visibility, and well-constructed threat hunting and intelligence teams. For the companies that can handily answer the "how" and the "what," attribution can be part of assessing potential adversaries and allowing organizations to prioritize their defensive efforts.

Attribution is helpful for investigations conducted by the larger security community, too. Approaching investigations from a perspective of "how would threat actor X do this?" can be a useful construction for threat researchers and law enforcement in their threat hunting. Distinctive groupings of adversary behaviors also allow for more streamlined threat sharing among peers, creating space for greater industry collaboration.

While it may be tempting to let curiosity govern your first steps, organizations should avoid falling into the attribution trap. Instead, they should examine their overall security programs, learn what and where their assets are, and analyze the data. Aiming for attribution doesn't help most organizations become more secure. Instead, it can actually have the opposite effect when you put off more basic and effective incident response measures to conduct "who done it?" research.

Related Content:

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Brandon Levene leads the Applied Intelligence team at Chronicle (VirusTotal). Prior to Chronicle he was a founding member of threat organizations at Salesforce.com and Palo Alto Networks. View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19698
PUBLISHED: 2019-12-10
marc-q libwav through 2017-04-20 has a NULL pointer dereference in wav_content_read() at libwav.c.
CVE-2019-4428
PUBLISHED: 2019-12-09
IBM Watson Assistant for IBM Cloud Pak for Data 1.0.0 through 1.3.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session....
CVE-2019-4611
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 168519.
CVE-2019-4612
PUBLISHED: 2019-12-09
IBM Planning Analytics 2.0 is vulnerable to malicious file upload in the My Account Portal. Attackers can make use of this weakness and upload malicious executable files into the system and it can be sent to victim for performing further attacks. IBM X-Force ID: 168523.
CVE-2019-4621
PUBLISHED: 2019-12-09
IBM DataPower Gateway 7.6.0.0-7 throug 6.0.14 and 2018.4.1.0 through 2018.4.1.5 have a default administrator account that is enabled if the IPMI LAN channel is enabled. A remote attacker could use this account to gain unauthorised access to the BMC. IBM X-Force ID: 168883.