System-Theoretic Process Analysis for Security (STPA-SEC ...

System-Theoretic Process Analysis for Security (STPA-SEC):

Cyber Security and STPA William Young Jr, PhD

Reed Porada

2017STAMPConferenceBoston,MA

March27,2017

[email protected] ©CopyrightWilliamYoung,Jr,2017

Disclaimer:

The views expressed in this presentation are are those of the

presenters and do not reflect the official policy or position of the

United States Air Force, Department of Defense, Air Combat

Command, MIT Lincoln Laboratory, or the U.S. Government

2 [email protected] ©CopyrightWilliamYoung,Jr,2017

Overview •  PartI:CyberSecurityandSTPA

•  Introduc?on• WhatAspectofSecurityisourFocus?

• Where(level)ofSecurityareWeFocusedon?

• WheninSystemEngineeringLifecycleareweFocusedon?

• WhoAmongtheOrganiza?on’sPersonnelareweFocusedon?

• WhyDoesThisAspectofSecurityMaQer?

•  HowDoesSTPA-SecWork:SimpleExampleBasedonChemicalReactor

•  Conclusion

•  PartII:CyberSecurityPrac?cum(ImmediatelyFollowingin32-144)


Introduc6on / Mo6va6on

•  SystemandsoYwareengineersfaceincreasedpressuretostemgrowinglosses

•  Originsoflossesfallintoatleastoneoftwocategories:•  Disrup?onpreventsengineeredsystemfromfulfillingitsdesignedpurpose•  Disrup?ondoesnotnecessarilypreventtheengineeredsystemfromfulfillingitsprimarypurpose,butitproducesanunacceptable“by-product”

•  ICTproblemsareubiquitousandgrowing,butcybersecuritysolu?onsextendbeyondcryptography,soYwareengineering,etc.

•  Securityengineeringistheemergingfieldtoaddressthesechallenges

•  Growingrealiza?onthatsecurityengineeringmustbeginbeforearchitecturedevelopment…butweneedaSecurityEngineeringAnalysismethodology

4WeMustEnsureThatWeAreSolvingtheRightEngineeringProblem


Security and Cyber Security Defined Security(USGov’t,CNSSI4009)--Acondi?onthatresultsfromtheestablishmentandmaintenanceofprotec?vemeasuresthatenableanenterprisetoperformitsmissionorcri?calfunc?onsdespiterisksposedbythreatstoitsuseofinforma?onsystems.Protec?vemeasuresmayinvolveacombina?onofdeterrence,avoidance,preven?on,detec?on,recovery,andcorrec?onthatshouldformpartoftheenterprise’sriskmanagementapproach.

Cybersecurity(USGov’t&DoD)--Preven?onofdamageto,protec?onof,andrestora?onofcomputers,electroniccommunica?onssystems,electroniccommunica?onsservices,wirecommunica?on,andelectroniccommunica?on,includinginforma?oncontainedtherein,toensureitsavailability,integrity,authen?ca?on,confiden?ality,andnonrepudia?on.

5CyberSecurityisanOverarchingTermthatCoversNearlyEverything

What

Where

When

Who

Why


Cyber Security of What?

6OurFocusTodayistheTopLevel(BusinessorMissionOpera?ons)

*Opera?onalTechnology–computercontrolledphysicalprocessessuchasICS(i.e.power,water)logis?cs(fuelsystems)orothercontrolsystems(i.e.buildingautoma?on,securityalarms)

Mission/BusinessLevel

(Management/Opera?onal/TechnicalControls)

ComponentLevel

(TechnicalControls)

SystemLevel

(Technical/Opera?onalControls)

Tradi?onalInfoTechnology

Opera?onalTechnology* Plagorms

LEVEL

TYPEWhat

Where

When

Who

Why


Cyber Security Through Different Analy6c Lenses

7Thephysicalsystemexiststoenablebusiness/missionfunc?on

System Vulnerability

Mission or Business Operations

Threat

To System and Business /

Mission

VulnerabilityAnalysis

ThreatAnalysis

ImpactAnalysis

FocusforToday

What

Where

When

Who

Why


Mission Assurance Versus CyberSecurity

•  AssureOpera?ons

•  IAC

•  Func?onal(opera?ons)

•  Info(seman?c)-focused

•  “Assure”

•  ComplexInterac?ons

•  Socio-Technical

•  Strategy

•  Protect Assets

•  CIA

•  Physical (Assets)

•  Data-focused

•  “Protect”

•  Complicated Interactions

•  Technical

•  Tactics

8 [email protected] ©CopyrightWilliamYoung,Jr,2017

1.  TargetAcquired 2.  InformaNonCommunicaNonsTechnologytransmitsdata

3.  Commanderatdistantcenterobserves

4.  MissionCommanderlosessurveillanceandaborts

5.SOFteamabortsmission 6.ATempttodeterminecause

Mission Failure Versus System Failure

9Ref: (Vautrinot, 2012)

CouldMissionOpera?onHaveBeenDesignedDifferentlytoEnableMoreAssurance?

ATack

Failure

Weather

Accident


Security Today •  Findthemostimportantcomponentsandprotectthem

•  Compliancewithstandardsandbestprac?cebelievedkeepoursystemssecurefromloss

•  Breakingthe“KillChain”preventslosses

•  Surveysorques?onnairestouncoverwhatismostimportant

Reconnaissance Weaponization Delivery Exploitation Installation C2 Actions

Analysis Detection

Figure 3: Late phase detection

on these tools and infrastructure, defenders force an adversary to change every phase of their intrusion inorder to successfully achieve their goals in subsequent intrusions. In this way, network defenders use thepersistence of adversaries’ intrusions against them to achieve a level of resilience.

Equally as important as thorough analysis of successful compromises is synthesis of unsuccessful intrusions.As defenders collect data on adversaries, they will push detection from the latter phases of the kill chain intoearlier ones. Detection and prevention at pre-compromise phases also necessitates a response. Defendersmust collect as much information on the mitigated intrusion as possible, so that they may synthesize whatmight have happened should future intrusions circumvent the currently e↵ective protections and detections(see Figure 4). For example, if a targeted malicious email is blocked due to re-use of a known indicator,synthesis of the remaining kill chain might reveal a new exploit or backdoor contained therein. Withoutthis knowledge, future intrusions, delivered by di↵erent means, may go undetected. If defenders implementcountermeasures faster than their known adversaries evolve, they maintain a tactical advantage.

Reconnaissance Weaponization Delivery Exploitation Installation C2 Actions

Analysis Detection Synthesis

Figure 4: Earlier phase detection

3.5 Campaign Analysis

At a strategic level, analyzing multiple intrusion kill chains over time will identify commonalities andoverlapping indicators. Figure 5 illustrates how highly-dimensional correlation between two intrusionsthrough multiple kill chain phases can be identified. Through this process, defenders will recognizeand define intrusion campaigns, linking together perhaps years of activity from a particular persistentthreat. The most consistent indicators, the campaigns key indicators, provide centers of gravity fordefenders to prioritize development and use of courses of action. Figure 6 shows how intrusions may havevarying degrees of correlation, but the inflection points where indicators most frequently align identifythese key indicators. These less volatile indicators can be expected to remain consistent, predicting thecharacteristics of future intrusions with greater confidence the more frequently they are observed. Inthis way, an adversary’s persistence becomes a liability which the defender can leverage to strengthen itsposture.

The principle goal of campaign analysis is to determine the patterns and behaviors of the intruders,their tactics, techniques, and procedures (TTP), to detect “how” they operate rather than specifically“what” they do. The defender’s objective is less to positively attribute the identity of the intruders thanto evaluate their capabilities, doctrine, objectives and limitations; intruder attribution, however, maywell be a side product of this level of analysis. As defenders study new intrusion activity, they willeither link it to existing campaigns or perhaps identify a brand new set of behaviors of a theretoforeunknown threat and track it as a new campaign. Defenders can assess their relative defensive posture ona campaign-by-campaign basis, and based on the assessed risk of each, develop strategic courses of actionto cover any gaps.

Another core objective of campaign analysis is to understand the intruders’ intent. To the extentthat defenders can determine technologies or individuals of interest, they can begin to understand theadversarys mission objectives. This necessitates trending intrusions over time to evaluate targetingpatterns and closely examining any data exfiltrated by the intruders. Once again this analysis results

7

Dowebelievethattheseapproachesareworking?

What

Where

When

Who

Why


We Are Performing Security Engineering

•  SecurityEngineering--“Aninterdisciplinaryapproachandmeanstoenabletherealiza?onofsecuresystems.Itfocusesondefiningcustomerneeds,securityprotec?onrequirements,andrequiredfunc?onalityearlyinthesystemsdevelopmentlifecycle,documen?ngrequirements,andthenproceedingwithdesign,synthesis,andsystemvalida?onwhileconsideringthecompleteproblem”(USFederalGov’t)

•  SystemsSecurityEngineering—”aspecialtydisciplineofsystemsengineering.Itprovidesconsidera?onsforthesecurity-orientedac?vi?esandtasksthatproducesecurity-orientedoutcomesaspartofeverysystemsengineeringprocessac*vitywithfocusgiventotheappropriateleveloffidelityandrigorinanalysestoachieveassuranceandtrustworthinessobjec?ves.“(NISTSP800-160)

11NISTSP800-160“SystemsSecurityEngineering”isEmergingastheUSGov’tStandard

What

Where

When

Who

Why


Martin Libicki on Network Security “Start with the problem of preventing effects arising from mis-instructed systems, often understood as “defending networks.” As noted earlier, such a task might otherwise be understood as an engineering task—how to prevent errant orders from making systems misbehave. One need look no further than Nancy Leveson’s Safeware to understand that the problem of keeping systems under control in the face of bad commands is a part of a more general problem of safety engineering, a close cousin of security engineering as Ross Anderson’s classic of the same name expounds.”

[email protected] ©CopyrightWilliamYoung,Jr,2017Reference:“CyberspaceisnotaWarfighNngDomain”

WholeSystem

Subsystem1

Subsystem2

Component

HW SW Human

FuncNonalPurpose

AbstractFuncNon

GeneralFuncNon

PhysicalFuncNon

PhysicalForm

Whole-Part

Ends-Means

Formfollowsfunc?on

What

Where

When

Who

Why

Where (Level) is Security Performed


WholeSystem

Subsystem1

Subsystem2

Component

HW SW Human

FuncNonalPurpose

AbstractFuncNon

GeneralFuncNon

PhysicalFuncNon

PhysicalForm

Whole-Part

Ends-Means

Ignoringtheproblemspacepreventstakingadvantageofimprovedproblemdefini?on

ProblemSpace

What

Where

When

Who

Why

Where (Level) is Security Performed


Systems, Information Systems, Information Technology

Mission Activity System

Information System

Information Technology Real-world computing and communications devices

Abstraction depicting how the mission-essential control/information requirements are satisfied

Why - MISSION

How - TASKS

Tactics

Strategy

Cyber Security & Information (Data) Security Emphasis

Abstraction representing real world purposeful action as a system

REAL WORLD ABSTRACTIONS

Tasks---dataandsignals;Mission--informa?on&controlReference: Checkland, 1995; Checkland and Howell 1998

Suggested Mission Assurance Emphasis

[email protected] © Copyright William Young, 2017

15

JustBecauseyouCan,Doesn’tMeanyouShould…JustBecauseitWorks,Doesn’tMeanitCanBeSecured


When to Address Security-- Pre-Architecture

17

Concept Development Production Utilization Retirement

Effe

ctiv

enes

s &

Cos

t to

Fix

Low

High

Problem Analysis Solution Development & Implementation

SystemsEngineeringLifecycle

FocusofSTPA-Sec

FocusoftradiNonalsecurityefforts

WeMustRigorouslyIden?fyandFramethe“Right”SecurityProblem

What

Where

When

Who

Why


Current Security Analysis “Whenyouaskanengineertomakeyourboatgofaster,yougetthetrade-space.

Youcangetabiggerenginebutgiveupsomespaceinthebunknexttotheengine

room.Youcanchangethehullshape,butthatwillaffectyourdraw.Youcangiveup

someweight,butthatwillaffectyourstability.Whenyouaskanengineertomake

yoursystemmoresecure,theypulloutapadandpencilandstartmakinglistsof

bolt-ontechnology,thentheytellyouhowmuchitisgoingtocost.”

-ProfBarryHorowitz,UVA

18

Performed During Early Engineering Technical Processes

IEEE/IEC/ISO15288(SystemEngineeringStandards)

•  Businessormissionanalysis•  Stakeholderneedsandrequirements

•  Systemrequirementsdefini?on

NISTSP800-160(EmergingSecureSystemEngineeringStandards)

•  Businessormissionanalysisprocess•  Stakeholderneedsandrequirementsdefini?on

•  Systemrequirementsdefini?on

19

What

Where

When

Who

Why


Who Are We Focused On

20

Special Publication 800-160 Systems Security Engineering A Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems

________________________________________________________________________________________________

CHAPTER 2 PAGE 11

This publication is available free of charge from: https://doi.org/10.6028/N

IST.S

P.800-160

• Provides evidence to substantiate claims for the trustworthiness of the system; and

• Leverages multiple security and other specialties to address all feasible solutions so as to deliver a trustworthy secure system.

Systems security engineering leverages many security specialties and focus areas that contribute to systems security engineering activities and tasks. These security specialties and focus areas include, for example: computer security; communications security; transmission security; anti-tamper protection; electronic emissions security; physical security; information, software, and hardware assurance; and technology specialties such as biometrics and cryptography. In addition, systems security engineering leverages contributions from other enabling engineering disciplines, specialties, and focus areas.14 Figure 1 illustrates the relationship among systems engineering, systems security engineering, and the contributing security and other specialty engineering and focus areas.

FIGURE 1: SYSTEMS ENGINEERING AND OTHER SPECIALITY ENGINEERING DISCIPLINES

The systems security engineering discipline provides the security perspective to systems engineering processes, activities, tasks, products, and artifacts. These processes, activities, and tasks are conducted in consideration of all system elements; the processes employed to acquire system elements and to develop, deliver, and sustain the system; the behavior of the system in all modes of operation; and the various forms of disruption, hazard, and threat events and conditions that constitute risk with respect to the intentional or unintentional loss of assets and associated consequences.

14 Enabling engineering disciplines and specialties include, for example, human factors engineering (ergonomics), reliability, availability, maintainability (RAM) engineering, software engineering, and resilience engineering.

Source: Adapted from Bringing Systems Engineering and Security Together, INCOSE SSE Working Group, February 2014.

SYSTEMS SECURITY ENGINEERING

SYSTEMS ENGINEERING

Other Specialty

Security Specialty

Security Specialty

Other Specialty

Security Specialty

SYSTEMS SECURITY ENGINEERING - A specialty engineering discipline

of systems engineering. - Applies scientific, mathematical,

engineering, and measurement principles, concepts, and methods to coordinate, orchestrate, and direct the activities of various security engineering and other contributing engineering specialties.

- Provides a fully integrated, system-level perspective of system security.

SECURITY AND OTHER SPECIALTIES - Performs and contributes to

systems security engineering activities and tasks.

- Contributions are seamlessly integrated through the systems security engineering activities and tasks.

- Reflects the need and means to achieve a multidisciplinary, SE-oriented approach to engineering trustworthy secure systems.

CrossFunc?onalTeamRequiredtoAddressCrossFunc?onalChallenge

What

Where

When

Who

Why

[email protected] ©CopyrightWilliamYoung,Jr,2017Ref:NISTSP800-160

By now we are all beginning to realize that one of the most intractable problems is that of defining problems (of knowing what distinguishes an observed condition from a desired condition) and of locating problems (finding where in the complex causal networks the trouble really lies). In turn, and equally intractable, is the problem of identifying the actions that might effectively narrow the gap between what-is and what-ought-to-be. ”Dilemmas in a General Theory of Planning.” Horst Rittel and Melvin Webber

Cybersecurity is a Wicked Problem

Formula?ng(Framing)aWickedProblemistheProblem!

What

Where

When

Who

Why

21

Security


Story of “Bob”

JustBecauseYouKnowWhatYouWantToBuild,Doesn’tMeanYouHaveDefinedtheProblem


SYSTEM THEORETIC PROCESS ANALYSIS FOR SECURITY (STPA-Sec)


STPA-Sec

STPA-Sec Extends STPA

•  Definesystempurposeandgoal•  Iden?fyaccidentsandhazards•  Drawthecontrolstructure•  Step1:Iden?fyunsafe/unsecurecontrolac?ons

•  Step2:Iden?fycausalscenarios•  Wargame

Controlledprocess

Controller

FeedbackControlAc?ons

STAMPModel

STPAHazardAnalysis

[email protected]

STPA-Sec Process

25

DefineandframesecurityproblemIdenNfylosses/accidents

IdenNfysystemhazards/constraints

ModelfuncNonalcontrolstructureIdenNfyunsafe/unsecurecontrolacNons

TracehazardouscontrolacNonsusinginformaNonlifecycleIdenNfyscenariosleadingtounsafecontrolacNons

IdenNfyscenariosleadingtounsecurecontrolacNons

PlacescenariosonD4CharttoIDmorecriNcalsecurityscenarios

Wargamesecurityscenariostoselectcontrolstrategy

Developnewrequirements,controls,anddesignfeaturestoeliminateormiNgateunsafe/unsecurescenarios

SystemEngineeringFounda6ons

Iden6fyTypesofUnsafe/UnsecureControl

Iden6fyCausesofUnsafe/UnsecureControlandEliminateorControlThem

RED=STPA-SecExtensiononSTPA


ProblemFramework•  Goal/Purpose•  UnacceptableLosses

Func?onalFramework•  Hazards•  ControlStructure•  Constraints/ControlRequirements

EnterpriseArchitecture•  Components&Connec?ons•  Disrup?onScenarios(Adversary,Accident,Nature)•  ControlSet

Ends

Ways

Means

Intent(Requirements)

Impact(Risk)

Analysis/Synthesis

Analysis/Synthesis


Defini6ons •  Mission(USMilitaryDoctrine)–“Thetask,togetherwiththepurpose,thatclearlyindicatestheac?ontobetakenandthereasontherefore.”

•  Business/MissionAnalysis(INCOSE)–“definingtheproblemdomain,iden?fyingmajorstakeholders,iden?fyingenvironmentalcondi?onsandconstraintsthatboundthesolu?ondomain…anddevelopingthebusinessrequirementsandvalida?oncriteria”

•  Hazard(USMilitaryDoctrine)--“Acondi?onwiththepoten?altocauseinjury,illness,ordeathofpersonnel;damagetoorlossofequipmentorproperty;ormissiondegrada?on.”

•  SecurityControl(NIST)--Asafeguardorcountermeasureprescribedforaninforma?onsystemoranorganiza?ondesignedtoprotecttheconfiden?ality,integrity,andavailabilityofitsinforma?onandtomeetasetofdefinedsecurityrequirements.

•  MissionAc?vitySystem-“Ano?onalpurposivesystemwhichexpressessomepurposefulhumanac?vity(amission)”(AdaptedfromCheckland,1984)


Security Engineering Analysis

• Determininglifecyclesecurityconcepts• Definingsecurityobjec?ves• Definingsecurityrequirements• Determiningmeasuresofsuccess

28

SecurityAnalysisProvidesaRigorousMannertoIden?fyWhattoProtectandHowtoProtectit

“Manysystemsfailbecausetheirdesignersprotectthewrongthings,orprotecttherightthingsinthewrongway”–RossAnderson“SecurityEngineering”


STPA-Sec For Security Engineering Analysis

ChemicalReactorExampleBasedonJohnThomasExampleUsedinEarlierSTPA

Tutorial.ExampleisUsedWithDrThomas’Permission.


STPA-Sec Process

30

Define&FrameProblem

Iden?fyUnacceptableLosses

Iden?fySystemHazards/Constraints

CreateFunc?onalControlStructure

Iden?fyHazardousControlAc?ons

GenerateCausalScenarios

Mi?ga?onsandControls

•  UseSTPA-Sectoperformthesecurityengineeringanalysistoinformthe

securityengineeringprocess

•  Useresultstoinformearlysystemengineeringtrades

•  Setthefounda?ontounderstand,informanddocumentsecurity

requirements


Chemical Reactor Design

•  Toxiccatalystflowsintoreactor

•  Chemicalreac?oncreatesheat,pressure

•  Waterandcondenserprovidecooling

31

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX

[email protected]’STPATutorial

Define & Frame Security Problem •  Definethesystempurposeandgoal:

“Asystemtodo{What=Purpose}bymeansof{How=Method}inordertocontributeto{Why=Goals}”

32

Define&FrameProblem







REACTORDESIGNSYSTEM

ManagementControlSystem

DesignedPhysicalSystem

CONTROLLER

PROCESS

outputsinputs

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


MissionAc?vitySystemCrea?onConfirmsOurUnderstandingandAidsControlStructureDevelopment

AdaptedfromDrThomas’STPATutorial

Chemical Reactor - Problem

•  Toxiccatalystflowsintoreactor•  Chemicalreac?oncreatesheat,pressure

•  Waterandcondenserprovidecooling

33

Whatdoesthesystemdo?Howdoesitaccomplishit?Whydoesthesystemexist?

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX

[email protected] ©CopyrightWilliamYoung,Jr,2017AdaptedfromDrThomas’STPATutorial


•  Verbsinthedescrip?onpointtothekeyprocessesthatmustbecontrolled

•  Flow•  Heat•  Condensing

34

Whatdoesthesystemdo?Howdoesitaccomplishit?Whydoesthesystemexist?

Define&FrameProblem








Chemical Reactor - Problem Asystemtocontainandprocesschemicals

bymeansoftransferring,mixing,andcoolingchemicals

inordercontributetoproduc?onofchemicalssoldbythecompany.

35

Define&FrameProblem









36

Asystemtocontainandprocesschemicalsbymeansoftransferring,mixing,andcooling

chemicalsinordercontributetoproduc?onofchemicals

soldbythecompany.

Define&FrameProblem







TheMissionAc?vitySystemDescrip?onisAbstract&Func?onal,NOTphysical

AbstractFunc?onal Physical(Architecture)

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX




chemicalsinordercontributetoproduc?onofchemicalssold

bythecompany.

37

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


Chemical Reactor - Losses

38

Define&FrameProblem







•  UnacceptableLosses(FromEarlierToday)

•  L-1:Peopledieorbecomeinjured•  L-2:ProducNonloss

Arethereotherunacceptablelosses?

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


Chemical Reactor - Losses

39

Define&FrameProblem







•  UnacceptableLosses(FromEarlierToday)

•  L-1:Peopledieorbecomeinjured•  L-2:ProducNonloss

Arethereunacceptablelossesrelatedtosecurity?

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


Chemical Reactor - Hazards

40

Define&FrameProblem







Hazard Descrip?on WorstCaseEnvironment

AssociatedLosses

H1:Plantreleasestoxicchemicals

H2:Plantisunabletoproducechemical

Whatsystemstateorsetofcondi?onstogetherwithasetofworst-caseenvironmentalcondi?onswillleadtoaloss?

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



41

Define&FrameProblem







Hazard L1:Peopledieorbecomeinjured

L2:ProducNonloss

H1:Plantreleasestoxicchemicals

H2:Plantisunabletoproducechemical

Hazardscrosscheck

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



42

Hazard SafetyConstraint

H1:Chemicalsinadvertentlyreleased

C1:

H2:??

Whatsystemstateorsetofcondi?onstogetherwithasetofworst-caseenvironmentalcondi?onswillleadtoaloss?

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



43

Hazard SafetyConstraint

H1:Chemicalsinairorgroundajerreleasefromplant

Chemicalsmustneverbereleasedinadvertentlyfromplant

H2:??

Whatarethesystemconstraints?

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


Chemical Reactor – Control Structure

44

Define&FrameProblem







•  WhatProcessesMustBeControlledinOrdertoAccomplishBusinessorMissionObjec?ve

•  Transferandmixingcatalyst•  Coolingreflux

•  UseInsightstounderstandControllerrequirements

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



soldbythecompany.



NeedFunc?onalEquivalent

45

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


Func6onal Control Structure

1.   Iden?fyModelElements2.   Iden?fyeachModelElement’sresponsibili?esincarryingouteachofthekey

ac?vi?esnecessaryconductthemission3.   Iden?fyControlRela*onships

4.   Iden?fytheControlAc*onsnecessaryforeachelementtoexecutetheirresponsibili?es

5.   DevelopProcessModelDescrip*on

6.   Iden?fyProcessModelVariables7.   Iden?fyProcessModelVariableValues

8.   Iden?fyFeedbackprovidingPMVValues

9.   CheckFunc?onalControlStructureModelforcompleteness

46

Define&FrameProblem









47

Define&FrameProblem







?

?

?

REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX

Asystemtocontainandprocesschemicals

bymeansoftransferring,mixing,andcoolingchemicals

inordercontributetoproduc?onofchemicalssoldbythecompany.



High-LevelFunc?onalAc?vity ModelElements Descrip?on

48

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



soldbythecompany.



High-LevelFunc?onalAc?vity ModelElements Descrip?on

Transfer Operator,Computer,Valves

Mix Operator,Computer,Valves,

Reactor

Cool Operator,Computer,Valves,

Condenser

49

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX



50

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX

KeyAc?vity:Transfer Element ResponsibilityDescrip?on Operator •  IniNateprocess

•  Monitorprogress•  ManuallyIntervene

Computer •  Controlvalves•  Reportstatus

Valves •  Open/closeoncommand•  Failopen?/Failclosed?



51

Define&FrameProblem







REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX

Valves

Computer

Operator

Open/closewatervalveOpen/closecatalystvalve

StartProcessStopProcess

Plantstatus

StatusinfoPlantstatealarm

PhysicalPlant


REACTOR

COMPUTER

CATALYST

PLANT STATUS

CONDENSER

COOLINGWATER

VENT

VAPOR

REFLUX


52

Whataretheunacceptablelosses?

Valves

Computer

Operator



Plantstatus


PhysicalPlant

Define&FrameProblem








Valves

Computer

Operator



Plantstatus


PhysicalPlant

Chemical Reactor – HCAs (Unsafe / Unsecure)

53

Define&FrameProblem







Whataretheunacceptablelosses?

HCA-HazardousControlAcNon


54

Chemical Reactor – HCAs (Unsafe / Unsecure) HCA-HazardousControlAcNon

ControlAc?on Notprovidingcauseshazard

Providingcauseshazard

IncorrectTimingorOrder

Stoppedtoosoonorappliedtoolong

CA1:StartProcess

CA2:OpenWaterValve


Chemical Reactor: Hazardous Control Ac6ons (HCA)

©CopyrightJohnThomas201755

ControlAc?on Notprovidingcauseshazard

Providingcauseshazard

IncorrectTimingorOrder

Stoppedtoosoonorappliedtoolong

CA1:StartProcess Operatorprovidescommandwhencondenserwatervalvenotfunc?oning

Operatormanuallyoverridesvalvesandcomputermissessignal

CA2:OpenWaterValve Computerdoesnotprovideopenwatervalvecmdwhencatalystopen

ComputerprovidesopenwatervalvecmdmorethanXsecondsaYeropencatalyst

Computerstopsprovidingopenwatervalvecmdtoosoonwhencatalystopen

CA3:CloseWaterValve Computerprovidesclosewatervalvecmdwhilecatalystopen

Computerprovidesclosewatervalvecmdbeforecatalystcloses

CA4:OpenCatalystValve Computerprovidesopencatalystvalvecmdwhenwatervalvenotopen

ComputerprovidesopencatalystvalvecmdmorethanXsecondsbeforeopenwater

CA5:CloseCatalystValve Computerdoesnotprovideclosecatalystvalvecmdwhenwaterclosed

ComputerprovidesclosecatalystvalvecmdmorethanXsecondsaYerclosewater

Computerstopsprovidingclosecatalystvalvecmdtoosoonwhenwaterclosed


Inadequate Control Algorithm

(Flaws in creation, process changes, incorrect

modification or adaptation)

Controller

ProcessModel(inconsistent,incomplete,orincorrect)

Control input or external information wrong or missing or malformed

Actuator InadequateoperaNon

Inappropriate, ineffective, malformed, or missing control action

Sensor InadequateoperaNon

Inadequate, malformed or missing feedback Feedback Delays

Componentfailures

ChangesoverNme

Controlled Process

Unidentified or out-of-range disturbance

Controller

Process input missing or wrong

Incorrect, partial or no information provided Measurement inaccuracies Feedback delays

Process output contributes to system hazard

Delayed, partial, or

malformed operation

Conflicting control actions

Missing or wrong or unauthorized communication with another controller

Sensor Actuator

Controller

Controller (?)

Controller (?)

Sensor Actuator


UCA:Computeropenscatalystvalvewhenwatervalvenotopen

57




Controller







Componentfailures

ChangesoverNme

Controlled Process


Controller





malformed operation



Sensor Actuator

Controller

Controller (?)

Controller (?)

Sensor Actuator

Step2:Poten?alcausesofUCAs


Computeropenswatervalve

58




Controller







Componentfailures

ChangesoverNme

Controlled Process


Controller





malformed operation



Sensor Actuator

Controller

Controller (?)

Controller (?)

Sensor Actuator

Step2:Poten?alcontrolac?onsnotfollowed


Scenario

59

UCA:Computerdoesnotprovideclosecatalystvalvecmdwhenwaterclosed

Scenario AssociatedCausalFactors RaNonale/Notes Watervalvestatussignalisincorrectlyprocessedbycomputer.

• Malformedsignalfromvalve• ParNalsignalfromvalve• Missingsignalfromvalve• Inconsistentprocessmodel

Maliciouslogiconwatervalvesystemreportsfalse/delayed/malformedinformaNon.Maliciouslogiconcomputermodifiesprocessmodelvariabletoindicatethatwatervalveisopen.


Causal Scenarios

60

UCA:ComputerprovidesopenwatervalvecmdmorethanXsecondsaYeropencatalyst

Scenario AssociatedCausalFactors RaNonale/Notes

Codeonthecomputerprocessesasynchronously.Assump?onsaboutthelatencyofcommandsviolatedcausingadelayedsendtowatervalve.

• Inadequatecontrolalgorithm• DelayedparNaloperaNon

TestandoperaNonalenvironmentwerelowlatencyandNmingerrorswerenottested.Maliciouslogiconcomputerorothersystemcausesdelayinthesendingorreceivingofcommand.


Causal Scenarios

61

UCA:Operatorprovidescommandwhencondenserwatervalvenotfunc?oning

Scenario AssociatedCausalFactors RaNonale/Notes

Operatorbelievesthatsystemsarefullyfunc?oning,andcommandsthestartofthereac?onprocess.

• Inadequatefeedbackfromcomputeronwatervalvestatus• Malformedsensordataincorrectlyindicatesgreen• ParNaldatacomingfromsensorcausescomputertoindicatewrongstate• Missingstatusfeedbackfromvalve

Unaccountedforerrorstateinsojwareusedbymaliciouslogicinvalveand/orcomputer.


Wargaming

•  EvaluateeffectsofATackonConstraint

•  Assesscostofconstraintapproach,costofaTack,complexityofaTack

•  RedSelectGeneralATackClasstoViolateConstraint

•  BlueConstraintEnforcementStrategy

BlueMove

RedMove

AssessEffects

AssessCosts

62

BluefocusonEnforcingConstraint,Redfocusonviola?ngconstraint…Goalisto“Fix”ProblemThroughElimina?onorMi?ga?onAboveComponentLevel


Lessons Learned Applying STPA-Sec •  Often heard comments:

•  “You’re starting at a much higher level of abstraction…” •  “We try to do something like that, but STPA-Sec is much more rigorous…” •  “This requires a great deal of thought…from more than just security

experts”

•  Difficult or impossible to implement if system owner is unable cannot specify what system is supposed to do

•  Initial expert guess on what is most important to assure tends to be too broad to be actionable

•  E.g. “Power grid”

STPA-SecisNOTasilverbullet,butappearstoenableincreasedrigor“LeYofDesign”

63 [email protected] © Copyright William Young, 2017

Recent Self-Reported Assessment Results

64

4

14

4

2

BeforeTraining:AbilitytoDevelopMi?ga?onStrategy

SomewhatCapable

Capable

VeryCapable

AbsolutelyCapable

1

10

13

1

AYerTraining:AbilitytoDevelopMi?ga?onStrategy

SomewhatCapable

Capable

VeryCapable

AbsolutelyCapable


Safety and Security

• Goalislosspreven?onandriskmanagement

• Sourceisprobablyirrelevantandmaybeunknowable

• Methodisthedevelopmentandengineeringofcontrols

• Focusonwhatwehavetheabilitytoaddress,nottheenvironment

•  STPA/STPA-Secprovideopportunityforaunifiedandintegratedeffortthroughsharedcontrolstructure!


Conclusion

• Mustthinkcarefullyaboutdefiningthesecurityproblem

• Perfectlysolvingthewrongsecurityproblemdoesn’treallyhelp

•  STPA-Secprovidesameanstoclearlylinksecuritytothebroadermissionorbusinessobjec?ves

•  STPA-Secdoesnotreplaceexis?ngsecurityengineeringmethods,butenhancestheireffec?veness


Concluding Thoughts from Sun Tzu

Theopportunitytosecureourselvesagainstdefeatliesinourownhands.

Thesupremeartofwaristosubduetheenemywithoutfigh6ng.

Strategywithouttac6csistheslowestroutetovictory.Tac6cswithoutstrategyisthenoisebeforedefeat.


QUESTIONS ??

My Contact Informa6on

[email protected]

69

Special Thanks

DrJohnThomasforprovidingthebaselinereactorproblemframeworkandini?alSTPAanalysis

Date post:	22-Nov-2021
Category:	Documents
Upload:	others
View:	6 times
Download:	0 times

System-Theoretic Process Analysis for Security (STPA-SEC ...

Documents