⏩ GIVEN WHEN THEN Threat Modeling

The Threat Gazette
1

Ever wondered how to not get water bombed by children in summer?? :sweat_droplets: :sweat_droplets: :sweat_droplets: :wink:

I’ve had a fun time exploring the capabilities of :fast_reverse_button: :play_button: :fast_forward_button: GIVEN WHEN THEN Threat Modeling! :slight_smile:

:fast_reverse_button: :play_button: :fast_forward_button: GIVEN WHEN THEN is a threat description template.

What I find particular interesting is that it develops Attack Defense Tree equivalent expressiveness, as soon as we start to reuse and refine conditions and also work with those structures.

As an example, I implemented a probability propagation simulation based on those structures. :robot: We can see how input probabilities at the sources spread through the system.

Here’s the write-up and demo - featuring :light_bulb: inspiration and insights, :pencil: threat model editor and :robot: simulation and some example threat models.

I’m curious… :speech_balloon: :speech_balloon:

  • Do you have any feedback?
  • What were your experiences with GIVEN WHEN THEN?
  • When working with GIVEN WHEN THEN… Have you “connected the dots” and worked with those structures?
  • I’d love to include more cool examples. :smiling_face_with_three_hearts: Would you like to contribute?
  • What’s missing?
Attack Trees + Attack Defense Trees
Visualizing attack trees
2

I’d like to share how feedback from Raphael Ahrens took GIVEN WHEN THEN to the next level:

He bridged GIVEN WHEN THEN and Petri nets and provided beautiful graph drawing!

3

GIVEN WHEN THEN is a familiar syntax for software engineers and QA professionals using BDD. An issue, based on reading your examples, is that the meaning of those words seems to be different for you than for BDD.

For QA and software engineers:

GIVEN implies the artificial generation of system state for testing purposes ( e.g. “GIVEN I have a user”, implies a step to create a test user)

WHEN implies the execution of the system behaviour being tested. You use this to describe attacker behaviour.

THEN describes an outcome, which superficially matches your meaning but for BDD implies an assertion - a step that measures some system states and throws an error if the state does not match an expectation. Your version of THEN is more like a forward-looking GIVEN, implying the situation has changed, not necessarily the system.

Your second structure asserts probabilities for the conditions described, which makes it very apparent you are doing different work with this model. In BDD the probability of a state after GIVEN or THEN in BDD, for a working test suite is 100% and the aim is to keep it at 100%. Scenarios are (normatively) independent and combining scenarios is a breakdown in design discipline with terrible consequences for team productivity.

You seem to be trying to estimate the implied probability of a condition based on a situation evolving in any of various ways, based on the combination of all the scenarios, and the state of the attacker and the system. Combining scenarios is your goal. Scenarios should link and a break in a link is a terrible disaster.

Since your goals and requirements are thoroughly different, perhaps you should use a different set of keywords? If you retain these keywords, then every conversation that you hope will be using familiar terms will actually start from a place of confusion.

1 Like
4

Thank you for sharing your observations.

I see your point in the difference of semantics.

Let me think about this and get back to you… :slight_smile: Happy new year!

5

You got the semantics right. Let’s talk about language features, expressiveness and better names!

STEP / TRANSITION

Groups a set of GIVEN WHEN THEN conditions. May be executed or not.

The Gherkin thing is called SCENARIO, so the new name already implies that this will be part of a sequence.

Petri nets would call this a transition.

GIVEN a / IF a / PRE a / REQUIRE a / WITH a

a needs to be true so that the STEP can invoke.

Petri nets call a transition “enabled” when it “may fire”. That is like saying all of it’s GIVENs are true. See also Petri net - Wikipedia

THEN b / GIVE b / POST b / WIN b / ACHIEVE b

b will be true after the STEP was invoked.

GIVEN + THEN is the smallest language set that already is fun. We can start with an initial setup, then turn things from false to true. We might also denote GIVEN a GIVEN b THEN c as a & b => c. Invokation order does not matter. Things terminate when everything is true, latest.

We can run Monto Carlo simulations based on that and combine investigations with initial probabilities like in the first publication.

WHEN c / ON c

The non-deterministic event c that may or may not happen that invokes the STEP.

In a simulation, that non-determinism is hard to handle. My simulation treats WHEN like a THEN. From a probablistic point of view, we might replace WHEN y with GIVEN y would happen THEN y did happen. But that is not exactly the same as a thing that may or may not happen.

In a Petri net, WHEN and STEP are the same thing - a transition.

UNLESS d / NOT GIVEN d / IF NOT d

d needs to be false so that the STEP can invoke.

UNLESS was introduced as a future work idea in the first publication

It is quite tempting to introduce this, because mitigations will always need to be negated otherwise, like in GIVEN mitigation is NOT holding the attacker back. On the other hand, if UNLESS d is combined with other THEN d steps, this will cause rules to be taken out of the game. We have full decision expressiveness and can model NP-complete problems like SAT or CLIQUE.

GIVEN AWAY e / TAKEN e / CONSUME e / LOSE e / SACRIFICE e

e must be true so that the STEP can invoke - like in GIVEN. e will be false after the STEP was invoked.

This is what Petri Nets do all the time. Like discussed in the second publication it adds insane expressiveness. Petri Nets also go from a false/true model to a number model and check / increase / decrease counters. Consuming inputs adds decision support and invites NP-complete problems. Execution order matters. Reachability and termination computations may become hard problems.

Conclusion

Those are my thoughts. What do you think, @sjgibbs ? How do you like the alternative names?

CommitStrip about how naming is hard
CommitStrip about how naming is hard650×615 173 KB

6

Yeah… naming things is a thing.

I think ACHEIVE or ACHEIVES is clear. UNLESS is also pretty clear. The best of the keywords for preconditions is IF, but I’m not sure I love it. I also like LOSE, but didn’t see an example of that.

Gherkin allows for an AND between steps with the same keyword.

For the event ON seems pretty clear, but there is an argument for WHEN

If I wanted to explore more options I might consider GRANT, or SET as an alternatives for ACHEIVE. (SET state to be true…)

Let’s try it out:

STEP Attacker finds InApp SQL Injection
IF Attacker can act as logged-in user

AND Attacker is clever and knows how to find SQL Injection

AND InApp has SQL Injection vulnerability

WHEN Attacker finds InApp SQL Injection vulnerability

SET Attacker knows SQL Injection SELECT vulnerability

I think that all reads fairly well, and does not collide with the opposite understanding BDD users would have.

Where no event is required to trigger the outcome then perhaps some syntax-sugar is helpful for brevity?

IF Attacker knows valid credentials

SET Attacker can act as logged-in user

could be accepted in this optional form

STATE Attacker knows valid credentials

IMPLIES Attacker can act as logged-in user

It might be sufficient to make SET/IMPLIES synonymous and STATE/IF synonymous, but “STATE.. IF” and “STATE … AND” would probably cause confusion, so there are risks and complications in achieving that extra brevity.

Does this language have a large user base you can try it out with?

Simon

1 Like
7

I like that.

A good tiny example (with your keywords) is

STEP
   IF I have a key
   WHEN I lock the door
   SET the door is locked

 STEP 
   UNLESS the door is locked
   WHEN the attacker opens the door
   SET the attacker is inside

I feel SET is a bit too technical, booleanish, procedural. I like that it is short.

UNLEASH / UNLOCK / CAUSE could work but is long. Also, UNLOCK the door is locked is funny. I need the opposite word, too. TURN ON/OFF? IGNITE? FIRE? INVOKE? START/STOP?

Not so easy…

8

Time to consult your user base, examine real examples etc etc.

I’m glad this draft doesn’t seem to clash with Gherkin :+1:

1 Like
9

The language needs

ALIAS A=B

for multi language support, custom keywords and right side name abbrevations.

ALIAS IF=GIVEN
ALIAS ON=WHEN 
ALIAS SET=THEN

:germany:

ALIAS FALLS=IF
ALIAS SOBALD=WHEN
ALIAS DANN=THEN

ALIAS ServerTakeover = Attacker took over the server

ALIAS ALIAS = Nowit'sgettingweird
Nowit'sgettingweird GIVEN=THEN

:winking_face_with_tongue:

I wish there was a user base.
AFAIK there’s people who commented on the PoC and people who use GIVEN WHEN THEN for threat descriptions, aware or unaware of my work.

Also, I hope that it helped shape a mental model and connect two methods that were previously different.

10

I tested :germany: WENN ... DANN KANN ... at work and it seems to work good with newbies.

German WENN is both conditional or temporal. Can be IF / AS SOON AS. So covers the original GIVEN and WHEN. DANN is THEN. KANN is CAN - modal verb introducing that effect still may or may not occur.

I’m always surprised how powerful language is. There’s a lot of possible variants…