Saturday, August 28, 2021

Common Attack Graph Schema (CAGS) 3.0

 It's been a while since I've updated CAGS. This is an initial post and may be modified to better fit with CAGS 2 later.

SCHEMA

The attack flows are defined with nodes as objects and their individual actions as hyperedges. Nodes maintain their individuals state with respect to security while edges document how state is changed by the edge. Edges also contain the logic to adjudicate complex interactions between inputs.  The attack flow (or graph) in its entirety represents the state of the system (or portion of the system) being described.

NODES TYPES:

  • Datum
  • Person
  • Storage
  • Compute
  • Memory
  • Network
  • Other
  • Unknown
Nodes have a ‘state’ property representing their current state with respect to the actor.  They indicate the  states (confidentiality/integrity/availability, Create/Read/Update/Delete, or object-specific).

EDGES:

  • leads_to
Edges are hyperedges (or, alternately, a bipartite representation of hyper-edges) with with a ‘logic’ property defining the process for translating the inputs into a success at the output.  Another option is to model the edge as a dendrite to represent the input to output logic of the edge.

Edges have a ‘action’ property defining the details of the action. (These may be in ATT&CK, veris, or any an arbitrary language.)

Edges may have a timestamp property to indicate the order in which they occur.  In practice this can be ‘played’ on the graph to update the node states over time.

Use Cases

Aggregation of Events  

Log data comes in as atomic events.  Given any single event, timestamps only reveal that later events cannot be the parent and earlier events cannot be the child, but the timestamp does not explain _what_ the parent(s) or child/children of an event are.  
 
The graph schema should assist in determining the parent(s) and child/children of an event, (for example by defining that an event occurred due to a file, a credential, or another system and, as such, that object(s) or actions ending in that object(s) must contain the parent.  


Motif Communication

It is often helpful when communicating a plurality of actions to communicate the relationships between those actions.  This really will touch on multiple use-cases, but is centered around motifs as bounded portion of a path or subgraph.  


Attack Surface  

A system can be documented using the graph schema to identify the interconnectivity between components and highlight potential paths of attack.  (Note, while many of the prior use cases are based around events (or signal generated from the system, this is based on the _actual_ state of the system and actual actions rather than the events they generate.)  


Attack Graph Generation  

An attack surface generated using the graph schema can be used to plan potential attacks on the system.  This can be used for automated attack simulation such as cauldera, planning manual penetration testing (such as bloodhound), etc.  This likely results in an attack graph, (a plurality of actions to take).  


Analysis  

Event data should be able to be aggregated into paths and graphs.  This data can then be aggregated across data sources (different tools, sites, organizations, etc) and then queried using graph queries to identify commonalities such as common motifs.


Incident Documentation  

After an incident has occurred,  the incident responders can document the relationship between the observed actions (or events generated by those actions) using the graph schema.  


Detection  

A defender wants to define a detection that contains multiple atomic events and how they are related (such as in grapl).  To do this they need both a motif of the detection and the ability to aggregate events to see if they match the motif.


Simulation  

A defender may wish to simulate attacks containing more than a single event.  To do so they need a motif of events and their relationships and the ability to turn that into atomic actions to take/attempt to take.


Incident Response  

After aggregating events, the data can be analyzed using graph tools, neural networks, or other tools to identify things like missing edges (actions the attackers might have taken but where no event exists to document it), nodes (objects that may be involved in the incident, but are currently not included in the investigation), or clustering (to identify assets currently part of the investigation but are unlikely to have been involved).  


Defense Planning  

Given analysis of an attack surface producing an attack graph, the attack graph can then be analyzed to determine thing such as what events will be generated if exercised, nodes and edges central to the attack that might serve as optimal mitigation points, etc.


Risk Analysis  

Given an attack surface, analyze the graph to identify the overall 'risk' associated with it.  The goal is to provide quantitative feedback on the likelihood and potentially impact of cyber threats given threat intelligence.  


Wednesday, February 3, 2021

Can you predict the future? No.

Did you ever wonder why some people succeed and others don't? Why Jeff Bezos is rich? Why a company got breached?  Is it because Jeff Bezos somehow learned what would happen in the future?  Is it because the breached company ignored the obvious future?  No.  No-one can predict the future.  

Let's take an example: Double Pendulums

double pendulum system


Just predict where they'll swing.  Really easy right?  You can model the entire pendulum with two nodes and two edges. Simple.

two pendulum system represented by two nodes and two edges

Give it a try:  https://www.myphysicslab.com/pendulum/double-pendulum-en.html.  Hit the pause button in the upper-right, drag the pendulums to the top where they can drop.  Put your finger on the screen where you think they'll be in 5 seconds, hit play, and count to 5.  How did it go? 


Hmmm.  Let’s try it again.  Maybe if you saw it happen first.  Hit pause, drag them back up, put 1 finger where it starts, run to the count of 5, and put another finger (same hand) where it ends.  Now drag the pendulum back up to the first finger, hit play again, and count to 5.  Is the second pendulum anywhere near your second finger?


You can't predict the future

If you were right you were wildly lucky.  Check out 7 pendulums who's only difference is approximately 1/3rd of an ounce.  It's due to chaotic motion.  Even in a system with just two nodes where we know all the variables, it gets unpredictable very quickly.  Now imagine if your system is something like this:



In this image the color code is as follows:

  • the upper-left brown is the internet.  
  • the five fuchsia nodes to the right are user systems
  • the upper green are the DMZ
  • the blue-green and dark grey are servers
  • orange are management systems
  • light pink is infrastructure
  • grey is a security system
  • light blue at the bottom is a protected enclave.  

That's about two dozen systems. An _extremely_ small IT estate.  And we have little idea what all the variables it may contain.  Compare that to the two pendulum model.  If we can't predict two pendulums what chance do we have with this?


Try to imagine predicting the business climate and how the world will change over the next 20 years.  You need to make choices now that will govern your success then.  Can you (or anyone) do that?


The answer is, of course, no.  Lots of people are making many decisions and some will be right, and some will be wrong. However, for the most part it's not due to the individuals making them.


So what's a person to do?

Give up? Give in? Nah, don’t do that.


In spite of all the uncertainty and the multitude of variables involved, the reality is that most useful systems do not tend to devolve into chaos.  If they did they wouldn't be useful.  Instead, they normally remain in common, steady states. Except for moving from one steady state to another when something changes.


And that's what you should do.  Bet on the average.  The common state.  The place where most things end up.  Don't look at people who succeeded (or failed) spectacularly.  It was spectacular because it wasn't common. They couldn't predict the future and neither can you.  You can bet on the most common outcome though. (As Sir Francis Galton - or Dan Kahneman if you prefer - would call it, Regression to the Mean.)  For security, this means filter email, filter web content, use two- factor authentication, and manage assets.


The other thing you can do is prepare to change along with the situation.  This requires creative people who can devise innovative solutions when there is some new input, as opposed to rather following the usual processes.  This is one of the reasons why quality security operations are essential. Something engineered and built over several years will never cope with a significant shift in information security unless it also shifts.


And in conclusion, don't beat yourself up over it

What happened in the past did not predictably lead to today, for you or anyone else.  And not only does the past not predict the future, but the future doesn’t require the past.  Inverse evolutionary techniques such as Inverse Generative Social Science demonstrate that things could have started completely differently, and we still could arrive right where we are today.  The best you can do is invest in the average and be creative enough to handle the unanticipated.

Monday, February 1, 2021

Simulating Security Strategy

You’ve probably imagined it, right? Lots of little attackers and defenders going at it in a simulated environment while you look on with glee. But instead of spending our cycles on details such as if the attack gets in, let's leave that for the virtual detonation chambers and focus on the bigger picture of attack and defense?


That is exactly what Complex Competition does.  It simulates an organization as a topology and then allows an attacker and a defender to compete on it.  Table 1 provides all the rules:


  1. Gameboard is an undirected, connected, graph. Nodes may be controlled by one or both parties.  One node is marked the goal.

  2. The defender party starts with control of all nodes except one.

  3. The attacker party starts with control of one node only.

  4. Parties take turns. They may:

    1. Pay A1/D1 cost to observe the control of a node.  
    2. Pay A2/D2 cost to establish control of a node. 
    3. Pay A3/D3 cost to remove control from a node (only succeeding if they control the node).
    4. A4/D4 cost to discovery peers of a node.
    5. Pass or Stop at no cost.
  5. They may only act on nodes connected to nodes they control. 

  6. The attacker party goes first.

  7. The target node(s) is assigned values V1-Vn.  When the attacker gains control of the target node X, they receive value Vx and the defender loses value Vx.

  8. The game is over when both parties stop playing.  Once a party has stopped playing, they may not start again.

This allows us to test out a lot of things which include the below:


Does randomly attacking in a network pay? 


Answer: No! (Unless the target of the attack is connected to the internet)


What does it cost to defend?


Answer: anywhere from three to five times the number of actions the attacker took.


What attacker strategies work best if there’s no defender?

Answer: Attacking deep into the network, or trying a quick attack and bailing.


What attacker strategies work best if there is a defender?

Answer: Now the quick attack is a clear front runner.


How does an infrastructure compromise change the attack?

Answer: When the infrastructure is compromised, the attacker doesn’t have to dig deep into the network. (Obvious, I know. But here we can show it quantitatively.)


Now the caveats


All that analysis must be taken with a grain of salt.  It’s totally dependent on the costs of the actions (all 1), the value and locations of the targets, the topology, and the attacker strategy.  None of which are meant to be particularly representative in these simulations.  Also, this simulation is relatively basic, but hopefully it strikes a balance between usefulness and simplicity for this first iteration.


Still, there’s a lot of other questions we could try to answer:

  • When should the defender stop defending / how much should they spend on defense?
  • How else does the location of the attacker affect their cost to reach the target?
  • How does the target location affect the attacker's cost to reach it?
  • How do different topologies affect the attacker and defender costs?
  • How do different costs affect the attacker's chance of reaching the target?
  • What is the relationship between topology, attacker strategy, attacker action cost, and target value?

And eventually we could make it more complex:

  • Add more information to the nodes to help players choose actions
  • Probability of success per edge
  • Cost of action per node
  • Replace the undirected graph with a directed graph
  • Different value for the attacker and defender for achieving the goal.
  • Separating the impact cost to the defender from the goal and having them on separate nodes
  • Allow the defender to take more than one action per round
  • Set per edge success probabilities and costs
  • Create action probabilities
  • Allow the defender to pay to increase attacker action cost (potentially per edge).
  • Allow the defender to pay to decrease the action success probability (potentially per edge).
  • Allow the defender to pay to monitor nodes without having to inspect them

Primarily, though, we simply want to get this out there and give everyone a chance to try it out,   and, more than anything, illustrate the clear need to simulate security strategy. (He said the thing!)