Threat Modeling

“Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized. The purpose of threat modeling is to provide defenders with a systematic analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker’s profile, the most likely attack vectors, and the assets most desired by an attacker.”

Mostly used during system design.

Basic questions:

• What are you building? (model of a product)
• What can go wrong?
• What are you going to do about it?

Multiple frameworks for threat modeling exists:

• STRIDE
• PASTA
• Trike

Attack Trees

“Attack trees are diagrams showing how an asset, or target, might be attacked. Attack trees have been used in a variety of applications. In the field of information technology, they have been used to describe threats on computer systems and possible attacks to realize those threats.”

Can be used during the system design but also as an evaluation on any existing system.

Bruce Schneier on attack trees (nice PGP example inside):

“How do you create an attack tree like this? First, you identify the possible attack goals. Each goal forms a separate tree, although they might share subtrees and nodes. Then, try to think of all attacks against each goal. Add them to the tree. Repeat this process down the tree until you are done. Give the tree to someone else, and have him think about the process and add any nodes he thinks of. Repeat as necessary, possibly over the course of several months. Of course there’s always the chance that you forgot about an attack, but you’ll get better with time. Like any security analysis, creating attack trees requires a certain mindset and takes practice.”

Cyber “kill chain”

Military concept related to the structure of an attack later adopted by Lockheed Martin as a method for modeling intrusions on a computer network.
Defensive steps can be derived from those as well.

OODA loop

OODA loop is an observe–orient–decide–act cycle developed by an US military strategist.

OODA loop applied to a cyber kill chain:

• Observe: attacker is searching for an entry points for his operation - DNS records, certificate transparency, IP ranges, technology stack used, authentication methods, …
• Orient: process the inputs collected from the reconnaissance, use tooling to find out wohat is relevant to an attack
• Decide: decide which attack vectors are feasible based on a previous analysis, select / “fix” targets and the techniques required to exploit them
• Act: exploit the vulnerabilities / exfiltrate data / do a harm to an organization

As a defender, our primary objective is to have a faster OODA loop cycle. If we are able to iterate faster than the attackers, we can disrupt their loop. The ideal scenario is that the attacker never finish the loop. As a first step, we should have better observability into our own systems, so we can better orient, decide and act.

How To Proceed

If we are about to introduce security within already established environment, we have to roll it in multiple steps.

Define Attacker

Example threat actors:

• malicious insider
• accidental insider
• malicious outsider (script kiddie / nation state)
• natural (fire, flood)

Divide program to a multiple deliverable phases (example!):

Things we as a security team can do:

• identify current problems in existing tech stack
• process existing data in a better way, collect complains from the SOC operators
• are we scanning known infrastructure periodically? what we collect, what we learn from it?
• fingerprint devices on subnets, track the changes over time, correlate with services and activity, build asset database
• prepare user stories for common attacks (malware infected node in DC, ransomware against the database, stolen laptop)

Define most common attacks with high possible damage:

• ransomware
• remotely exploitable CVE
• weak SSH settings
• remote desktop access
• ???

How to identify attacker stories ?

• empiric knowledge from the real world attack
• create/find existing attack trees for our internal assets
• blue/red teaming

Story: Attacker is a ransomware operator capable of programming. She is searching for any system access that allows her to encrypt company data at scale and blackmail company later.
Target systems: all database systems, all storage, …

Story: Script kiddie found a wat to SSH to one of our cloud based VMs.
Is somebody alerted about the successful SSH? How do we find out that it was not legitimate?

Future

Reiterate the whole process, find out what was not accomplished, add more sofisticated attacks to a backlog (insider theads, …)