Transcription
An Examination of Software Tool FeaturesNeeded to Help Secure Energy DeliveryIndustrial Control SystemsTaylor Andrews, Allen Moulton, and Stuart MadnickWorking Paper CISL# 2018-07August 2018Cybersecurity Interdisciplinary Systems Laboratory (CISL)Sloan School of Management, Room E62-422Massachusetts Institute of TechnologyCambridge, MA 02142
Working Paper – August 2018An Examination of Software Tool FeaturesNeeded to Help Secure Energy DeliveryIndustrial Control SystemsCybersecurity at MIT Sloan (CAMS)Massachusetts Institute of TechnologyCambridge, Massachusetts, United States of AmericaTaylor AndrewsAllen MoultonStuart E. Madnick1(working version 3.1)
Table of ContentsTable of Contents . 2Table of Figures . 31.Abstract and Motivation . 51.1 Why is Systems Theoretic Cybersafety based on STAMP? . 52.1.2Identify Energy Distribution Cyber Weaknesses Before Attackers Do . 71.3A Brief Summary of Existing STAMP Tools . 9A STAMP Software Tool Evaluation Framework . 102.1 General Software Features and Architectural Decisions . 102.23.STAMP-Specific Software Features . 11Software Trials Using an Example Energy Distribution Analysis. 123.0.1 What Steps Are Needed? . 123.1STPA-Sec Methodology Step 1.1: Define the Purpose of the Analysis . 163.1.1STPA-Sec Methodology Step 1.2: Identify Losses. 183.1.2STPA-Sec Methodology Step 1.3: Identify System-Level Hazards (Vulnerabilities) . 193.1.3STPA-Sec Methodology Step 1.4: Identify System-Level Constraints . 233.2STPA-Sec Methodology Step 2: Model the Control Structures . 253.3STPA-Sec Methodology Step 3: Identify Unsafe Control Actions (UCAs) . 333.3.1STPA Handbook Hazardous Four Control Action Possibility Support . 353.3.2 Hazardous System State Context Table Support . 383.1.1 NIST’s ACTS for Optimized T-Way Interaction Context Table Generation . 3943.4STPA-Sec Methodology Step 4: Identify Scenarios . 423.5Final Steps: Outputs, Reports, and Traceability. 45Conclusions . 46Appendix A – Detailed Categories of Software Features Supporting STAMP Analyst Items . 49Appendix B – STAMP Software Tool General Attribute Framework. 54Appendix C – Preliminary Systems Theoretic Cybersafety Data Structure Organization. 57Citations . 65Keywords: Systems Thinking, Cybersafety, Cyber Safety, Systems Theory, Systems Theoretic, SystemsTheoretic Cybersafety, STAMP, STPA, STPA-Sec, STPA-SafeSec, Industrial Control Systems, ICS,Operational Technology, OT, Cyber Security, Cybersecurity, Cyber Physical, Cyber-physical,Cyberphysical, Software Tools, Microsoft Office, Draw.IO, XSTAMPP, STAMP Workbench, RMStudio, SafetyHAT2(working version 3.1)
Table of FiguresFigure 1. A Systems Theoretic Cybersafety Methodology Progression (STAMP) . 11Figure 2. U.S. Dept. of Transportation Volpe's SafetyHAT MS Access Runtime System - Main View. 13Figure 3. XSTAMPP Hierarchical View of STPA-Sec Analysis Items . 14Figure 4. STAMP Workbench Hierarchical View of STPA Analysis Items . 14Figure 5. MS Office Example Rich Canvas Functionality for System Purpose . 16Figure 6. XSTAMPP Example Plaintext Functionality for System Purpose and Description . 17Figure 7. MS Office Rich Text Description of System and Goals . 17Figure 8. XSTAMPP Example Goals Management with Extended Plaintext Descriptions . 18Figure 9. MS Office Example Table for Specifying Losses . 18Figure 10. XSTAMPP Example Loss Manager with Extended Plaintext Descriptions . 19Figure 11. STAMP Workbench Specifying Losses. 19Figure 12. MS Office Example Table Format Specifying Hazards (Vulnerabilities) . 20Figure 13. XSTAMPP Example Hazard/Vulnerability Manager with Extended Description & Linking. 20Figure 14. MS Office Example Hazard/Vulnerability & Loss Linking Management Functionality) . 21Figure 15. XSTAMPP Example Hazard/Vulnerability & Loss Linking Management Functionality . 22Figure 16. SafetyHAT's Hazard Input Form and Loss/Accident Linking Features . 22Figure 17. MS Office Example Table for Safety Constraints . 23Figure 18 XSTAMPP Example Safety Constraint Manager and Linking Functionality . 24Figure 19. MS Office Example Safety Constraint Linking Using Rich Text . 24Figure 20. XSTAMPP’s Preliminary Features for Ordered List Support. 25Figure 21. Draw.IO Example General Purpose Canvas Control Structure Drawing . 26Figure 22. STAMP Workbench's Matrix Specification for Functional Control Structure Generation . 27Figure 23. STAMP Workbench Control Action Manager and Editor . 28Figure 24. STAMP Workbench Feedback Manager and Editor . 28Figure 25. STAMP Workbench Control Structure Model After Generation and Brief ManualRearrangement . 29Figure 26. Using XSTAMPP’s Drawing Canvas to Create a Functional Control Structure Drawing. 30Figure 27. "Connection Fracture" Intelligent Drawing Canvas Optimizations . 31Figure 28. [17, Figure G-2]. Detailed Socio-Technical Causal Control Model . 32Figure 29. XSTAMPP Example Process Model Specific Features . 33Figure 30. XSTAMPP Control Actions Summary Table . 34Figure 31. STPA’s “Hazardous Four” Control Action Possibilities to Consider . 35Figure 32 MS Office Table Evaluating Manually Evaluating Control Actions . 35Figure 33. XSTAMPP Example Unsafe & Unsecure Control Action Matrix Evaluation Functionality . 36Figure 34. XSTAMPP Example Allowing New Security and Safety Constraints Based On Unsafe ControlActions . 37Figure 35. MS Office Table Evaluating and Linking Control Actions with Hazardous Process ModelVariable Values (Context) . 38Figure 36. XSTAMPP Context Table Manger: Security Critical Control Action Review . 38Figure 37. XSTAMPP Context Table Generation: NIST CSRC’s ACTS Tool Interface . 39Figure 38. [17, Figure 2.20]. STPA Handbook: Overview of Scenario Identification . 42Figure 39. [17, Figure 2.17]. STPA Handbook: Two Types of Scenarios That Must Be Considered. 423(working version 3.1)
Figure 40. [17, Figure 2.18]. STPA Handbook: Two Causes of UCAs Scenarios . 43Figure 41. [17, Figure 2.19]. STPA Handbook’s Generic Control Loop, Control Path, and OtherControlled Process Factors . 43Figure 42. XSTAMPP Example Matrix Based Scenario Management. 44Figure 43. MS Office Example General Purpose Tool Visual Scenario Diagram Example . 454(working version 3.1)
1. Abstract and MotivationIn December 2015, coordinated cyberattacks targeting Ukrainian power distribution systems’information technology (IT), industrial control systems (ICS), and operational technology (OT) resultedin physical damage to Ethernet serial converters, intentional disabling of distribution facility backupgenerators, denial of service attacks on customer support call centers, and permanent destruction ofworkstation hard drive data, causing temporary citywide power grid failure that affected 225,000 people[21]. It was discovered the attack in Ukraine took place months after initial network penetration, afterextensive surveillance and data gathering was first performed, indicating cyber attackers are attempting toprolong intrusions and avoid detection in an effort to practice, simulate, and perfect militarized-styleattack architectures to maximize damages [21]. In March of 2018, after joint collaboration, the U.S.Department of Homeland Security and FBI released an alert that documented details of a multi-year,extensive surveillance and intrusion campaign from state sponsored “threat actors” that widely penetratedU.S. energy distribution systems with malware designed to enable covert remote access and technicalmanipulation abilities, to be able to perform similar attacks on American power grids [16].The growing number of cyber-physical intrusions to energy distribution systems requirepreventative, structured cybersecurity analysis to produce attack scenarios, causal factors, design changes,and new requirements to secure energy systems before systems are compromised, ideally at system designand development time. Hazard analysis, safety analysis, and reliability analysis must no longer beconsidered solely from the point of view of single component, engineering-based failures, but must allevolve to foresee premeditated, malicious, and coordinated actions of human organizations thatintentionally cause disastrous multi-component failure scenarios after careful reconnaissance and reverseengineering. In this paper, we explain systems theoretic cybersafety, we document an exploration ofsoftware tool features that support systems theoretic cybersafety analysis automation, provide a detailedlist of STAMP software tool specification requirement areas to consider when designing future systemstheoretic cybersafety tools, and finally we include some data structures for systems theoretic cybersafetyanalysis information organization. Through an energy distribution system example in Section 3, we alsodemonstrate how one currently may use software tool features to perform systems theoretic cybersafetyanalysis using STAMP, and produce system changes to defend and defeat when analyzing existingsystems or designing new ones.1.1 Why is Systems Theoretic Cybersafety based on STAMP?STAMP is an accident causality model developed by MIT’s Aeronautics and AstronauticsDepartment in the early 2000s by Nancy Leveson, which then led to the formation of STPA (SystemTheoretic Process Analysis) for preventative safety and hazard analysis [28]. In her paper, “A SystemsTheoretic Approach to Safety Engineering,” Nancy Leveson differentiates that “in STAMP, accidents areconceived as resulting not from component failures, but from inadequate control or enforcement ofsafety-related constraints on the design, development, and operation of the system” [25]. The 2018 STPAHandbook written by Nancy Leveson and John Thomas states "STPA is a relatively new hazard analysistechnique based on an extended model of accident causation. In addition to component failures, STPAassumes that accidents can also be caused by “unsafe interactions of system components, none of whichmay have failed" [17]. Systems theoretic cybersafety analysis is rooted in this systems theoretic accident5(working version 3.1)
model called STAMP due to its focus on loss of system control, emergent interactions and behaviors, andinadequate system “controller” decisions as potential causes that produce vulnerable system states, duringwhich system hazards and accidents can take place. “Controllers” in systems can be either human ortechnical. Controllers use logic and algorithms to make decisions they believe are correct, butunfortunately, unbeknownst to them, they may not have a clear picture of what the true state of the systemis; a malformed controller “process model” may lead them to believe otherwise. A process model isnothing more than the “mental model” of the controller; a human controller who has had proceduraltraining (such as an operator or other employee) forms mental algorithms that allow them toindependently view the state of their work environment, using their human senses to update their mental“process model,” and then to continuously make decisions (through the logic provided to them throughtraining) on how to perform their job responsibilities. Conversely, but in the same spirit, a technicalcontroller will possess numerous specific values in its memory (or perhaps sometimes periodicallypersisted to disk for backup) that correspond to the technical controller’s process model. The internalsoftware algorithm programming is the technical controller’s “procedural training,” and the technicalcontroller’s “view” of its “work environment” comes from considering the digital information in itsprocess model, helping it decide how to perform its job function as well. “Control actions” and“feedbacks” are also passed between controllers and the processes they control to enlighten the rest of thesystem about the state of system operations, so all controllers can respond and manage the systemtogether. It is believed this systems-theoretic view of accidents and hazards (STAMP analysis) can also beapplied in a security context for cybersecurity, providing the theoretical foundation for systems theoreticcybersafety.Full DefinitionSystems-Theoretic Accident Model and ProcessesCausal (post) Analysis based on STAMPSystems Theoretic Process AnalysisSystems Theoretic Process Analysis for SecuritySafety Analysis (STPA) and Security Analysis (STPA-Sec) [20]Abbreviated MP/STPA-SafeSecTable 1.Systems Theoretic Cybersafety STAMP NomenclatureSome software tools aim to support STAMP/STPA analysis, so an in-depth examination of existingfeatures was first performed to examine what features currently exist, and to develop a list of featurerequirement areas where future development of tools must focus to support systems theoretic cybersafety.This paper aims discuss a way to evaluate and compare STAMP software tools when integrating theminto existing systems engineering toolchains, existing software tool features available for performingSTAMP analysis (using an energy distribution industrial control system example), and finally a promisinglist of systems theoretic cybersafety software feature requirement areas to inspire future tool development.STAMP analysis was used by the Composite Information Systems Laboratory (CISL) to explore anddocument the Stuxnet cyberattack, which targeted Iranian nuclear enrichment centrifuges, and root-causethe component interactions that had taken place [29]. STAMP analysis was also used by CISL to exploreand document the TJX cyberattack, which resulted in the theft of “millions of customer’s payment carddata” and “financial losses amounting to over 170 million” [30].6(working version 3.1)
1.2 Identify Energy Distribution Cyber Weaknesses Before Attackers DoSignificant dangers arise from dutifully engineered, thoughtfully timed, intentional attacks that inject,omit, or otherwise tampering with specific control actions and feedbacks in the system to carefullydeviate controller process models (discussed in Section 1.1) to cause intentionally dangerous andunexpected interactions between components of the system. Modern cyberattacks are now repeatedlydemonstrating this type of sophistication [21][29]. Systems theoretic cybersafety is currently beingperformed on MIT's Cogeneration Plant by Cybersecurity at MIT Sloan (CAMS), and structured safetyanalysis has been performed on nuclear facility industrial control systems [22]. These examples ofstructured security analysis methods aim to allow engineers and analysts to identify unacceptable lossesand attack scenarios before they happen, and to generate safety constraints, requirements, andarchitectural decisions that keep cyber-physical systems secure from cyberattacks. For this process,CAMS recommends utilizing a system theoretic methodology called STAMP/STPA-Sec, along withaspects of a complimenting methodology STAMP/STPA-SafeSec [19] [20].Dr. Bill Young extended STAMP’s preventative STPA analysis for specific use in security, resultingin Systems Theoretic Process Analysis for Security (STPA-Sec) [19]. STPA-Sec aims to provide ananalysis methodology that identifies a top-down approach to safety and security by identifying losses,hazardous vulnerabilities, security constraints, and unsafe control actions to systematically create causalfactors and attack scenarios, identify security constraints, and necessary design or requirement changes ina preventative manner during system development. STAMP/STPA-Sec methodology steps are analogousto the 2018 STPA Handbook’s foundational STPA steps, with extensions to produce malicious attackscenarios to drive secure system change. STAMP/STPA-SafeSec built upon STPA by integratingformalization of some general physical network component structures and network interactions tocompliment the core functional control structures found in traditional STAMP analysis, and to organizeattack scenarios into a hierarchy to attempt to provide an interface for external attack-tree strategies [20].Currently engineers and analysts often perform hazard, safety, and cybersecurity analyses by hand orthrough general purpose document creation software platforms, using a variety of tools andmethodologies to produce custom structured reports, which aim to disseminate security relatedinformation. We believe STAMP software tool features can further the ease of creating such reports, byleveraging computer systems to aid in STAMP information organization/linking/prioritization, controlstructure modelling, component interaction consideration, attack scenarios, and outputs to help make thesystem changes necessary to secure the cyber-physical system before it is penetrated, explored, andintentionally exploited. We conclude with a brief discussion of future systems theoretic cybersafetysoftware areas of exploration, a basic framework for evaluating and comparing general STAMP softwaretool attributes when integrating them into existing systems engineering processes, and a detailed list ofSTAMP feature requirement areas. We hope this paper will help inspire further development of futuresoftware tools that help the analysist or engineer to performing systems theoretic cybersafety analysis,starting with energy delivery systems.The following section offers an evaluation of the existing STAMP tool features aimed primarily atshowcasing existing features required to perform STAMP analysis, specifically for systems theoreticcybersafety analysis of energy delivery systems. Please first note this paper was not intended to documentbugs in the software tools, and instead aims to portray the landscape of available software tool featuresavailable to aid in performing systems theoretic cybersafety analysis of energy distribution systems.7(working version 3.1)
This paper will next show the experiences gained from using some leading STAMP tools to duplicateS. Khan’s cybersafety analysis of MIT’s Central Utilities Plant (CUP) Facility: a cybersafety analysis ofan energy distribution system (Section 3). All general purpose tool example screenshots showcasing MSOffice and Draw.IO based STAMP analysis using general purpose document creation software platformsare from S. Khan’s working paper and research materials. This gas turbine generator example was chosento showcase many existing software features that already are available to support systems theoreticcybersafety, and to familiarize the reader with a systems theoretic approach to analyzing and securingenergy distribution IT, industrial control, and OT systems through cybersafety. Again, as the readerprogresses through an understanding of the steps in the example analysis, software features arehighlighted that support the rapid, organized completion of analysis steps to produce structured reports fororganized and professional cybersafety information dissemination. Considering systems theoreticcybersafety analysis findings can preventatively enlighten new architectural design decisions, systemsecurity constraints generation, and system requirement generation, or refine existing systems. This paperconcludes by highlighting some areas of further research and feature development for new softwarefeatures to move systems theoretic cybersafety software tool capabilities forward. This collection ofcontent aims to help operationalize systems theoretic cybersafety analysis software tools to help secureenergy distribution cyber-physical systems.8(working version 3.1)
1.3 A Brief Summary of Existing STAMP ToolsThere are various tools for STAMP assistance, in various stages of development, but all with theexpectation that the user has some level of STAMP analysis experience. Some aim to support specificSTAMP methods such as STAMP/STPA and, more recently, STAMP/STPA-Sec and STAMP/STPASafeSec. The following bullet lists shows the current landscape, and a list is also available online from thePartnership for Systems Approaches to Safety and Security (PSASS) [26].Some STAMP tools are in the project planning phases and are considered in-development: A separate partnership between Stiki ̶ Information Security and Zurich University of AppliedSciences advertises “a 2.5 year project” to create a STAMP/STPA plugin for their RM Studioproduct, Stiki’s risk-management platform [2].Some proprietary STAMP related tools are also available for purchase: Safeware Engineering Corporation offers a proprietary product SpecTRM that uses arequirements language to produce models of software that can “support execution of thespecification as well as automated safety analyses” [3]. Sparx Systems’ Enterprise Architect UML/SysML modeling tool had offered a STAMP/STPAextension SAHRA, but it now claims to be transitioning to a successor “ANSHIN,” which will“soon be available” [4].Finally, three more STAMP tools are available for immediate and free evaluation and are evaluated in thispaper: The U.S. Dept. of Transportation has released a STAMP/STPA tool aimed at transportationsystems, called the Safety Hazard Analysis Tool (SafetyHAT) [5]. STAMP Workbench (iSTAMP) was created by Japanese Information-technology PromotionAgency (IPA), advertising STAMP/STPA support. IPA announced iSTAMP as open source in2018, and a free productized version of the project was released branded as STAMP Workbench[1] [27]. The product is Java based and cross platform, built to run on various PC operatingsystems. The University of Stuttgart’s XSTAMPP Platform is a diverse open source STAMP softwareplatform, claiming to support a wide array of STAMP methods [6]. The product is Java based andcross platform, built to run on various PC operating systems.The following general-purpose drawing tools also implicitly support STAMP analysis. The followingsoftware tools were also evaluated for supporting STAMP analysis: Microsoft Office (MS Office) (Proprietary) Microsoft Word Microsoft PowerPoint Microsoft Excel Microsoft Access Draw.IO (https://www.draw.io) (Evaluation Versions)9(working version 3.1)
2. A STAMP Software Tool Evaluation FrameworkSome considerations for STAMP software tools were formalized that focused on safetyspecification categories that STAMP software tool component classifications when considering commonsoftware standards such as IEC 61508 (E/E/PE), EN50128 (Railway), ISO26262 (Automotive), andfinally D0-178C/D0-330 (Aerospace & Defense) [7]. These qualifications aim to quantify potentialdangers from software tool failures in a safety sense, rather than how a systems engineer would integrateSTAMP tools into their existing processes and software toolchains. When considering software tools foreffectiveness in automating and supporting systems theoretic cybersafety analysis of complex cyberphysical systems, more managerial as well as technical categories must be considered for socio-technicalcompleteness. Deciding how different STAMP software tools may or may not compliment an existing ITsystem architecture and as systems engineering toolchain is important for integrating STAMP tools intoexisting processes. This framework first aims to expand these considerations by documenting a sociotechnical set of general STAMP software tool attributes, spanning from common traditional softwarearchitectural decisions to IT managerial concerns. The framework then aims to set a future direction forSTAMP software tool development by describing some future research areas, and a preliminary set ofsystems theoretic cybersafety software tool feature requirement areas to leverage STAMP. This paperthen evaluates some popular, widely available STAMP tool features to document a collection of novel,existing STAMP-specific software tool features that aid in operationalizing systems theoreticcybersecurity and cybersafety analysis. Complementing the general software attribute considerationframework, a preliminary list of STAMP-specific feature set areas is provided to help guide futuresoftware tools supporting analysts performing cybersafety analysis on energy distribution systems. Thepaper concludes with a discussion of possible future feature development areas, a general STAMPsoftware attributes framework evaluating a popular STAMP tool (Appendix B – STAMP Software ToolGeneral Attribute Framework), a detailed list of feature set areas on which future systems theoreticcybersafety tool development should focus (Appendix A – Detailed Categories of Software FeaturesSupporting STAMP Analyst Items), and an initial data structure and organization for systems theoreticcybersafety analysis data.2.1 General Software Features and Architectural DecisionsThe STAMP tool evaluation begins with a traditional collection of software product attributes in atable showcasing general software attributes. This captures a set of common software attributes generallyconsidered when comparing systems engineering software products for a production application, such astechnical details, software architecture information, acquisition availability and type, collaboration andteamwork features, and other managerial and logistical concerns. In this respect, we believe STAMPsoftware tools can be first evaluated in a somewhat high-level, general way, allowing similar comparisonto other software products, before moving into STAMP methodology specific features (Section 3 andAppendix A – Detailed Categories of Software Features Supporting STAMP Analyst Items). Appendix B– STAMP Software Tool General Attribute shows general STAMP software attributes and how anexample STAMP software tool (XSTAMPP) is classified using them.10(working version 3.1)
2.2 STAMP-Specific Software FeaturesThe compliment to the general software attributes evaluation provides STAMP-specific featureareas that support completing STAMP analysis in an optimized, engaging, and rapid way to supportsystems theoretic cybersafety. A detailed list of STAMP-specific software feature areas follows inAppendix A – Detailed Categories of Software Features Supporting STAMP Analyst Items. In the samespirt of STAMP’s top-down approach, the features were first aggregated into 15 general software featurerequirement areas.1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.Features supporting methodology guidanceFeatures supporting identification of system purpose and descriptionFeatures supporting the identification of system goalsFeatures supporting the identification of system accidents/lossesFeatures supporting the identification of system hazards/vulnerabilitiesFeatures supporting the identification of system-level constraintsFeature
Theoretic Approach to Safety Engineering," Nancy Leveson differentiates that "in STAMP, accidents are conceived as resulting not from component failures, but from inadequate control or enforcement of safety-related constraints on the design, development, and operation of the system" [25]. The 2018 STPA
