How decisions are made
A look under the hood at the Prelude Operator brain
Have you read our post about TTPs? This is great foundational knowledge for understanding the concepts in this article.
Machine learning, big data, artificial intelligence… There are a lot of buzz words floating around technology today, circling around the topic of programmatically consuming information and spitting out something resembling intelligence.
Machine learning has a niche category known as automated planning, which is the type of decision making that the MITRE CALDERA framework was originally built around and Prelude Operator has inched even further forward.
Planning is the process of evaluating a set of defined decisions and determining which to do next. You can think of planning as an extensive decision-tree. Each branch in the tree is evaluated in full to determine the possible effects of each decision, ranking each based on some criteria (more on this later), selecting which branch to go down, then re-evaluating, again and again the process continues.
Why use planners in Prelude Operator?
A red team usually has no knowledge of a network when they drop into it. They are blind. They need to make small decisions to determine where they are in relation to where they want to go. A manual red teamer may start by running the following command, to see what user account they have compromised.
whoami Then they may run another command to list the contents of their location on disk.
ls -alEach small decision is made to give context to where they are (the discovery ATT&CK tactic) and that information is used to build toward the next decision.
Most autonomous red team tools use atomic ordering of attack procedures. Meaning, they run them in the sequential order you defined when you created your adversary profile. Operator is designed around planners because it provides a more realistic basis for making decisions. Adversaries are not run sequentially, instead, all the procedures are thrown into a bucket and the planner determines if and when to execute each one, based on the logic embedded in it.
By using a planner, Operator can mimic the behavior of a manual red team operator. After each decision is made, the knowledge learned increases, helping to determine the next move.
Finite state machine planning
Operator contains a default planner, referred to internally as a brain. The brain is baked into the platform and executes by default, without needing your intervention. This brain is designed after a multi-layered finite-state-machine, correlated with the Cyber Kill Chain.
A finite state machine is a mathematical model of computation, which states you can be in one of a set number of states at a single point in time. When you exit the state, you then enter a new state.
In a simplistic case, think about an elevator in a 20-story building. An elevator can be in any of a number of predefined states. It can be moving or it can be at a standstill at any of 20 floors. The state can change, as determined by who gets into the elevator and presses a button. As the states change, the elevator makes a decision to move to the next one.
In an example from Wikipedia, consider a turnstile, used to control access to subways and amusement park rides.
"A turnstile is a gate with three rotating arms at waist height, one across the entryway. Initially the arms are locked, blocking the entry, preventing patrons from passing through. Depositing a coin or token in a slot on the turnstile unlocks the arms, allowing a single customer to push through. After the customer passes through, the arms are locked again until another coin is inserted.
Considered as a state machine, the turnstile has two possible states: Locked and Unlocked. There are two possible inputs that affect its state: putting a coin in the slot (coin) and pushing the arm (push). In the locked state, pushing on the arm has no effect; no matter how many times the input push is given, it stays in the locked state. Putting a coin in – that is, giving the machine a coin input – shifts the state from Locked to Unlocked. In the unlocked state, putting additional coins in has no effect; that is, giving additional coin inputs does not change the state. However, a customer pushing through the arms, giving a push input, shifts the state back to Locked.
The turnstile state machine can be represented by a state-transition table, showing for each possible state, the transitions between them (based upon the inputs given to the machine) and the outputs resulting from each input:"
Shifting gears, the Cyber Kill Chain, developed by Lockheed Martin, is a set of states that an adversary goes through while attacking a computer network. States such as reconnaissance, weaponization, delivery, exploitation and others form a chain of events any adversary will do while performing an attack.
The kill chain was the defacto standard for describing the behavior of adversaries, until the ATT&CK matrix started gaining popularity in 2015.
As such, Operator uses the concept of the kill chain (states of adversarial behaviors) inside a finite state machine model to determine which decision to make next.
It works like this.
When you deploy an adversary, it is full of procedures (abilities) spanning a wide array of ATT&CK tactics. The Operator kill chain will organize your tactics and execute them in this order:
Defensive evasion
Command and control
Discovery
Collection
Persistence
Credential access
Privilege escalation
Lateral movement
Execution
Exfiltration
Impact
The planner will deviate from this kill chain only if there is not enough information to proceed in order. For example, if your adversary contains a Discovery procedure that looks like this:
nmap -Pn -sV #{ip.T1010} Your Operator will not be able to execute it until it collects at least one ip address from a T1010 procedure (you should read about how procedures link together to fully understand the concept of facts and variables). The platform may skip discovery and move on to Collection, or a further tactic, and it will swing back to this discovery procedure if and when it finds a fact to satisfy the variable.
Using a finite-state-machine computational model combined with an ATT&CK kill chain allows Operator to make logical decisions in a similar order as a real human adversary.
Beyond tactics, Operator layers another finite state machine at the technique level. Each of the dozens of techniques are ordered by a reasonable kill chain order, so when Operator is executing within a given tactic, it is also executing within the innermost finite state machine against techniques.
When you import TTPs - whether from a community repo like Atomic Red Canary or from your private collection - they are automatically mapped into the brain and become part of its capabilities. This means that the more TTPs you have, the more options your brain has at its disposal. In the future, we'll be adding the capability for you to reorder the default state machine kill chain, allowing you to customize it for your needs.
Each tactic may have dozens of techniques underneath it. So, it is too verbose to explain here. However, if you open up the docs inside Operator, you can interactively see how the brain will manage the procedures loaded into your application:
Active area of research
At Prelude, planning is an active area of research. Our engineers are working on building new planners which use smarter computational models and better adversarial decision mimicking.
The goal is simple: create a planner to replicate human decision-making. We want to create an intelligent, autonomous planner for cybersecurity, one that balances the effectiveness of each command with the odds of getting caught. This balance needs to loop in a risk/reward system that can dole out rewards for good decisions and punishments for bad ones. This effectively will combine reinforcement learning with traditional machine learning. This is the future we're driving toward.
Why is it important to develop planners alongside the command-and-control center (C2)? If the future of cybersecurity is truly to move into the autonomous space (which we believe) then the only thing holding it back is intelligent decision-making. If we can model a hacker’s brain, their way of applying knowledge in order to determine their next step - on an indeterministic playing field - well then maybe we can build a “super hacker” for the greater good. Such a hacker would apply their knowledge to proactively identify your security holes and recommend smart solutions. And this would happen before you experience a breach, not after.
New planners will be released with future versions of the Operator and the existing (finite state machine) will go through continuous advancements as the team applies new approaches to the problem at hand.
If autonomous decision-making is an area you're interested in collaborating on - whether out of personal interest or as related to your day job - we'd love to hear from you. We believe that Operator offers a unique approach to testing out algorithms in this space. We built it to be a simple to use, yet effective example for advanced decision making.