Attacker Knowledge? Why?

  • 19 May 2023
  • 4 replies
  • 129 views
Brook Schoenfield
Rank
Userlevel 4
Badge

“Understand what a criminal is looking for, why they're going to attack you. Is it because of status, cash, ideology? Understand who the attackers are, why they're attacking you, what they're looking for, information access, data cache. And then you'll understand the persistence of the attack. You'll understand what you need to do to design security to deter that type of attack.” - Brett Johnson, Shadow Crew, the first organized cybercrime community. “Scale To Zero” Episode 2.

Several members of TM Connect and I have had this long-running conversation (really, disagreement): Must we understand attackers or not? Mr. Johnson, former and foundational attacker clearly validates my position that attacker knowledge is essential to understanding the following:

  • Attack surfaces
  • Lateral movements (steps of the attack towards attacker’s objectives)
  • What will be compromised and how (not every successful attack ends in a data breach. consider bot nets)
  • Rating impacts properly

Take for example a diversity training platform that does not require financial information. There’s some sensitive personal information (PII), sure. Names of customers. Company trade secrets. All obvious.

But when we think about potential attackers for this, very specific case, should we also consider those who fight to create monocultures? Facist activists who despise all talk, certainly any training that might involve exploring minority disadvantage, systemic racism? One of these activists’ explicit goal is to create their supposedly “pure” region and government? Are they going to allow an alternate viewpoint to exist, much less teach and advocate? 

I would argue, “absolutely”: one must know one’s potential attackers. The attackers I just described may have little interest in any of the obvious targets (impacts). DDOS will not be enough, I suspect.

Know your attackers!

I perhaps I dare to open one of TM’s nastier can of worms? Let’s go for it!

4 replies

R
Rank
Userlevel 1
Badge

Knowing your attackers is not the same as knowing all the attackers. If we take the very specific case you present about DEI classes/training and change the organization to an outspoken transphobic group, the attack vectors, complexities and vulnerabilities all stay the same, but the attackers change. 

In this way, I think it’s important to know who’s out there and what they are willing to do -- are they a DDoS nuscience meant looking only for attention and disruption or are they suicide attackers looking to expel as much damage as possible with little/no regard to themselves?

I think you make a good case for knowing what’s out there, but I’m not sure it opened any worms. There is always a chance for another 9/11 but is it our biggest threat and where our TMing should start/focus? I’m not so sure. It’s good awareness, it makes a good TMer better, but even if you knew nothing of the possible attack-ers, knowing the attack methods, vulnerabilities, capabilities and how to prioritize them is much more important. IMO

Thanks for the thought exercise (even if I disagree). r/

Brook Schoenfield
Rank
Userlevel 4
Badge

@Roger_RPC You mention prioritize. How do you do that?

I would argue that knowing something about your attackers (not attackers in general, but those who have an interest in the system to be protected) provides important, perhaps critical dimensions to priority.

Let me unpack how attacker knowledge affects risk, which then affects priority.

Considering targeted nation-state vs. cyber crime, these operate at vastly different frequency of activity and huge difference in effort. For criminals, “time is money”. While nation states have resources, persistence, and patience. Really quite different. If any nation-state, cyberwar affects are entirely collateral (we’re all potential collateral damage), maybe I can disregard well-resourced, sophisticated attacks in favour of raising the cost of compromise high enough that criminals “try the site next door”?

Understanding the difference between botnet renters, XXS misusers, and hacktivists who want to disrupt a system’s functions allows me to think through various frequencies of attack, differing sophistication, skill, and effort, which will lead both to better prioritization, but also aligning defence with need.

It’s all about valuable input into that risk rating, which, in the absence of actuarial tables, needs as much data as it can get, in my experience. Prioritizing must be based upon whatever risk rating we can manage in a world of incomplete, usually poor quality information.

Can’t defend against everything; can’t close every vulnerability. 

n1ffl3r
Rank
Badge

@Brook Schoenfield , at our organization we’re working with threat categories to determine “likelihood”.  General “hacktivism” threats raise the baseline likelihood some, specific hacktivism threats raise the baseline likelihood more, specific hacktivism threats + TTPs that match a specific vulnerability raise the likelihood for that specific risk a bunch.  This helps us prioritize against threats in a data driven way based on modifying the risk  with the best intelligence we have.

The above is all great in theory, but the challenges we have are:
a) Collating threat data with enough accuracy and granularity to make it actionable in this way, and
b) Revisiting threat models often enough to react to changes in the threat landscape

Imperfect solution, but certainly best effort for us anyway.

adedayo
Rank

Very interesting perspective @Brook Schoenfield .

 While I agree that understanding the attacker and their motivation is important to frame the threat scenario, I would propose that for defenders, thinking in terms of attacker capabilities and methods leads to more actionable selection of appropriate controls to defend against the threat posed by the attacker. While the adversary may have an opposing ideology, there is a limited effect that they can have on the system to be defended if they do not have the means to attack or disrupt it.
 
Sure, being motivated is an important factor that may cause a determined attacker to search for and obtain the means to attack, but ultimately it is the acquisition of that capability that can lead to a material impact on the targeted system. So, should we rather frame it as a question about the attacker's capabilities instead of motivation? This is no new idea, the FAIR methodology to risk assessment thinks in terms of attacker capabilities and method to achieve an effect vs the defender's control resistance to that capability. That is, how effectively can we mitigate an attacker's ability to attack through a given method?
 
Thus, from a defender's perspective, I would propose that it is more productive to think in terms of attacker capabilities: can they mount a DDoS? What are we going to do about that? Do they have a credible means to deface our website? What are those means, and how should we defend against it? Are they a well-funded organisation that has the means to buy out information operations, or even have sympathisers within our own workforce to pose an insider threat? What should we do about that? Do they have the means to gain access to our data centres to interfere with systems and services? What can we do about that? I would argue that these sorts of questions lend themselves to actionable defender activities that lead to the selection of appropriate controls for credible threats posed by those attackers.
 
I am not suggesting that understanding the attacker (specifically their motivation) is not relevant, in fact, motivations can sometimes play a role in predicting certain attack vectors. For example, state-sponsored attackers may have different objectives and resources than lone hackers, and understanding their motivations could inform defence strategies. However, I wanted to lay emphasis on how a defender might go about turning the attacker understanding to actionable defence steps during threat modelling.
 
Thoughts?

Reply


Terms and Conditions, Community Guidelines and Privacy.Cookie settings
V2