System-Theoretic Safety, Security and Privacy Analysis

A brief introduction to STAMP/STPA, our extension to connect it to software verification and a brief look to STPA-Sec.

Transcript

1. Oslo, 2017-09-26 Stefan Wagner System-Theoretic Safety, Security and Privacy Analysis
2. You can copy, share and change, film and photograph, blog, live-blog and tweet this presentation given that you attribute it to its author and respect the rights and licences of its parts. based on slides by @SMEasterbrook und @ethanwhite
3. The primary safety problem in software- intensive systems is not software “failure” but the lack of appropriate constraints on software behavior. – Nancy Leveson
4. System Theory
5. STAMP Control Process Behavior Inadequate Enforcement Hazardous Process Hierarchical Safety Control Structure Hazardous System State Inadequate of Safety Constraints on from: Leveson. Engineering a Safer World. MIT Press, 2011
6. Problem Reports Operating Procedures Revised operating procedures Whistleblowers Change reports Certification Info. Manufacturing Management Safety Reports Policy, stds. Work Procedures safety reports audits work logs Manufacturing inspections Hazard Analyses Documentation Design Rationale Company Resources Standards Safety Policy Operations Reports Management Operations Resources Standards Safety Policy Incident Reports Risk Assessments Status Reports Safety−Related Changes Test reports Test Requirements Standards Review Results Safety Constraints Implementation Hazard Analyses Progress Reports Safety Standards Hazard Analyses Progress Reports Design, Work Instructions Change requests Audit reports Problem reports Maintenance Congress and Legislatures Legislation Company Congress and Legislatures Legislation Legal penalties Certification Standards Regulations Government Reports Lobbying Hearings and open meetings Accidents Case Law Legal penalties Certification Standards Regulations Accidents and incidents Government Reports Lobbying Hearings and open meetings Accidents Whistleblowers Change reports Maintenance Reports Operations reports Accident and incident reports Change Requests Performance Audits Hardware replacements Software revisions Hazard Analyses Operating Process Case Law SYSTEM DEVELOPMENT Insurance Companies, Courts User Associations, Unions, Industry Associations, Government Regulatory Agencies Management Management Management Project Government Regulatory Agencies Industry Associations, User Associations, Unions, Documentation and assurance and Evolution SYSTEM OPERATIONS Insurance Companies, Courts Physical Actuator(s) Incidents Operating Assumptions Process Controller Automated Human Controller(s) Sensor(s) from: Leveson. Engineering a Safer World. MIT Press, 2011
7. Problem Reports Operating Procedures Revised erating procedures Audit reports Problem reports Change Requests rdware replacements Software revisions Operating Process Physical Actuator(s) Incidents Operating Assumptions Process Controller Automated Human Controller(s) Sensor(s)
8. Safety is a control problem.
9. System-Theoretic Process Analysis (STPA)
10. Safety-guided design Hazard Analysis Design Decisions Fits well to iterative and agile development See also: Wang, Wagner. Toward Integrating a System Theoretic Safety Analysis in an Agile Development Process, 2016
11. Figure by Asim Abdulkhaleq
12. Figure by Asim Abdulkhaleq
13. Figure by Asim Abdulkhaleq
14. Controller 2 process changes, (Flaws in creation, or adaptation) Sensor Component failures Incorrect or no Feedback Delays missing feedback Inadequate or control action ineffective or missing Inappropriate, Delayed operation Controller Actuator Controlled Process extermal information Control input or wrong or missing Changes over time Measurement Feedback delays information provided inaccuracies Inadequate Operation operation Inadequate 1 4 4 3 Algorithm Inadequate Control 2 Process Model inconsistent, incomplete, or incorrect 3 Unidentified or out−of−range Process output contributes to disturbance system hazard Process input missing or wrong Conflicting control actions incorrect modification Unsafe inputs from higher levels Unsafe algorithms Wrong model of the process Wrong process execution
15. Example: ACC – Control Structure
16. Example: ACC – Step 1 Process Model Variables Control Actions Distance Driver Status Hazardous? Accelerate signal provided Distance < safe distance – Yes (H2) Distance > safe distance Driver on driver’s seat No Distance > safe distance Driver not on driver’s seat Yes (H3)
17. Example: ACC – Step 2 "ACC provides accelerate command while driver is exiting vehicle. ACC would accelerate if ACC is engaged and the vehicle in front starts moving again within a short time period. During this time, the driver may try to exit the vehicle because the vehicle was stopped and they believed ACC was off or had timed out." This scenario was formulated by John Thomas. Causal factors could be missing or wrong input from the seat belt sensor or the door sensor.
18. STPA for software-intensive systems
19. Connection to Verification Abdulkhaleq, Wagner, Leveson. A Comprehensive Safety Engineering Approach for Software-Intensive Systems Based on STPA. Procedia Engineering 128:2–11, 2015
20. context table, the software safety requirements are refined. For example, the software safety requirement (S ) is refined as the ACC software controller should not provide accelerating signal more than the desired speed wh CC is in cruise mode and brake pedal is not pressed. Table 2. Examples of the context table of providing the control actions Control Actions Process Model Variables Hazardous? Distance Speed Brake ACC Mode Accelerate Signal provided Distance < safe distance Speed == desired speed applied Cruise No Distance < safe distance Speed > desired speed Not applied Cruise Yes (H2), SSR3-4 Distance < safe distance Speed > desired speed Not applied follow Yes (H1), SSR1 Once we have identified the software safety requirements, the process model and the unsafe scenarios of e ntrol action using step 1, the safe behavior model can be constructed based on the process model. The safe behav del of the ACC software controller shows the relations between the process model variables (identified by ste d labeled with software safety requirements. Each transition in the safe behavior model is labeled with the synt nt [safety constraint]/control action. The event is a trigger of the transition and the safety constraint is a Bool ndition that must be true to transit to the next state. The control action describes the effect of the transition, such w the state variables are updated and what events are generated. For example, the transition t6 can be written: ntrolSpeed(currentspeed) [currentSpeed < desiredSpeed && distance > safeDistance && ACCMode ==cru & Brakestatus == Notapplied ]/ accelerateSpeed(currentspeed). 0 Asim Abdulkhaleq et al. / Procedia Engineering 128 ( 2015 ) 2 – 11 The transition t6 constrains the provision of the accelerate control action under the safety constraint derived by step 1 (Table 2). To formally verify the software safety requirements of each control action (refined from Table 2), first each software safety requirement should be formalized into a formal specification such as LTL or CTL to be able to verify them against the safe behavior model of the software controller during the verification phase. For example, the refined software safety requirement SSR1.3 can be expressed as the LTL formula: G ((currentSpeed < desiredSpeed && distance > safeDistance && ACCMode == cruise && Brakestatus == Notapplied) o accelerateSpeed). This formula means that the ACC software controller must always provide an acceleration signal when the current speed of the vehicle is less than the desired speed, there is no vehicle in the lane (distance > safe distance), and the brake pedal is not pressed when the ACC system is in cruise mode. Second, the safe behavior model needs to be Example Abdulkhaleq, Wagner, Leveson. A Comprehensive Safety Engineering Approach for Software-Intensive Systems Based on STPA. Procedia Engineering 128:2– 11, 2015 Semi-automatic transformation
21. Application to Security and Privacy
22. Example: ACC – Control Structure
23. Example: ACC – Step 1 Process Model Variables Control Actions Distance Driver Status Hazardous? Accelerate signal provided Distance < safe distance – Yes (H2) Distance > safe distance Driver on driver’s seat No Distance > safe distance Driver not on driver’s seat Yes (H3)
24. Example: ACC – Step 2 with STPA-Sec "ACC provides accelerate command while no driver is in the vehicle and the vehicle is parked.“ A causal factors could be a hostile attacker getting access to the car network either directly with a wired connection or via a wireless network and sending the accelerate command to the ACC.
25. System-theoretic analysis fits well to software systems! Tool support: www.xstampp.de PATRON project: http://patronresearch.de European STAMP Workshop: www.stamp-workshop.eu
26. Prof. Dr. Stefan Wagner e-mail stefan.wagner@informatik.uni-stuttgart.de phone +49 (0) 711 685-88455 WWW www.iste.uni-stuttgart.de/se Twitter prof_wagnerst ORCID 0000-0002-5256-8429 Institute of Software Technology These slides are available at www.stefan-wagner.biz
27. Pictures used in this slide deck Safety by GotCredit (https://flic.kr/p/qHCmfo, Got Credit) Unsafe Area by Jerome Vial under CC BY-SA 2.0 (https://flic.kr/p/71Kpk7) Airplane by StockSnap (https://pixabay.com/de/flugzeug-reisen-transport- airasia-926744/) Swiss Cheese Model by Davidmack - Own work, CC BY-SA 3.0, (https:// commons.wikimedia.org/w/index.php?curid=31679759) Die Titanic im Hafen von Southhampton - Gemeinfrei (https:// commons.wikimedia.org/w/index.php?curid=19027661) Pisa by Aaron Kreis (https://flic.kr/p/wzEw5K) Black cat at cemetery fence, New Orleans under CC SA 2.0 (https:// commons.m.wikimedia.org/wiki/ File:Black_cat_at_cemetery_fence,_New_Orleans.jpg) Looking back by Susanne Nilsson (https://flic.kr/p/niBFZo) Concorde Cockpit by Dr. Richard Murray (https://commons.wikimedia.org/wiki/ File:Concorde_Cockpit_-_geograph.org.uk_-_1357498.jpg)