Overview of the ProSec project

ITUNIVERSITYOFCOPENHAGEN

Cyber-physical Security of Critical Processes for Crucial Functions in Society

Thomas HildebrandtIT University of Copenhagen!!!!End Seminar for ProSecMapping Emergency and Security Processes in the Danish Public Transport Sector and their Dependency on ICT.

!

May 2nd, 2016

(June 2015 to March 2016)


ProSec End Seminar Thomas Hildebrandt, [email protected]

May 2nd, 2016

Program

2

mailto:[email protected]



May 2nd, 2016

OverviewofProSec

3

April&8,&2015&1.&Applicants&&Head&of&project&&&research:"Thomas"Hildebrandt,"Associate"Professor"&"Head"of"Process"and"System"Models"Group,"IT"University"of"Copenhagen.""[email protected]."Telephone:"3142"5279""Affiliated&Researcher&at&IT&University&of&Copenhagen:"Søren"Debois"(Assistant"Professor).""Head&of&research:"Lars"Pagter"Zwisler,"Head"of"Emergency"and"Risk"Management"Programme,"Metropolitan"University"College.""[email protected]."Telephone:"7248"9402""Affiliated&Researchers&at&Metropolitan&University&College:"Laurits"Rauer"Nielsen"(Assistant"Professor)"and"Lene"Sandberg"(Assistant"Professor).""Affiliated&International&Researchers:"Prof."David"Basin,"Zurich,"Switzerland,"chair"for"Information"Security,"ETH"Zurich"([email protected])"&"Raimundas"Matulevičius,"Associate"Professor,"Information"Systems"Security"Risk"Management,"University"of"Tartu,"Estonia"([email protected]).""National&Collaborators:"Myndighedschef,"Ole"Christensen,"Banedanmark,."Email:"[email protected]"Beredskabschef,"Hardy"Olsen,"DSB."Email:"[email protected]"Direktør,"Morten"Marquard,"Exformatics"A/S."Email:"[email protected]"&2.&Project&title&&

Cyber&security&and&ICT&Infrastructure&with&importance&to&crucial&functions&in&Denmark&Mapping'Emergency'and'Security'Processes'in'the'Danish'Public'Transport'Sector'

and'their'Dependency'on'ICT'(ProSec)'&&3.&Concept&Safe"and"reliable"public"transport"is"a"prerequisite"for"the"Danish"society."Whilst"the"sector"has"well"established"processes"for"managing"physical"emergency"and"security"threats,"the"knowledge"of"the"dependencies"on"ICT"infrastructure"and"consequences"of"cyber"attacks,"during"daily"operation"as"well"as"emergency"events"is"fragmented."Consequently,"the"possible"cascading"effects"of"cyber`attacks"on"any"of"the"involved"ICT"infrastructures"are"at"present"unknown.""The"aim"of"ProSec"is"to"develop"and"demonstrate"a"general"method"for&collaborative&mapping&of&ICT&dependencies&for&the&safe&operation&of&crucial&functions&in&society"based"on"an&empirical&analysis&of&ICT&dependencies&and&emergency&management&processes&in&the&transport&sector"and"application"of"a"collaborative"process&modeling&technology&provided"by"Exformatics"and"extended"in"ProSec"with&security&notations.""The"project"will"be"carried"out"by"experts"in"process"modelling"at&IT&University&of&Copenhagen,"experts"in"emergency"and"crisis"management"at&Metropol,"experts"in"security"and"risk"management"and"selected"crucial"operations"at&DSB&and&Banedanmark"and"international&experts&in&cyberQsecurity&and&business&processes.""




May 2nd, 2016

OverviewofProSec

3




Condition Response (DCR) graphs and tool DCRGraphs.net to describe the process and per-formed two rehearsals of the process with domain-experts supported by the simulation tool.The experiments and results of the modelling and simulation of the procecdure has been ac-cepted for publication [] and presentation at the 1st Workshop on Safety & Security Assurancefor Critical Infrastructures Protection (S4CIP) in May 2016, and is briefly summarised in Ch. ??below. In parallel with the empirical studies and modelling experiments, we investigated state-of-the- art techniques for security elicitation, social modelling and security analysis based onformal and semi-formal process models briefly summarized in Sec. ??. Finally, we initiatedinvestigations of how DCRGraphs and tooling could be applied, and possibly extended, tosupport on the one hand social modelling and on the other hand security monitoring andpro-active security enforcement. The former is briefly summarized in Sec. ?? . The latterwas accepted for publication and presentation at the Computer Security Foundations (CSF)Symposium in June 2016, and briefly summarized in Sec. ??. Finally, in Ch. ?? we summarizethe conclusions of the project and proposals for future work.

1.1. Conclusions

TODO: Brief (couple-of-sentences) summary of the project for the impatient reader.

1.2. Participants

The project was undertaken by

• experts in process modelling at IT University of Copenhagen: associate professorThomas Hildebrandt and assistant professor Søren Debois;

• experts in emergency and crisis management at Metropolitan University College: assis-tant professor Lene Sandberg, and assistant professor Laurits Nielsen;

• international experts in security, risk-management, and business processes: professorDavid Basin, ETH Zürich, and associate professor Raimundas Matulevicius, Universityof Tartu.

• domain experts at DSB (principally Brian Nygaard Jensen, “Sikkerhedskoordinator/Be-redskabsspecialist”) and BaneDanmark (principally Keld Almand Jensen, Lead auditor,and Henrik Islin).

Exformatics A/S provided computation time and its dcrgraphs.net collaborative processmodelling and simulation tool. We are grateful to the students of the Metropolitan UniversityCollege participating in the case study and carrying out the first rehearsal of the emergencyresponse process using the dcrgraphs.net tool.

3


1.1. Conclusions


1.2. Participants







3


1.1. Conclusions


1.2. Participants







3




May 2nd, 2016

ResearchQuesAon&Aim

4

1. Introduction

This report summarises the work and conclusions of the research project ProSec, running inthe period June 1st 2015–April 1st 2016. The full title of the project is:

Cyber security and ICT Infrastructure with importance to crucial functions in Den-mark: Mapping Emergency and Security Processes in the Danish Public TransportSector and their Dependency on ICT.

Safe and reliable public transportation is a critical prerequiste for the functioning of Danishsociety. Accordingly, the transportation sector has well-established processes for managingphysical emergencies and security threats. However, the knowledge of the dependencieson ICT infrastructure and consequences of cyber attacks, during daily operation as well asemergency events is fragmented. Consequently, the possible cascading effects of cyber-attackson any of the involved ICT infrastructures during a physical emergency are at present unknown.This leads naturally to the question:

How can we prepare for a cyber-physical attack on Danish transportation infras-tructure, that is, an attack combining a physical and a cyber-security attack?

The ProSec project was carried out by experts in process modelling at IT University ofCopenhagen, experts in emergency and crisis management at Metropol, experts in securityand risk management and selected crucial operations at DSB and Banedanmark and interna-tional experts in security analysis based on formal process models and security requirementengineering based on business processes.

The main aim of the project was to answer the above question by developing, demonstratingand evaluating a general method for collaborative mapping and simulation of processesand plans for the safe operation of crucial functions in society and their dependencies onInformation and Communication Technology (ICT). The first key hypothesis of the project wasthat the recently developed constraint based process modelling notation, Dynamic ConditionResponse (DCR) graphs [] and the web-based modelling and simulation tool dcrgraphs.net []allow for capturing emergency plans jointly with domain experts in a way that allow for thecollaborative simulation and exploration of expected paths and scenarios as well as non-expected paths not described in the existing paper-based plans and rehearsal processes. Thesecond key hypothesis was that the models can be used to identify, model and evaluate theconsequences of dependencies of emergecy processes on Information and CommunicationTechnology (ICT).

The method and approach was first to do an empirical analysis of descriptions of emergencyresponse processes and their ICT dependencies at DSB and BaneDanmark, briefly summarisedin Ch. 2 below. We then selected a representative emergency response process and jointly withdomain experts applied the collaborative declarative process modeling technology, Dynamic

2







May 2nd, 2016

Subprojects

5

&4.&Project&Description&ProSec"will"develop"and"demonstrate"a"method"and"technology"for"mapping,"simulating"and"communicating"ICT"dependencies"within"essential"processes"for"the"safe"operation"of"crucial"functions"in"society"by"adding"security"notations"to"process"modeling"and"simulation"technology"recently"developed"by"Exformatics"and"ITU"and"conducting"an"empirical"analysis"and"joint"process"mapping"sessions,"facilitated"by"early"interviews"(June),"and"two"workshops"(August"and"November)"with"partners"in"the"transport"sector"(DSB"and"Banedanmark)"and"the"international"experts."""The"results"will"constitute"an"important"tool"to"increase&the&knowledge&and&level&of&communication&about&cyber&security&within&companies&as&well&as&internal&an&external&cooperation&in&handling&the&matter,"and"thereby"contribute"directly"to"subject"area"1"(Mapping"the"Danish"ICT"with"importance"to"crucial"functions)"and"4"(Cyber"security"within"private"companies"in"Denmark)"in"the"call"text.""ProSec"consists"of"four&connected&subprojects&(SP1QSP4)"described"in"more"detail"below"and"planned"to"take"place"from"June"15"to"December"15,"2015."The"project"will"coQfinance&a&named&assistant&professor"(Søren"Debois)"at"ITU"for"6"months,"the"hours&for&the&participants&from&Metropol"and"professor&David&Basin,"chair"for"Information"Security"at"ETH"Zurich,"as"well"as"travels&to&and&from&Tartu&and&Zurich"allowing"to"incorporate"international"experience"from"leading"researchers"in"security"and"business"processes."""SP1. Empirical"studies"of"Processes"for"Safe"Operation"and"Emergency"Management"in"the"Danish"Transport"Sector"and"their"dependencies"on"ICT"(Month"1`6."Lead:"Zwisler."Other"members:"Basin,"Sandberg,"R."Nielsen,"Hildebrandt"and"Debois)"SP2. Development"of"method"for"Collaborative"Mapping"and"Simulation"of"ICT"dependencies"in"emergency"and"security"processes"with"importance"to"crucial"functions"in"society"(Month"1`3."Lead:"Debois."Other"members:"Hildebrandt,"Zwisler,"Sandberg,"Matulevičius"and"Basin)"SP3. Demonstration"of"Collaborative"Mapping"and"Interactive"Simulation"for"Identifying"and"Communicating"Cyber"Security"Threats"and"Emergency"Management"Processes"(Month"4`6."Lead:"Debois."Other"members:"Hildebrandt,"Zwisler,"R."Nielsen,"Matulevičius"and"Basin)"SP4. Coordination,"integration"and"dissemination"of"results"from"SP1K3"and"international"experience"(Month"1`6."Lead:"Hildebrandt."Other"members:"All)""The"aim"of"SP1"is"to"study&the&dependencies&on&ICT&in"both"daily&operation"and"emergency&management&processes&for&crucial&functions&in&Denmark,"concretized"as"processes"within"DSB"and"BaneDanmark"for"the"safe"operation"of"the"public"transport."This"will"be"carried"out"by"performing"empirical&studies"facilitated"by"experts"in"emergency"management"at"Metropol"and"process"mapping"at"ITU,"and"the"participating"actors"from"the"transport"sector"(DSB"and"BaneDanmark)."Concretely,"the"empirical"research"will"be"initiated"by"individual&2Qhour&interviews"with"key"actors"in"DSB"and"BaneDanmark"(5`6"persons)"agreed"to"take"place"June"15`July"5."These"interviews"will"serve"to"align"expectations"of"the"project"and"identify"concrete"processes,"e.g."within"personal"management"and"signal"systems,"to"be"mapped"and"analysed"in"two&subsequent&oneQday&workshops"(August"and"November)"using"and"contributing"to"development"of"the"method"and"tools"in"SP2"and"SP3.""




May 2nd, 2016

Whichprocesses?

6

Agreed to consider emergency management process for incident at the Great Belt bridge




May 2nd, 2016

CasePaper

7

Available online at www.sciencedirect.com

Procedia Computer Science 00 (2016) 000–000www.elsevier.com/locate/procedia

The 1st Workshop on Safety & Security Assurance for Critical Infrastructures Protection (S4CIP)

Experience Report: Constraint-based Modelling and Simulation ofRailway Emergency Response Plans

Søren Deboisa, Thomas Hildebrandta,⇤, Lene Sandbergb

a IT University of Copenhagen, Rued Langgaardsvej 7, 2300 Cph S, DenmarkbMetropolitan University College Copenhagen, Denmark

Abstract

We report on experiences from a case study applying a constraint-based process-modelling and -simulation tool, dcrgraphs.net,to the modelling and rehearsal of railway emergency response plans with domain experts. The case study confirmed the approach asa viable means for domain experts to analyse and rehearse emergency response plans, through the activities of formally modellingthe plan and subsequently rehearsing it by simulating that model collaboratively. In particular, the constraint-based modellingnotation resulted in a flexible model giving rehearsal participants freedom to explore di↵erent ways to proceed, including ways notnecessarily anticipated in the paper-based emergency response plans. The case study was undertaken as part of a short research,ProSec, project funded by the Danish Defence Agency, with the aim of applying and developing methods for collaborative mappingof emergency and security processes in the danish public transport sector and their dependency on ICT.c� 2016 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the Conference Program Chairs.

Keywords: Emergency response plans; Railways; Simulation; Formal models; DCR Graphs;

1. Introduction

Safe and reliable public transport is a prerequisite for the Danish society. The sector has well established plansand processes for managing physical emergency and security threats. However, as also pointed out in1, emergencyhandling is a multi-disciplinary concept, and the complexity and dynamic environment in which it is embedded makesit a serious coordination problem. Plans and processes are described in various paper documents that need to becontinuously rehearsed and updated, and the knowledge of dependencies on ICT infrastructure and consequences ofcyber-attacks is at best fragmented. Consequently, possible cascading e↵ects of cyber-physical incidents are unknown.

The aim of the ProSec project running from June 2015 to March 2016 was to develop and demonstrate a generalmethod for collaborative mapping and simulation of processes and plans for the safe operation of crucial functions insociety and their dependencies on Information and Communication Technology (ICT). The project members combineexpertise in process modelling, emergency and crisis management, and security and risk management. The firstkey hypothesis of the project is that the recently developed constraint based process modelling notation, Dynamic

⇤ Corresponding author. Tel.: +45 7218 5279.E-mail address: [email protected]

1877-0509 c� 2016 The Authors. Published by Elsevier B.V.Peer-review under responsibility of the Conference Program Chairs.




May 2nd, 2016

Verybrieflywhatwedid

8

Roles DCR Graphs




May 2nd, 2016

DCRGraphs&Security• Possible uses for reasoning about security

Raimundas will tell you about related work

• Pro-active enforcement of timed policies? Paper on Computer Security Foundations (CSF) Symposium - Søren will present this

9

In the Nick of Time:Proactive Prevention of Obligation Violations

David BasinInformation Security

ETH Zurich, SwitzerlandEmail: [email protected]

Søren DeboisTCS, IT University of Copenhagen

DenmarkEmail: [email protected]

Thomas HildebrandtTCS, IT University of Copenhagen

DenmarkEmail: [email protected]

Abstract—We present a system model, an enforcement mech-anism, and a policy language for the proactive enforcement oftimed provisions and obligations. Our approach improves uponexisting formalisms in two ways: (1) we exploit the target system’sexisting functionality to avert policy violations proactively, ratherthan compensate for them reactively; and, (2) instead of requiringthe manual specification of remedial actions in the policy, weautomatically deduce required actions directly from the policy. Asa policy language, we employ timed dynamic condition response(DCR) processes. DCR primitives declaratively express timedprovisions and obligations as causal relationships between events,and DCR states explicitly represent pending obligations. As keytechnical results, we show that enforceability of DCR policiesis decidable; we give a sufficient polynomial time verifiablecondition for a policy to be enforceable; and we give an algorithmfor determining from a DCR state a sequence of actions thatdischarge impending obligations.

I. INTRODUCTION

Many security requirements can be decomposed into pro-visions and obligations [4], [16], [25]. Provisions specifyconditions or properties dependent on the present and the past.They cover most traditional access control requirements. Forexample, access to customer records is granted to users in therole of customer-relations manager, provided customer consentwas granted in the past. Obligations, in contrast, imposeconditions on the future that an agent or process should fulfil.For example, a hospital may need to delete patient recordswithin 14 days of a patient’s release.

Provisions and their enforcement by access control mech-anisms are well understood. Obligations are less well under-stood, and subject to active research [1], [3], [10], [12]–[14],[17], [19], [21]–[24], [30], [34]. Enforcement of obligations isdifficult as, to be enforceable, obligations must be associatedwith deadlines. A simple but limited enforcement mechanismis to associate obligations with access control rules, wherebythe enforcement mechanism immediately takes the obliged ac-tion when the rule grants access, e.g., logging the taken action.Alternatively, obligations may be associated with deadlines,whose expiration triggers remedial actions to be taken by theaccess control mechanism.

The state of the art generally handles obligations in limitedways, like those suggested above. The theory of how tohandle obligations is underdeveloped, especially when dead-lines are involved. With few exceptions, policy violations arenot prevented, they are remediated. Namely, the enforcement

mechanism witnesses a deadline expiring, but is powerless toprevent the concomitant policy violation and is reduced totaking remedial actions after the fact, such as logging, loweringa reputation, etc. Moreover, the enforcement mechanism’sinteraction with the target system is often too limited foreffective obligation enforcement or the exact extent of themechanism’s control over the target system is unclear. Whilean enforcement mechanism can intercept actions and preventthem from happening, it cannot, a priori, force the targetsystem to take action when required. Existing mechanismstend to take only actions independent of the target system’sfunctionality, such as logging or sending notifications. Thereare exceptions, such as mandatory results automata [24], andwhite-box approaches [11]. We expand on these points inSection VI.

Approach and Results. We tackle the problem of proactivepolicy enforcement and present an enforcement mechanismthat directs the target system to prevent policy violations. Notevery policy can be enforced, and enforceability depends onthe enforcement mechanism’s exact powers over the targetsystem. We distinguish between whether the enforcementmechanism can (1) control an action by denying that it happensat a given point in time, (2) proactively cause an action tohappen in the target system, or (3) merely observe that anaction happens in the target system.

The above distinctions are critical. For some actions, e.g.a patient at a hospital dies, it is neither meaningful foran enforcement function to deny nor cause the action tohappen. In other cases it may make sense for a mechanismto control whether the action is allowed or not, but not toallow the mechanism to cause the action to happen by itself.For instance, a hospital IT system may be able to deny the im-mediate re-admission of a released patient; however, it cannotoutright cause a patient to be readmitted, as that would requireconsent from the patient. Finally, some actions may be bothcontrollable and causable, e.g., the enforcement mechanismcan both deny and proactively cause the transfer of recordsfrom local data storage to a remote archive, depending on theexact circumstances. Such distinctions between controllable(in the sense of denying) and uncontrollable (but observable)actions are well-known in other areas, such as supervisory-control theory (SCT) [31]. Here the supervisor plays the role




May 2nd, 2016

Conclusions?

• Let us discuss them at the end!

10




May 2nd, 2016

MoAvaAon

• Our life and society critically depend on the correct functioning of software systems

• Errors are not only expensive but also dangerous

• Using the right tools and formal methods errors can be detected early and systematically

11




May 2nd, 2016

• Errors can be dangerous:

• Therac-25 radition overdosing

• At least 6 cases of overdosis 1985-1987

• Three patients died

• Race condition in the control software

MoAvaAon

12




May 2nd, 2016

MoAvaAon

• Errors can be expensive:

• 9 hour outage of large parts of US telephone network in January 1990

• Costs: Several 100 million US$

• Software flaw

13




May 2nd, 2016

MoAvaAon

• Crash of Ariane 5-missile in 1996

• Costs: More than 500 million US$

• Software flaw in the control software

14




May 2nd, 2016

MoAvaAon

15




May 2nd, 2016

ImportanceofcorrectICT

• ICT is pervasive, can be safety-critical & serves us

• in our bodies (pacemakers)

• in our daily life (communication, transportation, finance, shopping...)

• in our society (hospitals, e-Government, military,..)

16




May 2nd, 2016

ValidaAonvsverificaAon

• Validation: Check that we build the right thing

• Verification: Check that we are building the thing right

17

The sooner the better:




May 2nd, 2016

ClassicalSWVerificaAon

• Peer reviewing

• code inspection - detects 31-93% defects but subtle (such as algorithmic, concurrency & communication) defects hard to catch

• Testing

• running the code - again, concurrency and communication defects hard to catch

18




May 2nd, 2016

BuildingSecurityIn

19

Code Scanning

Continuous Delivery




May 2nd, 2016

FormalMethods

• “Applied mathematics for building ICT systems”

• Potential for higher coverage and early integration in design (model-based design and SWD)

• More promising for detecting concurrency & communication errors

20




May 2nd, 2016

Formalmethods• Types

• Constrain the static structure of your code

• Type-checking is the procedure of verifying that your code follows the type constraints

• Mainstream types guarantee agreement of methods and types of values in interfaces

• Behavioral/Session types guarantee the order of communication, i.e. extend the scope to protocols for communication in distributed systems

21




May 2nd, 2016

Formalmethods• Model-based simulation & testing

• Explore a model (of the system) or use it to guide your tests of the system

• Simulation & testing detect bugs, not prove absence

• Model Checking

• Systematically check that a property P holds in every possible state of the (model of the) system

• Tools: SPIN, PRISM, NuSMV, UPPAAL, CPN Tools, WoPed, Declare, DCRGraphs editor, ..

22




May 2nd, 2016

FormalmethodsatITU• The Process and System Models (Models) Group

• Cross-cuts the Theoretical Computer Science (TCS) section and the Software Systems Section (SSS)

• Model-based design, session types, logical frameworks, model-checking, distributed systems, business process and case management systems

• Overlaps with the Programming, Logic and Semantics (PLS) Group

23




May 2nd, 2016

FormalmethodsMilestones• Mathematical model of computation & program

correctness (Turing, 1949)

• Syntax-based technique for sequential programs (Hoare, 1969)

• Syntax-based technique for concurrent programs (Pnueli, 1977)

• Models and syntax-based techniques for concurrent and mobile systems (Petri ’62, Hoare, Milner, ’80->)

• Model-checking (made into efficient and adopted technology by Clarke, Emerson, Sifakis - receiving ACM Turing Award 2007)

24




May 2nd, 2016

Goaloftheseminar

• The goal is to enable you to

• recognise and explain the most common problems in software that can be exploited by hackers,

• to apply tools for improving the quality of software

• and understand state-of-the art techniques for correct-by-construction distributed and process-oriented software systems

25




May 2nd, 2016

PrerequisitesandGoals

26




May 2nd, 2016

ImprovingqualityofSW

• We look at tools and techniques for

• reviewing code (code scanning)

• exhaustively test control flow (model checking)

• type checking communication protocols

• automating the software delivery process

• conclude with a look at critical systems in practice

27




May 2nd, 2016

LecturePlan

28

+Peter




May 2nd, 2016

Hand-insandexam

29

Sept 5Sept 15

Sept 25

Oct 20



Model Checking

Code

Environment

ModelProperty

?



May 2nd, 2016

TheModel-CheckingProcess

31

Create Formal Model of Requirements

Create Formal Model of System

Model Check: Does System Model satisfy

requirements?

Simulate (error trace)

No

Yes

Give up, buy bigger machine or change model

& requirements ?

Out

of m

emor

y/tim

e

Bigger machine

Change model/requirements

Give

up

Need to perform new model checking?

Yes

No




May 2nd, 2016

TheModel-CheckingProcess

31

Create Formal Model of Requirements

Create Formal Model of System

Model Check: Does System Model satisfy

requirements?

Simulate (error trace)

No

Yes

Give up, buy bigger machine or change model

& requirements ?

Out

of m

emor

y/tim

e

Bigger machine

Change model/requirements

Give

up

Need to perform new model checking?

Yes

No

What do formal system and requirementsmodels look like ?




May 2nd, 2016

TransiAonSystems&Automata

32




May 2nd, 2016

FormalSystemModels

33




May 2nd, 2016

ProperAes

• “After inserting a coin you will either eventually get a beer or a sprite”

• “It is possible to get infinitely many beers”

• “You can not get more drinks than coins inserted”

34




May 2nd, 2016

TemporalProperAes

• Linear Time (observe paths)

• Branching Time (observe branching)

35

{c}

{cof} {cof} {tea}{tea}

{c} {c}




May 2nd, 2016

Wheredomodelscomefrom?

• Code: C# or Java, Promela, VHDL, process calculus

• Graphical notations: BPMN, WS-CDL, Petri Net, UML, State charts, Message Sequence Diagrams, DCR Graphs, Declare, …

• Temporal Logics: LTL, CTL,..

36




May 2nd, 2016

Linear-AmeTemporallogic

37

Examples:

PLTL:




May 2nd, 2016

Linear-AmeTemporallogic

38

Examples:Formal Semantics

PLTL:




May 2nd, 2016

CommonpaWerns

• B is a response to A: B must happen (eventually) after A happens¬A ∨ F(B) (also written A⇒F(B) )

• A is a condition for B: A must happen before B can happen WU(¬B, A)

39

weak until:




May 2nd, 2016

MCStrengths&Weaknesses• General applicable

• Supports incremental/partial verification

• Provides diagnostic information if error found

• Potentially applied without knowledge of theory and integrated in development cycles

• Being adopted by (some) industries

• Sound, formal mathematical underpinning

40




May 2nd, 2016

Examples

• B&O remote controllers

• Deep Space 1 space craft execution module

• Deadlocks detected in on-line reservation systems

• Design flaws in control software of storm surge barrier protecting the main port of Rotterdam

• Bugs in routing protocol

41




May 2nd, 2016

• Difficult to handle data & infinite state

• Verifies a model - must validate model against reality

• Only verifies requirements you state

• Suffers from state-space explosion problem

• Still requires abstraction and formalization expertise

• The model-checker may contain errors!

42

MCStrengths&Weaknesses




May 2nd, 2016

Goingfurther

• Model checking code

• Smart representation of state space (BDDs)

• Use concurrency and/or symmetry information

• Make abstraction that preserve property of interest

• Give up precision

43




May 2nd, 2016

Exercises&Review• Explain key differences between type checking and

model checking

• Can you find an LTL formula satisfied by one of the (Kripke) transition systems at slide 28 and not the other? Explain why/why not

• Give a formal model describing the exercise hand in for the CRSYS seminar with actions Act={handin1,handin2,handin3,handinexam,login,logout} and the same atomic propositions

44




May 2nd, 2016

Exercises&Review

• Describe the following properties in LTL

• You must log in before you can hand in

• It is always possible eventually to log in

• The next state after logout is login

45


Overview of the ProSec project

Technology

Transcript of Overview of the ProSec project