Model-based Risk Management
for Socio-Technical Systems –Report on the TRESPASS Project

Dieter Gollmann
Hamburg University of Technology

2About the speaker• PhD on a topic in cryptography, 1984
• Research on cryptographic algorithms & protocols,
foundations of computer security, risk analysis– Container transport, German e-health card, now TRESPASS• Course director, MSc in Information Security, Royal
Holloway, University of London, 1992 – 1997
• Microsoft Research Cambridge, 1998 – 2003
• Chair for Security in Distributed Applications, Hamburg
University of Technology, since 2003
• Now JSPS Invitational Fellowship at Kyushu University

3Agenda• My views on the intrinsic challenges in risk management• Report on the way these challenges are addressed in theEU research project “Security is a people problem”– Be they part of the problem, be they part of the solution,
people should be part of the model• Acknowledgement: talk uses slides from project partners• Talk gives my view, not necessarily the project’s view4?

192.168.2.0/24

192.168.1.0/24
VM
1

VSW
1

VM
2

VFW

VSW
2

3*-#4.5&1.2$-&

From
IT security

VM
3VR

VM
2!

VM
3

VM

192.168.3.0/24

Hypervisor
HostComputer

VM! VM

Hypervisor
Host
Computer!"#$%"&'()$#*+%,(!"#$%"$#(-.#$%"&'(/&#$*&0("#$%$&'()*+*,#-./0+&1.2$-&

VM1

5Towards
socio-technical systems

skillsgoals

resources

6

TRESPASS project 2012-2016•! EU FP 7 Integrated Project, funding ! ! 10,000,000•! Seventeen partners, large companies, SMEs, academia•! Expertise ranges from visualization to model checking tocriminology

7

TRESPASS use cases• Use cases to guide the project• Obtained from industry partners and industry contacts• For validating methods and tools developed• To pose new research questions

8Parasitic business models(tariff misuse of call termination)
callCall termination fee
TSP A pays calltermination charge toTSP B (per minute)
TSP A

TSP B

Fixed/mobile/virtual
IP connection pointwith TSP A

Fixed/mobile/virtual
IP connection pointwith TSP B

Mr. Clever9Model-basedrisk management• Capture requirements – anamnesis• Model system / organization, requirements, attacker• Construct executable models• Evaluate, analyze, communicate (visualize)• Decide10

Capture requirements
recordanamnesis

executablemodelvisualize
analyze11

Fundamental dilemma ofcomputer security• Security unaware users havespecific security requirements
but usually no security expertise• Risk management iscommunication• How to get this communication
started?

12

Facilitating communication• CORAS: earlier EU project on model-based risk analysis– Stage 1: staff describes organization
to security experts– Stage 2: security experts describe
organization to its staff• TRESPASS– Explores use of Lego building blocks in brainstorming sessions

http://heim.ifi.uio.no/~ketils/coras/index.htm

13

14

Model organization
recordanamnesis

executablemodelvisualize
analyze

15

Fundamental challenge inmodel-based risk analysis• Capturing and aligning two intrinsically different
views of a system, the operator’s view and theattacker’s view
• Operator’s view framed by intended use of the system– Includes features relevant for describing operation of the system– May include defenses against anticipated types of attacks• Attacker’s view
– Can be approached in two ways

16

Attacker’s view – 1• Extend operator’s view: attack points and attack patterns– Alignment of the two views is comparatively easy
– View on attacks may be blinkered by too much familiarity withintended use of the system (“Betriebsblindheit”)– May miss attacks exploiting features outside of the system model• Artful attackers explore gaps between operator’s modeland actual system to find levers for an attack– If it is provably secure, it probably isn’t [Lars R. Knudsen]– Models are abstractions; gaps MUST exist

17Attacker’s view – 2• Create attacker’s view independently of operator’s view
• Some information about the system must be available• Attacks identified at this stage may turn out to be
infeasible because of specific features of the system
under analysis that had not been considered– “But this attack is not possible because …”– System model needs to be refined• Aligning the two views tends to be more challenging

18

TRESPASS system model(operator’s view)• Represented as a directed graph• Nodes can be– Locations, in physical space (e.g. rooms) or in cyberspace (e.g.
network nodes, virtual machines)– Actors, e.g. people and processes; these nodes can move
– Assets, can be attached to locations or actors, can be annotatedwith metrics• Edges define various physical and logical connections• Description language with formal semantics

19

TRESPASS system model– quantities• For actions, time to perform action, risk of detection
when performing it, and cost of performing it• For actors, likelihood of a social engineering attack to be
successful and risk appetite of actor• For locations, risk of detection at this location (forexample due to surveillance cameras)

20

TRESPASS system model– behavior and policies• Domains limit where processes can move
– Human actors restricted to room nodes, computer processes
restricted to network nodes• Possible to define the behavior of actors• Policies, both access control policies and security goals– “To access the account, a PIN is required”– “This data item must remain confidential”• Attacks treated as policy violations

21

TRESPASS system model– example

22

Attacker’s view
• Attack trees for structuring brainstorming about attacks• Attack tress augmented with
– Attributes: likelihood, cost, time, skill level, …
– Defense nodes (attack-defense trees, also work in TRESPASS)• Tool support (also work in TRESPASS, ADTree tool)• E.g. pruning of trees with respect to attacker profiles

23

24

25

Parasitic business models(tariff misuse of call termination)

call

Call termination fee
TSP A pays calltermination charge toTSP B (per minute)
TSP A

TSP B

Fixed/mobile/virtual
IP connection pointwith TSP A

Fixed/mobile/virtual
IP connection pointwith TSP B

Mr. Clever

26

TREsPASS model
Actions

Descriptionin

Waiting for incoming
actionout

Outgoing action to otheractors

Operators

Description!

Waiting for an input

dot(.)

Sequential actions||Executing actions inparallel@“from” where the action is
performed

27

Value modelling using
e3fraud28

Analysisrecordanamnesis

executablemodel

visualize
analyze29

Fundamental challenges
in analysis and evaluation• How to deal with uncertainty?
• How to deal with complexity?
• How to deal with dependencies?
• How to achieve completeness?

30

Uncertainty• How to model uncertainty?
– Subjective probabilities (Bayesian approach)?
– Frequencies (frequentist approach)?
– Other mathematical frameworks, fuzzy theory, etc.?

• Do we have the data and do probabilities work at all?
– Expectations that mandatory reporting will improve the situation– Current disillusion in the UK about data-driven approach– “We had lots of data on the financial markets but did not foresee
the crisis of 2008 …”– “In security the past is a poor indicator of the future!”31Complexity• Divide-and-conquer is a powerful strategy– E.g., attack trees break down a high-level goal into basic actions– Easier to assign metrics to basic actions than to high level goals• How to return from divide-and-conquer?
– Methods for combining metrics for subsystems to achieve
compositionality• How to deal with dependencies?

32

Completeness• How to avoid missing out on attacks?
• Brainstorming is a creative but informal process,may miss attacks that are obvious in hindsight• TRESPASS explores the use of model checking forsystematic attack discovery

33

TRESPASS
analysis methodology• Start from an attack tree
• Convert attack tree into an executable stochastic model– Interactive Markov chains– Markov automata (choice + time-dependent success probability)– Priced (weighted) timed automata (basis for model checking)• Check for security properties in the executable model– Ideally, cover all possible executions of the system

34

TRESPASS
analysis methods (sample)• Computational analysis methods for attack trees– Extended to attack-defence trees– Pareto-optimal solutions considering multiple attributes• Statistical model checking of timed automata– Derive results from several simulations of the system– Scales better than normal model checking– Deals with uncertainties in input values• Model checking for policy violations– Delivers attack traces if a violation is found– Deals with completeness35

Analyse36

Understanding
human actors• Experiments on stealing laptops (in the past) and door
keys (within TRESPASS) at Twente University• Prevention campaign in key experiment significantly
reduced vulnerability of people in an office environment• Key-fob reduced cases of handing over a key to an
attacker from 62.5% to 37%

37Cues and warnings
experiment• Asked people in a shopping mall for email address, halfof bank account number, data on online shopping• Cues to cybercrime didn’t reduce cases of revealing data
• Warning leaflet decreased revealing of emails addresses
but not of bank account information or online shopping• Differences due to changes in context, from a quiet officeenvironment to a square in a shopping mall?
– J-W. Bullée et al.: The persuasion and security awarenessexperiment: reducing the success of social engineering attacks

38

Visualize
recordanamnesis

executablemodel

visualize
analyze39

Visualise40

Conclusions

41

TRESPASS work flow

42

Innovation 1•! A process
methodology tosupport risk analysis
in socio-technicalenvironments

43

Innovation 2•! New and improved
attack navigation tools
to support these risk
analyses of sociotechnical attacks•! A portfolio of tools – nota single tool chain•! Many extensions ofopen source tooling44

Innovation 3•! New visualisation
techniques to enhance
the presentation ofcomplex socio-technicalattacks•! Designed to :–! Highlight important
information–! Better scalability

45Summary• TRESPASS includes human actors in its models• Attack tress currently constructed manually, automatic
generation under consideration– But would this be sufficient for capturing attacker’s view?

• TRESPASS moves risk management from descriptivemodels to executable models• Validation of methods in various case studies withindustrial partners, more in the final project year

46

Next dissemination event
January
TREsPASS winter school on Security in Socio-Technical13-15, 2016	   Systems	  • Organizers: Christian W Probst, Rene Rydhof Hansen• Technical University of Denmark, Campus Lyngby• http://winterschool2015.trespass-project.eu/

47

Security by design
is an oxymoron• Core question: is data driven analysis right way forward?
– TRESPASS started from this assumption but where can it get us?

• Is risk management about avoiding unforgivable
vulnerabilities?
– Automated tools are the way forward towards complete coverageof known attacks• Is risk management about avoiding awkward surprises?
– If you can predict something, it is no longer a surpriseContact
www.trespass-project.eu
contact@trespass-project.eu
Twitter: @TREsPASSProjectContact us to join our public mailing list!
The research leading to these results has received funding fromthe European Union Seventh Framework Programme(FP7/2007-2013) under grant agreement n° 318003 (TREsPASS).
This publication reflects only the author’s views and the Union is
not liable for any use that may be made of the information
contained herein.