Methodological Findings from Applying STPA in Cyber ...psas.scripts.mit.edu/home/wp-content/uploads/2019/04/1...2019/04/01 · in Cyber Security Case Studies • Intro to the role

Thisinforma,onisexemptundertheFreedomofInforma,onAct2000(FOIA)andmaybeexemptunderotherUKinforma,onlegisla,on.ReferanyFOIAqueriestoncscinfoleg@ncsc.gov.uk.AllmaterialisUKCrownCopyright©

Methodological Findings from Applying STPA in Cyber Security Case Studies DrAnnaG.–SociotechnicalSecurityResearcherUKNa,onalCyberSecurityCentre


Methodological Findings from Applying STPA in Cyber Security Case Studies

•  IntrototheroleoftheUKNa,onalCyberSecurityCentre(NCSC)

•  OurWorkwithSTAMPandSTPA

•  MethodologicalFindings:-  TypeBScenarioGenera,on

-  Documenta,onofaddi,onalinforma,onsuchassubsystemstatesandcondi,ons


UKNa&onalCyberSecurityCentre

Actasabridgebetweenindustry,governmentandacademia

Unifiedsourceofadvice,guidanceandsupportoncybersecurity

MIT STAMP Conference March 26th 2019

SociotechnicalSecurityGroup

Cybersecurityresearchinprac,ce

Sociotechnicallensoncybersecurityproblems

Mul,disciplinary

Vision:TomaketheUKthe

safestplacetoliveandworkonline

Interac,onsbetweenpeople,technology,organisa,onsand

processes


Our Work with STAMP and STPA

RiskFrameworks–CoreResearchQues&ons:

Dowehavetherightmixoftools/techniques/frameworks

forthecybersecurityproblemsoftodayandinthefuture?

Ifnot,whatdoweneedtoensure

ourcybersecurityrisktoolboxisfitforthecybersecurityproblemsoftoday

andinthefuture?


Systemstheore,capproachestocybersecurityrisk,

andSTAMPinpar,cular,shouldbepartofourcybersecurity

risktoolbox.


Our Work with STAMP and STPA Exploringapplicabilitytoavarietyofdifferentusecases:

Tradi&onalcybersecurityscenarios

•  EnterpriseITinfrastructure

Jointsafetyandcybersecuritycontexts•  Automated/connectedproducts

•  Industrialcontrolsystems•  Cri,calna,onalinfrastructure

NumberofcasestudiesworkingwithUKstakeholdersinvolvingsystemsindesignandinopera&ons



Illustrative Example – Drone


KeyPoints-  Casestudyinvolvinganautomatedproductin

design

-  Userinterfacesuchasasmartdevice

-  Safetyandsecurityconcerns-  CompletedseveralSTPAitera,ons-  IncreasinglydetailedandcomplexHCS

Thisinforma,onisexemptundertheFreedomofInforma,onAct2000(FOIA)andmaybeexemptunderotherUKinforma,onlegisla,on.ReferanyFOIAqueriestoncscinfoleg@ncsc.gov.uk.AllmaterialisUKCrownCopyright©MIT STAMP Conference March 26th 2019

Controller

Controlledprocess

Controlac,ons Feedback

ControlAlgorithm

ProcessModel

TypeA

TypeB

Methodological Findings: Type B Scenario Generation WhywouldanUnsafeControlAc,onoccur?

Whywouldcontrolac,onsbeimproperlyexecutedornotexecuted,leadingtohazard?

STPAStep4:Iden,fyLossScenariosandRequirementsOuroriginalmethodappliedincasestudies-  TakeeachindividualUCAiden,fiedinStep3-  ApplyTypeAscenariothinkingtotheUCA-  ApplyTypeBscenariothinkingtotheUCAToolimited-  TypeBscenarioslinkeddirectlytohazard-  CanapplyTypeBtocontrolac,onsButnotwanttoloserela,onshipbetweenUCAsandbothtypesofscenarios


Type B Scenario Generation How to generate the broadest range of Type B scenarios to inform subsequent requirements? Adjustedmethodologyappliedincasestudies:-  TakeeachindividualUCAiden,fiedinStep3-  ApplyTypeAscenariothinkingtotheUCA-  ApplyTypeBscenariothinkingtotheUCA-  ApplyTypeBscenariothinkingtothecontrolac,on

asawhole-  ConsiderrequirementsgeneratedfrombothTypeA

andBscenariosappliedtotheindividualUCAswhengenera,ngrequirementstomi,gateTypeBscenariosfromcorrespondingControlAc,on

Illustra&veDroneExample

CA.1Take-offCA.2Land

CA.3PairsmartdeviceCA.4Unpairsmartdevice



CA.9PairsmartdeviceCA.10Revokesmartdevice

User

Interface(SmartDevice)

InternalAutomatedController

CentralManagementSubsystem

CA.11Pairsmartdevice

CA.12Revokesmartdevice


Interplay between Type A and Type B Scenarios and Requirements Illustra&veDrone

ExampleTypeBScenarioanalysisappliedtoCA.5‘Take-off’andCA.6‘Land’

Serial From To Ac&on TypeBScenarioDescrip&on Hazard Addi&onalRequirements

CA.5 Interface(SmartDevice)


Take-off

Thesescenariosrefertoasitua,oninwhichthecommandsarenotac,oned.Thiscouldoccurduetoafailureinthecontrolpath,eitherbyamaliciousactorjammingtheconnec,on,orbyatechnicalfailure.Thereisalsoapossibilitythatlegi,matecommandsfromtheuserwouldbecountermandedinthecontrolpathbyaspoofedsmartdevice.Theseriskshavealreadybeenmi,gatedbyR3.5andR.3.9.

H.02,H.03

None–exposureto

hazardmi,gatedbyexis,ng

requirements.

CA.6 Interface(SmartDevice)


Land






User







Interplay between Type A and Type B Scenarios and Requirements Illustra&veDrone

Example

TypeBScenarioanalysisappliedtoCA.12RevokesmartdeviceSerial From To Ac&on TypeBScenarioDescrip&on Hazard Addi&onal

Requirements

CA.12 CentralManage-mentSubsystem


Revokesmartdevice

InthisscenariotheCA‘Revokesmartdevice’isnotreceivedorac,onedbytheInternalAutomatedController.Thiscouldallowcontrolac,onsfromastolenorspoofedsmartdevicetocon,nuetoexertcontroloverthedrone.Currentlycommandsfromthesmartdeviceandthecentralmanagementsystemcouldbereceivedcontemporaneouslyandthosefromthesmartdevicecouldbeac,oned,overridingthosefromthecentralmanagementsystem.Mi,ga,onwouldbetoprivilegethecommandsfromthecentralmanagementsubsystemoverothercontrollers.

H.01,H.05

R.3.28Thereshouldbea

mechanismtoensurethatcommandsfromtheCentral

ManagementSystemare

givenprecedence

overcommandsfromothercontrollers.






User







Interplay between Type A and Type B Scenarios and Requirements Whatdidthisapproachgiveus?

-  Broadbasisforgenera,ngbothtypesofscenariosandcorrespondingrequirements

-  U,lityinprac,ceofconsideringthepoten,alexposure

tohazardfromdifferentdirec,ons

-  Foundnewscenariosandaddi,onalrequirements

-  InterplaybetweenscenariosandrequirementsgeneratedfromindividualUCAsandthecontrolac,ontheUCAisderivedfrom

Requirement Derivedfrom: Connec&ontoHazard

R3.5 UCA3.2-TypeACA.5-TypeBCA.6-TypeB

H.02H.03

R3.9 UCA3.2-TypeACA.5-TypeBCA.6-TypeB

H.02H.03

R3.28 CA.12-TypeB H.01H.05

…… ….. ……

-  Traceabilityofrequirementstomul,plescenariosandexposuretohazard

-  Addedweighttonecessityofrequirementswhencommunica,ngfindings


Methodological Findings: Documentation of Subsystem States / Conditions • CaseStudyExampleKeyPoints:-  Automatedproductindesign-  Safetyandsecurityconcerns-  Geo-fencedperimeterforlanding-  Importanceof:•  Sequencingofavailablecontrolac,ons•  Movingbetweenstatesof‘Disabled’,‘FlightMode’,‘StandbyPassive’and‘StandbyAc,ve’


User



PhysicalProcesses

CA.Checklandingarea(whenin‘Standby

Passive’)CA.Land(whenin‘StandbyActive’)

F.Landingareaclear(i.e.changeto

‘StandbyActive’)/Notclear

(i.e.remainin‘StandbyPassive’)

Landed/Notlanded

CA.Land

CA.Land

GeolocationDetectionSubsystem

CA.Providegeolocation

status

F.Withinperimeter(i.e.changeto

‘StandbyPassive’)/Notwithinperimeter(i.eremainin‘Flight

Mode’)

F.Landed/Notlanded/Drone

Status


Status

Illustra&veDrone

Example


Documentation of Subsystem States / Conditions From To Control

Ac&onWhenthiscondi&onistrue:

Feedback Changetostatus?

User Interface Land StandbyPassiveorStandbyAc,ve

LandedNotLandedDroneStatus

N/A

AutomatedInternalController

Geoloca,onDetec,onSubsystem

Providegeoloca,onstatus

Allstates WithinperimeterNotwithinperimeter

StandbyPassiveNochange


PhysicalProcesses

Checklandingarea

StandbyPassive

LandingareaclearNotclear

StandbyAc,veNochange

AutomatedInternalcontroller

PhysicalProcesses

Land StandbyAc,ve

LandedNotlanded

N/A


User



PhysicalProcesses

CA.Checklandingarea(whenin‘Standby

Passive’)CA.Land(whenin‘StandbyActive’)

F.Landingareaclear(i.e.changeto

‘StandbyActive’)/Notclear

(i.e.remainin‘StandbyPassive’)

Landed/Notlanded

CA.Land

CA.Land

GeolocationDetectionSubsystem

CA.Providegeolocation

status

F.Withinperimeter(i.e.changeto

‘StandbyPassive’)/Notwithinperimeter(i.eremainin‘Flight

Mode’)


Status


Status

Illustra&veDrone

Example


Documentation of Subsystem States / Conditions From To Control

Ac&onWhenthiscondi&onistrue:




N/A







PhysicalProcesses

Checklandingarea

StandbyPassive

LandingareaclearNotclear



PhysicalProcesses

Land StandbyAc,ve

LandedNotlanded

N/A


Helpsdefinewhatop,onsareavailableunderwhatcondi,ons

toformpartofControlAlgorithmofaController

HelpsdefinewhatfeedbackaControllerneedsforitsProcessModelandwhatitneedstoknowaboutthestateofthesystem


Documentation of Subsystem States / Conditions

From To ControlAc&on Whenthiscondi&onistrue:




N/A







PhysicalProcesses

Checklandingarea

StandbyPassive LandingareaclearNotclear



PhysicalProcesses

Land StandbyAc,ve LandedNotlanded

N/A


Addi,onalinforma,ontoberecorded:-  Subsystemstates-  Condi,onsthatmustbetruefortransi,onsbetween

suchstates-  Subsequentchangestostatusdependentonwhat

feedbackisreceived

Mayhelpanalysttospot:-  Missingsubsystemstates-  Missingcondi,onsnecessaryfortransi,ons-  Sequencingerrorsleadingtohazard

Mayhelpanalysttogenerate:-  UCAs-  Lossscenarios-  Requirementstomi,gateexposuretohazard

Dependentonsystemunderanalysis-  Levelofcomplexity/detailoftheHCS-  Numberofsubsystemstates/condi,ons


Our Next Steps

•  Con,nuetodeepenourunderstandingofSTAMP(STPAandCAST)inrela,ontocybersecurity

•  Provideadviceandguidanceasapplicableacrossourbroadremit

•  Expandthesystemstheore,capproachesavailableinourcybersecurityrisktoolbox



Ques&ons?

Contact:[email protected]


Documents

Methodological Findings from Applying STPA in Cyber ...psas.scripts.mit.edu/home/wp-content/uploads/2019/04/1...2019/04/01 · in Cyber Security Case Studies • Intro to the role