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
GitHub Named in Capital One Breach Lawsuit
Dark Reading Staff 8/14/2019
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
The Flaw in Vulnerability Management: It's Time to Get Real
Jim Souders, Chief Executive Officer at Adaptiva,  8/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4483
PUBLISHED: 2019-08-20
IBM Contract Management 10.1.0 through 10.1.3 and IBM Emptoris Spend Analysis 10.1.0 through 10.1.3 is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X...
CVE-2019-4484
PUBLISHED: 2019-08-20
IBM Emptoris Sourcing 10.1.0 through 10.1.3, IBM Contract Management 10.1.0 through 10.1.3, and IBM Emptoris Spend Analysis 10.1.0 through 10.1.3 generates an error message that includes sensitive information that could be used in further attacks against the system. IBM X-Force ID: 164068.
CVE-2019-4485
PUBLISHED: 2019-08-20
IBM Emptoris Sourcing 10.1.0 through 10.1.3, IBM Contract Management 10.1.0 through 10.1.3, and IBM Emptoris Spend Analysis 10.1.0 through 10.1.3 generates an error message that includes sensitive information that could be used in further attacks against the system. IBM X-Force ID: 164069.
CVE-2019-7593
PUBLISHED: 2019-08-20
Metasys? ADS/ADX servers and NAE/NIE/NCE engines prior to 9.0 make use of a shared RSA key pair for certain encryption operations involving the Site Management Portal (SMP).
CVE-2019-7594
PUBLISHED: 2019-08-20
Metasys? ADS/ADX servers and NAE/NIE/NCE engines prior to 9.0 make use of a hardcoded RC2 key for certain encryption operations involving the Site Management Portal (SMP).