You are on page 1of 158

1

2
3

6
7
8

PART4:TECHNICALSECURITY
REQUIREMENTSFORANINDUSTRIAL
AUTOMATIONANDCONTROLSYSTEMS

9
10

Draft1Edit02
200803

11
12

THISDRAFTVERSIONISSTRICTLYFORREVIEWBY
ISASP99MEMBERSONLY

13
14
15

ThisdocumentisaworkproductoftheISASP99committee.ItISNOTpartofanydraftstandardor
technicalreport.CopiesmaybesharedforpurposesrelatedtotheoperationoftheSP99committee,
butallcopiesmustreproduceacopyrightnoticeasfollows:

16

Copyright2008ISA.Allrightsreserved.ReproducedanddistributedwithpermissionofISA.

17
18
19
20

Thereaderiscautionedthatthisdocumenthasnotbeenapprovedandcannotbepresumedtoreflect
thepositionofISAoranyothercommittee,society,orgroup.Althougheveryefforthasbeenmadeto
ensureaccuracy,neitherISA,membersoftheS&PDepartment,northeiremployersshallbeheldliable
forerrorsorlimitations.

21

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Forward................................................................................................................................... v

TheISA99series ..................................................................................................................... vi

RelationshipsoftheISA99standardstotheISA99technicalreports ..................................... vi

Introduction ...........................................................................................................................vii

Scope....................................................................................................................................... 8

References............................................................................................................................... 8

Definitionsoftermsandacronyms.......................................................................................... 8

Definitionofterms .................................................................................................................................... 8

Definitionofacronyms .............................................................................................................................. 9

10

Threatassessmentandsecuritypolicy................................................................................... 10

11

Threatassessmentvectors...................................................................................................................... 10

12

Buildingachainoftrust .......................................................................................................................... 10

13

Identificationoftrustedanduntrustedcomponents ............................................................................. 11

14

Securityconsiderationsforindustrialautomationandcontrolsystems................................. 12

15

Twoperspectives:ITandControlSystemOperation.............................................................................. 12

16

Technologyroadmaps ............................................................................................................................. 14

17

Catalogofsources ................................................................................................................................... 15

18

Standards,recommendedpracticesandguidelines ............................................................................... 15

19

Securityassurance................................................................................................................. 16

20

Securityfoundationalrequirements ...................................................................................... 17

21

Accesscontrol ......................................................................................................................................... 17

22

Usecontrol .............................................................................................................................................. 17

23

Dataintegrity.......................................................................................................................................... 17

24

Dataconfidentiality ................................................................................................................................. 18

25

Restrictdataflow .................................................................................................................................... 18

26

Timelyresponsetoevent ........................................................................................................................ 18

27

Networkresourceavailability ................................................................................................................. 18

SP99Part4Draft1Edit0320080310Word972003format.doc

Pagei

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

Derivedrequirementsforeffectivesecurity .......................................................................... 19

Protectionofdataatrest ........................................................................................................................ 19

Securityoftheindustrialcontrolnetwork .............................................................................................. 22

FieldcommunicationsandfielddeviceSecurity ..................................................................................... 43

Automationcellsecurity ......................................................................................................................... 52

ControlNetworkHostsecurity................................................................................................................ 57

Interactiveremoteaccesssecurity.......................................................................................................... 72

Enterprisenetwork/Controlnetworkinterconnectionsecurity ........................................................... 99

Intercontrolcentersecurity ................................................................................................................. 120

10

AnnexA:Bibliography ......................................................................................................... 130

11

AnnexB:SystemdynamicsManagingComplexity ............................................................. 132

12

Thecyberspaceproblemdomain......................................................................................................... 132

13

Theneedtoaccountfortimeandeventdynamics .............................................................................. 133

14

Bewaryofmoresecurityisbetter ........................................................................................................ 133

15

AnnexC:Humanbehaviorresponsetosecurity................................................................... 135

16

Dynamictriggers.................................................................................................................................... 135

17

Bewareofdefenseindepth ................................................................................................................. 137

18

Impactofexcessivesecurity.................................................................................................................. 138

19

Privacyissues......................................................................................................................................... 139

20

Factorfictiontheneedforvalidation................................................................................................ 140

21

AnnexD:GuidanceforusingISA99.00.04 ........................................................................... 142

22

AnnexE:FieldCommunicationandDevices ........................................................................ 145

23

Monitoringandcontrolparadigmsforautomationsystems................................................................ 148

24

Needsforindustrialdevicetodevicefieldcommunications ............................................................... 149

25

Patternsofindustrialfieldcommunicationsuse .................................................................................. 151

26

Usageclassesofindustrialdevicetodevicefieldcommunications ..................................................... 153

SP99Part4Draft1Edit0320080310Word972003format.doc

Pageii

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

TABLEOFFIGURES

Figure1Typicalautomationcellnetworkconfiguration............................................................................ 53

Figure2NotionalIRAreferencetopology .................................................................................................. 73

Figure3NotionalECIreferencetopology................................................................................................. 100

Figure4NotionalintercontrolcenterNetworktopology........................................................................ 122

Figure6Notionaldegradationofsecurityassurance ............................................................................... 133

Figure7Dynamictriggerhypothesis ........................................................................................................ 136

Figure8EnablingDefenseinDepth ......................................................................................................... 137

10

Figure9Theconsequencesofimplementingsecuritymeasures............................................................. 138

11

Figure10Impactofexcesssecurity .......................................................................................................... 139

12

Figure11SmartCardforDiD ..................................................................................................................... 140

13

14

TABLEOFTABLES

15

Table1SummaryofITandcontrolsystemdifferences ............................................................................. 12

16

Table2DataatRestsecurityrequirements................................................................................................ 20

17

Table3Malware,virusandTrojansecurityprotectionrequirements ....................................................... 21

18

Table4IdentityandaccessmanagementSecurityrequirements.............................................................. 24

19

Table5Confidentiality,integrityandavailabilitysecurityrequirements................................................... 25

20

Table6DefenseinDepthsecurityrequirements....................................................................................... 26

21

Table7Networkroutingdevicehardeningsecurityrequirements............................................................ 29

22

Table8Fieldcommunicationandfielddevicesecurityrequirements....................................................... 46

23

Table9Automationcellinterconnectionsecurityrequirements............................................................... 53

24

Table10Controlnetworkhostsecurityrequirements............................................................................... 58

25

Table11IRANetworktopologysecurityRequirements............................................................................. 76

SP99Part4Draft1Edit0320080310Word972003format.doc

Pageiii

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

Table12IRADataflowsecurityrequirements ........................................................................................... 84

Table13IRAsecuritycomponentsecurityrequirements .......................................................................... 88

Table14IRAoperationssecurityrequirements ......................................................................................... 94

Table15IRAsecuritypolicyrequirements ................................................................................................. 98

Table16ECInetworktopologysecurityrequirements ............................................................................ 102

Table17ECIdataflowsecurityrequirements .......................................................................................... 109

Table18ECIsecuritycomponentrequirements....................................................................................... 112

Table19ECIoperationssecurityrequirements........................................................................................ 114

Table20ECIsecuritypolicyrequirements................................................................................................ 120

10

Table21ICCnetworktopologysecurityrequirements ............................................................................ 124

11

Table22ICCdataflowsecurityrequirements.......................................................................................... 126

12

Table23iCCoperationssecurityrequirements........................................................................................ 126

13

Table24ICCpolicysecurityrequirements................................................................................................ 128

14

Table25ApplicablerequirementsofISA99.00.04forusers.................................................................... 142

15

Table26Fieldcommunicationsanddeviceusageclasses ....................................................................... 145

16

Table27Costconsiderations .................................................................................................................... 145

17

Table28Availabilityandperformanceconsiderations ............................................................................ 146

18

Table29Compatibilityandscalabilityconsiderations.............................................................................. 146

19

Table30Qualityofserviceconsiderations ............................................................................................... 147

20

Table31Securityconsiderations .............................................................................................................. 147

21

SP99Part4Draft1Edit0320080310Word972003format.doc

Pageiv

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

FORWARD

3
4
5
6
7
8

ThisisthefourthinaseriesofISAstandardsthataddressesthesubjectofsecurityforindustrial
automationandcontrolsystems.Thefocusisontheelectronicsecurityofthesesystems,commonly
referredtoascybersecurity.ThisPart4standarddefinesthecharacteristicsofindustrialautomation
andcontrolsystemsthatdifferentiatethemfromotherinformationtechnologysystemsfromasecurity
pointofview.Basedonthesecharacteristics,thestandardestablishesthesecurityrequirementsthat
areuniquetothisclassofsystems.

9
10
11
12

ThisstandardisstructuredtofollowISO/IECdirectivespart2forstandardsdevelopmentascloselyas
possible.Anintroductionbeforethefirstnumberedclausedescribestherangeofcoveragetheentire
seriesofstandards.Itdefinesindustrialautomationandcontrolsystemsandprovidesvariouscriteriato
determinewhetheraparticularitemisincludedinthescopeofthestandards.

13

Clause1definesthescopeofthisstandard.

14
15

Clause2listsnormativereferencesthatareincorporatedaspartofthisstandardbecausetheyare
indispensablefortheapplicationofthedocument.

16
17

Clause3isalistoftermsanddefinitionsusedinthisstandard.Mostaredrawnfromestablished
references,butsomearederivedforthepurposeofthisstandard.

18
19

Clause4summarizesaninformativedescriptionofthreatsandpolicythatprovidesthecontextfor
evaluatingsecurityoptionsspecifiedinthisstandard.

20
21
22

Clause5providesaninformativedescriptionofthesituationwithrespecttothesecurityofindustrial
automationandcontrolsystemsthatformthecontextforspecifyingthefoundationalandderived
requirementsinthenormativeclausesofthisstandard.

23

Clause6specifiesthenormativeproceduretomodelandcalculatesecurityassurancelevels.

24
25

Clause7specifiesthenormativefoundationalrequirementsforsecureindustrialautomationandcontrol
systems

26
27

Clause8specifiesthenormativesecurityrequirementstoeffectivelyimplement,commission,maintain
andmanagesecurityforindustrialandautomationenterprises.

28
29
30
31

Part4annexesareincludedtoprovideinformativeexplanationsofthebackgroundandrationalusedto
developthenormativerequirementsofthisstandard.Thefirstannexisabibliographyofworkscitedin
thisstandard.AnnexD:GuidanceforusingISA99.00.04mapsthenormativerequirementstoexpected
audienceinterest.

SP99Part4Draft1Edit0320080310Word972003format.doc

Pagev

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

THEISA99SERIES

2
3

StandardsintheISA99seriesaddressallaspectsofsecurityforindustrialautomationandcontrol
systems.Theseriesisorganizedbypartsdescribedbelow.

ISA99.00.01Part1:Terminology,ConceptsandModels

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Part1establishesthecontextforalloftheremainingstandardsintheseriesbydefininga
commonsetofterminology,conceptsandmodelsforelectronicsecurityintheindustrial
automationandcontrolsystemsenvironment.
ISA99.00.02Part2:EstablishinganIndustrialAutomationandControlSystemSecurityProgram
Part2describestheelementsofacybersecuritymanagementsystemandprovideguidancefor
theirapplicationtoindustrialautomationandcontrolsystems.
ISA99.00.03Part3:OperatinganIndustrialAutomationandControlSystemSecurityProgram
Part3addresshowtooperateasecurityprogramafteritisdesignedandimplemented.This
includesdefinitionandapplicationofmetricstomeasureprogrameffectiveness.13
ANSI/ISA99.00.012007Copyright2007ISA.Allrightsreserved.
ISA99.00.04Part4:TechnicalSecurityRequirementsforIndustrialAutomationandControlSystems
Part4definesthecharacteristicsofindustrialautomationandcontrolsystemsthatdifferentiate
themfromotherinformationtechnologysystemsfromasecuritypointofview.Basedonthese
characteristics,thestandardwillestablishthesecurityrequirementsthatareuniquetothisclass
ofsystems.

21

RELATIONSHIPSOFTHEISA99STANDARDSTOTHEISA99TECHNICAL
REPORTS

22
23

TwotechnicalreportsproducedbytheISA99committeeonthesubjectofelectronicsecuritywithinthe
industrialautomationandcontrolsystemsenvironmentwereusedasaguidelineforthisstandard.

24

ANSI/ISATR99.00.012007TechnologiesforProtectingManufacturingandControlSystems

20

25
26
27

TechnicalReport1,updatedfromtheoriginal2004version,describesvarioussecurity
technologiesintermsoftheirapplicabilityforusewithindustrialautomationandcontrol
systems.Thistechnicalreportwillbeupdatedperiodicallytoreflectchangesintechnology.

28
29

ANSI/ISATR99.00.022004IntegratingElectronicSecurityintotheManufacturingandControlSystems
Environment

30
31
32

TechnicalReport2describeshowelectronicsecuritycanbeintegratedintoindustrial
automationandcontrolsystems.Thecontentsofthistechnicalreportissupersededwithbythe
Part2standard.

SP99Part4Draft1Edit0320080310Word972003format.doc

Pagevi

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

INTRODUCTION

2
3
4

Thesubjectofthisstandardissecurityforindustrialautomationandcontrolsystems.Inordertoaddress
arangeofapplications(i.e.,industrytypes),eachofthetermsinthisdescriptionhavebeeninterpreted
verybroadly.

5
6
7
8
9

Thetermindustrialautomationandcontrolsystems(IACS)includescontrolsystemsusedin
manufacturingandprocessingplantsandfacilities,buildingenvironmentalcontrolsystems,
geographicallydispersedoperationssuchasutilities(i.e.,electricity,gas,andwater),pipelinesand
petroleumproductionanddistributionfacilities,andotherindustriesandapplicationssuchas
transportationnetworks,thatuseautomatedorremotelycontrolledormonitoredassets.

10
11
12
13
14

Thetermsecurityisconsideredheretomeanthepreventionofillegalorunwantedpenetration,
intentionalorunintentionalinterferencewiththeproperandintendedoperation,orinappropriate
accesstoconfidentialinformationinindustrialautomationandcontrolsystems.Electronicsecurity,the
particularfocusofthisstandard,includescomputers,networks,operatingsystems,applicationsand
otherprogrammableconfigurablecomponentsofthesystem.

15
16
17
18
19
20
21
22
23

Theaudienceforthisstandardincludesallusersofindustrialautomationandcontrolsystems(including
facilityoperations,maintenance,engineering,andcorporatecomponentsofuserorganizations),
manufacturers,suppliers,governmentorganizationsinvolvedwith,oraffectedby,controlsystemcyber
security,controlsystempractitioners,andsecuritypractitioners.Becausemutualunderstandingand
cooperationbetweeninformationtechnology(IT)andoperations,engineering,andmanufacturing
organizationsisimportantfortheoverallsuccessofanysecurityinitiative,thisstandardisalsoa
referenceforthoseresponsiblefortheintegrationofindustrialautomationandcontrolsystemsand
enterprisenetworks.AnnexD:GuidanceforusingISA99.00.04providesausersguideofapplicable
securityrequirements.

24

TypicalquestionsaddressedbythisPart4standardinclude:

25
26
27
28
29
30
31

Howdoesoneestablishaquantitativesecurityassurancelevelfortheindustrialautomationand
controlsystem,andallocatesecurityassurancetosubsystemsandcomponents?
Whatenablingtechnologiesandtechnicalconsiderationscontributetocosteffectivesecurity?
WhatsecurityrequirementsarederivedfromthefoundationalrequirementsoutlinedinPart1?
Whatistheinteractionorcouplingbetweenderivedsecurityrequirementsallocatedtothe
zonesandconduitsoftheindustrialautomationandcontrolsystem,andhowarethese
allocationsconstrainedbyoperationalprocedures,availabilityandperformance?

SP99Part4Draft1Edit0320080310Word972003format.doc

Pagevii

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

SCOPE

2
3
4
5

ISA99.00.04(Part4)definesthenormativetechnicalsecurityrequirementstoachieveanassetowners
targetsecurityassurancelevel(SAL)foranIndustrialAutomationandControlSystem(IACS).Thesystem
includesallpersonnel,hardwareandsoftwareusedtoensuresafe,secureandreliableoperationofan
industrialprocess.Thesesystemsinclude,butarenotlimitedto:

6
7
8
9
10
11
12
13
14
15

Distributedcontrolsystems(DCS),programmablelogiccontrollers(PLC),remoteterminalunits
(RTU),intelligentelectronicdevices(IED),supervisorycontrolanddataacquisition(SCADA),
measurementunits,monitoringunits,anddiagnosticsystems.
Processcontrolsystems(PCS)includesafetyinstrumentedsystem(SIS)functionsthatare
separateunitsorembeddedinprocesscontroldevices.
Associatedinformationsystemssuchasadvancedormultivariablecontrol,onlineoptimizers,
dedicatedequipmentmonitors,graphicalinterfaces,historians,manufacturingexecution
systemsandplantinformationmanagementsystems.
Associatedhuman,networkormachineinterfacesusedtoprovidecontrol,safetyand
manufacturingoperationsforcontinuous,batch,discreteandotherprocesses.

REFERENCES

16
17
18
19

[1] ISA99.00.01Part1:Terminology,ConceptsandModels
[2] ISA99.00.02Part2:EstablishinganIndustrialAutomationandControlSystemSecurityProgram
[3] ISA99.00.03Part3:OperatinganIndustrialAutomationandControlSystemSecurityProgram

20

21

DEFINITIONSOFTERMSANDACRONYMS

22

DEFINITIONOFTERMS

23
24
25
26

3.1.1.

27
28
29

3.1.2.

30
31

b) processbywhichuseofsystemresourcesisregulatedaccordingtoasecuritypolicyandispermitted
onlybyauthorizedentities(users,programs,processes,orothersystems)accordingtothatpolicy

Accessauthority
entityresponsibleformonitoringandgrantingaccessprivilegestoIACSsandtheirassociatedindustrial
networksforotherauthorizedentities

Accesscontrol
a) protectionofsystemresourcesagainstunauthorizedaccess

SP99Part4Draft1Edit0320080310Word972003format.doc

Page8

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4

accountability
propertyofasystem(includingallofitssystemresources)thatensuresthattheactionsofasystem
entitymaybetraceduniquelytothatentity,whichcanbeheldresponsibleforitsactions

5
6
7

3.1.4.
applicationlayerprotocol
layer7protocolspecifictoexecutingnetworkapplicationssuchasemailandfiletransfer

8
9

Note:Manymodernindustrialcontrolsystemsincludefieldbusnetworks,whichdonotnormallyinclude
sevendistinctlayers,butdohaveanapplicationlayer.

3.1.3.

10
11
12

3.1.5.
authentication
aprocessthatestablishestheoriginofinformation,orvalidatesanentitysidentity.

13
14
15
16
17
18
19
20

3.1.6.
Authorization
Accessprivilegesgrantedtoanentity;conveysanofficialsanctiontoperformasecurityfunctionor
activity.

3.1.7.
availability
timely,reliableaccesstoinformationbyauthorizedentities.

21
22
23
24

3.1.8.
tamperevident
adeviceorprocessthatmakesunauthorizedaccesstotheprotectedobjecteasilydetected.Thismay
taketheformofseals,markingsorothertechniques.

25
26
27
28

3.1.9.
tamperresistant
resistancetotamperingbyeitherthenormalusersofaproduct,package,orsystemorotherswith
physicalaccesstoit

29
30
31

3.1.10.
tamperresponse
providingsensorstodetecttamperingandassociatedresponsemechanisms

32

{Morecominginalaterdraftwaitingonmaturity}

33
34

DEFINITIONOFACRONYMS
{TBSinalaterdraftwaitingonmaturity}

SP99Part4Draft1Edit0320080310Word972003format.doc

Page9

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4
5
6

THREATASSESSMENTANDSECURITYPOLICY
Threatassessmentandsecuritypolicymustbeinplacetoprovideaproperframeworkforconsidering
arrayofsecurityoptionsthatcouldbedeployed.Thisinformativeclauseprovidesabriefreviewofthe
threatassessmentvectors,theneedtobuildachainoftrust,andtheidentificationoftrustedand
untrustedcomponents.

THREATASSESSMENTVECTORS

8
9
10
11
12

Threatassessmentvectorsarederivedfromanunderstandingofthethreat,thechainoftrust,
identificationoftrustedanduntrustedcomponentsandthesecurityvulnerabilitiesoftheterminal
devices.ISA99.00.02[2]addressestheneedtounderstandthethreatsandtoputinplaceaneffective
securityprogram.Thoserequirementsareincorporatedbynormativereferenceintotheconsiderations
offeredbyISA99.00.04.

13

BUILDINGACHAINOFTRUST

14
15
16
17
18
19
20
21

Buildingachainoftrustbetweenterminaldevices,networkdevicesandprocesscontrolIEDsthathave
accesstoprocesscontroldataiscritical.Infact,itsoftenmoreimportanttoauthenticatetheterminal
deviceaccessthecontrolnetworkorprocesscontrolIEDthatthepeopleusingthem.Thisisparticularly
trueinapplicationswherecompaniesneedtotrustthecomputersusedtochangeoperationalsettings
orupdateprogramsthatcontrolproductionfunctionswithinaspecificIEDorsubsystem.Theabilityto
trustthecomputersmanagingtheprocesscontroldataoraccessingthecontrolnetworksisvital.Thais
canbecomplicatedbythefactthatmultiplevendorsmayhavelegitimateneedtoaccessthese
networksanddevices.

22
23
24
25
26

Softwareonlyimplementationsareinadequateparticularlywheretheincentivetoattackishigh.
Softwareonlysolutionsoftenrequireconsiderableexpensetodevelopandimplement.Butbecausethe
code,encryptionalgorithmsandkeysareexposed,theycanberelativelyeasytoattackandclone
especiallywiththemanyreverseengineeringtoolsthatarereadilyavailablefordownloadingonthe
Internet.

27
28
29
30

Forexample,withinaterminaldeviceitbecomesessentialtoisolatethesecuritycriticalprocessingfrom
therestoftheapplication.Throughthephysicalinterfaceswherecommandsanddataaredeliveredto
andfromtheterminaldevice,anadversarywillattempttoexploitsystemimplementationflaws.Oncea
vulnerabilityisfound,securitycomponentsthatarenotisolatedbecomesusceptibletoattack.

31
32
33

Toprovideprivacy,authentication,andnonrepudiation,securitymustincludeacombinationof
hardwareandsoftware.Evenifanadversarycanreverseengineeraportionofsoftwaretowhichhehas
access,hestilldoesnthaveenoughinsightintowhatisgoingoninthehardware.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page10

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

IDENTIFICATIONOFTRUSTEDANDUNTRUSTEDCOMPONENTS

2
3
4

Controlnetworksdefinedbyconduitsandroutingdevices(routers,switches,wirelessaccesspoints)are
trustednetworksiftheirsecurityrequirementsetsareimplemented.Componentsattachedtothe
controlnetworksaretrustediftheirrequirementsetsareimplemented.

5
6
7

However,iftherequirementsetsfortheattachedcomponentsarenotimplemented,orifasecurity
eventoccurs,theterminaldevice,networkdeviceorprocesscontrolIEDshouldincludesecurity
mechanismstoprovideanotherlevelofdefenseindepth.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page11

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

SECURITYCONSIDERATIONSFORINDUSTRIALAUTOMATIONAND
CONTROLSYSTEMS

4
5
6
7
8

Manysourceswereconsideredtodeveloptheprescriptivesecurityrecommendationsandguidelinesfor
industrialautomationandcontrolsystems.Thesesourcesincludestandardsdevelopedbyother
recognizedorganizations,reportsbyUSnationallaboratoriesandroadmapsdevelopedbyUS
governmentandothercountrygovernmentorganizationsorconsortiums.Thisinformativeclause
summarizesthecontributionofthesesources.

TWOPERSPECTIVES:ITANDCONTROLSYSTEMOPERATION

10
11
12
13

Itisimportanttounderstandthedifferencesoftwoperspectivesofsecurity:theperspectiveoftheIT
organizationandtheperspectiveoftheprocesscontrolsystemoperations.KimFenrich(Fenrich,Kim;
February2008)summarizedthesedifferencesinaverysuccincttable.ThedifferencesshowninTable1
areamplifiedinboththeinformativeandnormativeclausesofthisstandard.
TABLE1SUMMARYOFITANDCONTROLSYSTEMDIFFERENCES

14
Category

InformationTechnologySystem

IndustrialControlSystem

Performancerequirements

Nonrealtime.Responsemust
beconsistent.Highthroughput
required.Highdelayandjitter
maybeacceptable

Realtimeresponseistime
critical.Modestthroughputis
acceptable.Highdelayand/or
jitterisaseriousconcern.

Availabilityrequirements

Responsessuchasrebootingare
acceptable.Availability
deficienciescanoftenbe
tolerated,dependingonthe
systemsoperational
requirements.

Responsessuchasrebooting
maynotbeacceptablebecause
ofprocessavailability
requirements.Outagesmustbe
plannedandscheduled
days/weeksinadvance.High
availabilityrequiresexhaustive
predeploymenttesting.

Riskmanagementrequirements

Dataconfidentialityandintegrity
areparamount.Faulttolerance
islessimportant;momentary
downtimeisnotamajorrisk.
Majorriskimpactisdayof
businessoperation.

Humansafetyisparamount,
followedbyprotectionofthe
process.Faulttoleranceis
essential,evenmomentary
downtimeisnotacceptable.
Majorimpactisregulatorynon
compliance,lossoflife,
equipmentorproduction.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page12

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Category

InformationTechnologySystem

IndustrialControlSystem

Architecturesecurityfocus

PrimaryfocusisprotectingtheIT
assetsandtheinformation
storedonortransmittedamong
theseassets.

Primarygoalistoprotectedge
clients(forexample,field
devicessuchasprocess
controllers).Protectionof
centralserverisstillimportant.

Unintendedconsequences

Securitysolutionsaredesigned
aroundtypicalITsystems.

Responsessuchasrebooting
maynotbeacceptablebecause
ofprocessavailability
requirements.

Timecriticalinteraction

Lesscriticalemergency
interaction.Tightlyrestricted
accesscontrolcanbe
implementedtothedegree
necessary.

Responsetohumanandother
emergencyinteractioniscritical.
Accessshouldbestrictly
controlled,yetnothamper
humanmachineinteraction.

Systemoperation

Systemsaredesignedforuse
withtypicaloperatingsystems.
Upgradesarestraightforward
withtheavailabilityautomated
deploymenttools.

Differingandcustomoperating
systemsoftenwithoutsecurity
capabilities.Softwarechanges
mustbecarefullymade,usually
bysoftwarevendors,becauseof
thespecializedcontrol
algorithmsandperhapsmodified
byhardwareandsoftware
involved.

Resourceconstraints

Systemsarespecifiedwith
enoughresourcestosupportthe
additionofthirdparty
applicationssuchassecurity
solutions.

Systemsaredesignedtosupport
theintendedindustrialprocess,
withminimalmemoryand
computingresourcestosupport
theadditionofsecurity
technology.

Communications

Standardcommunication
protocols.Primarilywired
networkswithsomelocalized
wirelesscapabilities.TypicalIT
networkingpractices.

Manyproprietaryandstandard
communicationprotocols.
Severaltypesofcommunication
mediausedincludingdedicated
wireandwireless(radioand
satellite).Networksarecomplex
andsometimesrequirethe
expertiseofcontrolengineers.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page13

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Category

InformationTechnologySystem

IndustrialControlSystem

Changemanagement

Softwarechangesareappliedin
atimelyfashioninthepresence
ofgoodsecuritypolicyand
procedures.Theproceduresare
oftenautomated.

Softwarechangesmustbe
thoroughlytestedanddeployed
incrementallythroughouta
systemtoensurethatthe
integrityofthecontrolsystemis
maintained.Outagesoftenmust
beplannedandscheduled
days/weeksinadvance.

Managedsupport

Allowfordiversifiedsupport
styles.

Servicesupportisusuallyviaa
singlevendor.

Componentlifetime

Lifetimeontheorderof35
years.

Lifetimeontheorderof1520
years.

Accesstocomponents

Componentsareusuallylocal
andeasytoaccess.

Componentscanbeisolated,
remoteandrequireextensive
physicalefforttoaccess.

TECHNOLOGYROADMAPS

2
3
4

Twoqualitytechnologyroadmapsprovideconsiderableguidanceforthedevelopmentofthe
prescriptiverecommendationsandguidelinesspecifiedinthisstandard.

5
6
7

TheUSDepartmentofEnergy(DoE)publishedaRoadmaptoSecureControlSystemsintheEnergy
Sector(USDepartmentofEnergyJanuary2006)outliningneededresearchinitiativesinthenearterm
(2006and2007),themidterm(20072010),thelongterm(20102015)andtheendstate(2015) 1 .

8
9
10
11

TheEuropeanUnion(EU),EuropeanCommission(EC)JointResearchCenter(JRC)publishedICT
VulnerabilitiesofPowerSystems:AroadmapforFutureResearch(GRIDConsortiumDecember2007)
outliningresearchinitiativeinthenearterm(20072009),themidterm(20092013),thelongterm
(20142020)andthefinalstate(2020) 2 .

12

Althoughthetimeframesdifferslightly,bothroadmapsaddressthesameneedsineachperiod:

Nearterm,midtermandlongtermwasdescribedinperiodsof02years,25yearsand510years
respectively.BasedonthepublicationdateoftheDoEroadmap,theseperiodsaremappedtocalendar
years.

Nearterm,midtermandlongtermwasdescribedinperiodsof03years,38yearsand815years
respectively.BasedonthepublicationdateoftheGRIDroadmap,theseperiodsaremappedtocalendar
years.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page14

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4
5
6
7

Establishscientificbasesandtoolsthatcrosscutissues,raisingawarenessandproviding
educationinthenearterm.
Providingstructuralmeasures(actions)forcomponentsandarchitectures,andaddressing
societalandgovernanceissuesinthemidterm.
Deployingprotectivemeasures,remedialactionsandrealtimeapplicationsinthelongterm.

ISA99standardsfitwellinbothroadmaps.ISA99.00.04isdesignedtoprovidetheprescriptive
recommendationsandguidelinesneededtomeetthelongtermobjectives.

CATALOGOFSOURCES

8
9
10
11
12
13
14
15
16
17
18

TheUSDepartmentofHomelandSecurity(DHS)commissionedtheIdahoNationalLaboratory(INL)to
developCatalogofControlSystemsSecurity:RecommendationsforStandardsDevelopers(US
DepartmentofHomelandSecurityJanuary2008).Thisdocumentprovidesacatalogofrecommended
requirementstobeusedinthefacilitationofthedevelopmentandimplementationofcontrolsystem
cybersecuritystandards.Includedisacompilationofpracticesrecommendedbyvariousorganizations
forincreasingthesecurityofcontrolsystemsfrombothphysicalandcyberattacks.Therecommended
requirementsinthiscatalogaregroupedby18families,orcategories,withsimilaremphasis.The
recommendedrequirementsforeachofthefamiliesaredisplayedwithasummarystatementofthe
requirement,supplementalguidanceorclarification,andarequirementenhancementstatement
providingaugmentationfortherequirementunderspecialsituations.

19
20

INLscatalogwasavaluableresourceusedinthedevelopmentoftheprescriptiverecommendationsand
guidelinesspecifiedinthisdocument.

21

STANDARDS,RECOMMENDEDPRACTICESANDGUIDELINES

22

23

{TBSneedanauthor}

SP99Part4Draft1Edit0320080310Word972003format.doc

Page15

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2

SECURITYASSURANCE

3
4
5
6
7

ISA99.00.01[1]definessecurityassuranceasthelevelcorrespondingtotherequiredeffectivenessof
countermeasurestothwartcyberattacksagainstindustrialautomationsystems.ISAintendstoprovide
ascaleofsecurityassurancelevelswhichassetownerscanusetoestablishaminimumsetof
requirements.Eachsetisdesignedtoprotectselectedzonesorconduitsagainstaccesstoanduseof
devices,systemsanddata.

8
9

Thesecuritylevelofthesystem(Ssystem)isdescribedasthesumoftheweightedsecuritylevelsofthe
components(wisi).

10

Ssystem=

is i

11
12

Basedontheownersassessmentofriskandevaluationofconsequences,wi(theweighting)andsi(the
securitylevelofthecomponent)areassignedbytheassetowner.

13
14
15
16
17
18

Itisimportanttonotethatsiisnotastatementofprobability,andthereisnorequirementthatsi=[0,1].
Itismorelikeascore.AsimilarapproachisdescribedintheCommonVulnerabilityScoringSystem
(CVSS);however,itisnotobviouswhysishouldberelatedtoaprobabilityofoccurrencewhichisthe
foundationpremiseofCVSS.Itismorelikelythatsiisameasureoftheconsequenceofthefailureto
adequatelyprotectthesystemagainstanadversaryinducedattack.Thatis,ifsiishigh,theconsequence
resultingfromanattackislow;i.e.,ameasureofeffectiveness.

19
20
21
22
23

Thetargetsecuritylevelofasystemcan,withconsiderableeffort,bedeterminedfortheNIST80053
and80082documents.TheproblemisthatthereisnoinsightintheNISTpublicationsastohowan
assetownershouldallocatesystemlevelsecuritytargettothecomponent(orsubsystem)security
levels.Bethatasitmay,thetargetvalueforthesystemshouldbegreaterthantheestimated
(calculated)valueforthesystem.

24

Ssystem

25
26
27
28
29
30
31

SAL1 ISA99.00.04recommendsthefollowingprocedure:
1. TheassetownerestimatesthetargetlevelofthesystemusingNIST80053(NISTSP800
53n.d.)and80082.
2. UsingthesameassumptionsandrulessetforthintheNISTpublications,theassetowner
calculatesthesecuritylevelofthesystembysummingtheweightedcomponents.Thisis
nowthedesignsecurityassurancelevelforthesystem.
3. Iftheestimated(calculated)designsecuritylevelforthesystemisgreaterthan

32
33
34
35

somethingisamissprobablytheassumptionsareeithernotconsistent,orthe
applicationoftheassumptionshasnotbeencorrectlyperformed.Ineithercasetheasset
ownermustredobothestimates.
4. Iftheestimateddesignsecuritylevelforthesystemislessthan
thedifferenceis

36
37

thedesignmargin.Giventheuncertaintyinallfactorsofthisprocess,beginningwiththe
uncertaintyintheinitialriskassessmentandconsequenceanalysisaswellasthe
SP99Part4Draft1Edit0320080310Word972003format.doc

Page16

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2

uncertaintyinproperlyapplyingtheassumptions(asdiscussedabove),adesignmargin
ontheorderof100%isprobablyreasonable.

SECURITYFOUNDATIONALREQUIREMENTS

4
5
6
7
8

ISA99.00.01[1]establishedsevenfoundationalsecurityrequirements.Theserequirementsareusedto
derivetheprescriptiverecommendationsandguidelinesspecifiedinISA99.00.04.Furthermorebecause
ofthesynergismbetweenrequirements,ISA99.00.04specificationstendtofocusonenabling
technologiesthatprovideacomprehensivesecuritysolution.Thegoalistoreducethecostof
implementingandmaintainingsecurityasdescribedinISA99.00.02[2]andISA99.00.03[3].

ACCESSCONTROL

10
11

FR1 Controlaccesstoselecteddevices,informationorbothtoprotectagainstunauthorized
interrogationofthedeviceorinformation.

12
13
14
15
16
17

Rationale:Usingtheirriskassessmentmethodology,assetownerswillselectdevicesandinformation
thatrequirestrongaccesscontrolprotection.Derivedprescriptiverecommendationsandguidelines
shouldincludemechanismsthatwilloperateinmixedmodes;e.g.,somedevicesonacommunication
channelrequirestrongaccesscontrolandothersdonot.Byextension,accesscontrolrequirements
needtobeextendedtodataatrest;i.e.,ensurestrongaccesscontroltodatathatresidesinselected
repositories.

18

USECONTROL

19
20

FR2 Ensuretheintegrityofdataonselectedcommunicationchannelstoprotectagainst
unauthorizedoperationofthedeviceoruseofinformation.

21
22
23
24
25

Rationale:Usingtheirriskassessmentmethodology,assetownerswillselectcommunicationchannels
thatrequirestrongusecontrolprotection.Derivedprescriptiverecommendationsandguidelinesshould
includemechanismsthatwilloperateinmixedmodes;e.g.,somecommunicationchannelsrequire
strongusecontrolprotectionandothersdonot.Byextension,usecontrolrequirementsneedtobe
extendedtodataatrest;i.e.,ensurestrongusecontroltodatathatresidesinselectedrepositories.

26

DATAINTEGRITY

27
28

FR3 Ensuretheintegrityofdataonselectedcommunicationchannelstoprotectagainst
unauthorizedchanges.

29
30
31
32
33

Rationale:Usingtheirriskassessmentmethodology,assetownerswillselectcommunicationchannels
thatrequirestrongintegrityprotection.Derivedprescriptiverecommendationsandguidelinesshould
includemechanismsthatwilloperateinmixedmodes;e.g.,somecommunicationchannelsrequire
strongintegrityprotectionandothersdonot.Byextension,dataintegrityrequirementsneedtobe
extendedtodataatrest;i.e.,protecttheintegrityofdatathatresidesinselectedrepositories.
SP99Part4Draft1Edit0320080310Word972003format.doc

Page17

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

DATACONFIDENTIALITY

2
3

FR4 Ensuretheconfidentialityofdataonselectedcommunicationchannelstoprotectagainst
eavesdropping.

4
5
6
7
8
9

Rationale:Usingtheirriskassessmentmethodology,assetownerswillselectcommunicationchannels
thatrequirestrongconfidentialityprotection.Derivedprescriptiverecommendationsandguidelines
shouldincludemechanismsthatwilloperateinmixedmodes;e.g.,somecommunicationchannels
requirestrongconfidentialityprotectionandothersdonot.Byextension,confidentialityrequirements
needtobeextendedtodataatrest;i.e.,protecttheconfidentialityofdatathatresidesinselected
repositories.

10

RESTRICTDATAFLOW

11
12

FR5 Restricttheflowofdataoncommunicationchannelstopreventthepublicationof
informationtounauthorizedsources.

13
14
15
16
17

Rationale:Usingtheirriskassessmentmethodology,assetownerswilldeterminewhatinformation
mustberestrictedforpublication,andbyextensionblockthecommunicationchannelsusedtodeliver
thesedata.Derivedprescriptiverecommendationsandguidelinesshouldincludemechanismsthat
rangefromdisconnectingcontrolnetworksfrombusinessorpublicnetworkstousingstatefulfirewalls
andDMZtomanagetheflowofinformation.

18

TIMELYRESPONSETOEVENT

19
20
21

FR6 Respondtosecurityviolationsbynotifyingtheproperauthority,reportingneeded
forensicevidenceoftheviolation,andautomaticallytakingtimelycorrectiveactionin
missioncriticalandsafetycriticalsituations.

22
23
24
25

Rationale:Usingtheirriskassessmentmethodology,assetownerswillestablishpoliciesandproper
linesofcommunicationandcontrolneededtorespondtosecurityviolations.Derivedprescriptive
recommendationsandguidelinesshouldincludemechanismsthatcollect,reportandautomatically
correlatetheforensicevidencetoensuretimelycorrectiveaction.

26

NETWORKRESOURCEAVAILABILITY

27
28

FR7 Ensuretheavailabilityofallnetworkresourcestoprotectagainstdenialofservice
attacks.

29
30
31
32

Rationale:Usingtheirriskassessmentmethodology,assetownerswillestablishpoliciesandguidelines
forcommunicationnetworkoperationalredundancyandbyextensionsupportinginformation
repositories.Theseguidelineswillincludecriteriaofemergencyshutdownprocedures,reconfiguration
procedures,restartproceduresandhotswitchoverprocedures.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page18

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3

DERIVEDREQUIREMENTSFOREFFECTIVESECURITY
TherequirementsetsspecifiedinISA99.00.04areforthemostpartharmonizedwiththerequirement
setsinIEC62443(IEC624432008).

PROTECTIONOFDATAATREST

5
6
7
8

Protectionofdataatrestisamissioncriticalsecurityrequirementforindustrialautomationcontrol
systems.Becausedataatrestexiststhroughouttheenterprise,acomprehensivesecuritypolicy,security
solutionanddeploymentstrategyisneeded.Recommendedsecuritysolutionsmustaddressdataatrest
residinginfixedandportablerepositories.

9
10
11
12
13
14
15

Dataresidingintheserepositoriesmayrequiresignificantlydifferentsecurityrequirements.For
example,securitykeysforencryptionshouldcomplywithNISTFIPS1422(NISTFIPS14022001)
requirements;however,anonsensitivememomaynotrequireanysecurityprotection.Lastly,itis
importanttounderstandthatinahighlynetworkedenvironment,whichisthecaseforISA99.00.04,we
mustthinkaboutdataashavingapointofpresence,ratherthanflowingfrompointAtopointB.For
thisreason,protectionofdataatrestmustaoccurasclosetoitssourceoforiginationaspossible,and
theseprotectionmechanismsmusttravelwiththedatathroughoutitslifetime.

16
17
18
19
20

Accesscontrol,usecontrol,dataconfidentialityandintegrityarefourofthefoundationalrequirements
thatrequirespecialattentiontoprotectdataatrest.Andbecauseoftheinsidiousnatureofmalware,
virusandTrojanthreatagentsthatattachthemselvestodataobjects,protectionmechanismsneedto
bedesignedwiththeappropriatecountermeasurestomitigatethesethreats.Thecombinationofthese
requirementspresentsasignificantchallengefordesigningacomprehensivesecuritysolution.

21

Foundationalrequirementprotectionmechanisms

22
23
24
25
26

Thegoalistofindonecomprehensivesecuritymechanismforstrongaccesscontrol,usecontrol,
confidentialityandintegritythatcanbetailoredtoprovidethesecurityassurancelevelspecifiedbythe
assetowner.Themechanismmustbecosteffectiveintermsofprocurement,deploymentand
maintenanceoveritslifecycle.Andmostimportantly,managingthesecuritymustberelativelyeasyto
ensureitsacceptancebythoseentrustedwithsecurityresponsibilities.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page19

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE2DATAATRESTSECURITYREQUIREMENTS
Requirement
ID

Requirement specification

Rationale

I&AM1

Providethecapabilitytoprovide
strongaccesscontrol,usecontrol,
confidentialityandintegritysecurity
assuranceforanynameddataobject.

Acomprehensivesecuritymechanismis
neededtoprovideanintegratedsolutionfor
accesscontrol,usecontrol,confidentialityand
integrity.Suchacoherentmechanismwill
minimizetheimplementationofstovepipe
securitysolutionsdesignedtoaddresseach
requirementindependently.

I&AM2

Providethecapabilitytoimplement
I&AM1withinasinglerepository
withthegranularitytoestablish
securityassurancelevelsforan
objectdefinedasarecord,file,
physicalmedium,etc.

Theintentistoimplementasecurity
mechanismthatminimizestheneedfor
physicalseparationofdataobjectsthat
requiredifferentsecurityassurancelevels.

I&AM3

Providethecapabilitymanageaccess
anduseprivilegesusingrolebased
accesscontrolthatisadministeredby
theorganizationalunitmostclosely
associatedwiththesourceor
functionthatcreatesthedataobject.

Theobjectiveistoimplementacommon
securityassurancepolicythatisadministered
locally.Thecentralmanagementorganization
(enterpriseauthority)isresponsiblefor
oversightoftheexecutionbyall
organizationalunitsincludingpartners,
suppliersandgovernmentoversightagencies.

I&AM 4

Providethecapabilitytouseany
validatedcryptographicalgorithmto
matchthesecurityassurance
requirementsforconfidentialityand
integrity.

Theobjectiveistoprovideagraceful
migrationofacceptablecryptographic
mechanismsthatwillbedevelopedinthe
future.

I&AM 5

Cryptographicmoduleshallbe
designedandcertifiedtobein
compliancewithFIPS1402soasto
achievethesecurityassurancelevel
specifiedbytheassetowner.

Tamperresistantandtamperproof
requirementswillbedefinedbythesecurity
assurancelevel.
Note:TheUniversityofCambridgehas
reportedsystemlevelfailuresoftamper
proofing(Drimer,MurdochandAnderson
February2008).Securityassuranceneedsto
addressthisissue.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page20

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4
5
6

PROTECTIONAGAINSTMALWARE,VIRUSANDTROJANS
Commercialproductsarereadilyavailabletoprovideprotectionagainstmalware,virusandTrojan
threats.Ingeneral,theseproductsworkwellforofficeenvironmentsandInternetbrowsing.Theymay
notworkwellinanindustrialautomationandcontrolsystemwhereavailabilityandperformanceare
missioncriticalconstraints.
TABLE3MALWARE,VIRUSANDTROJANSECURITYPROTECTIONREQUIREMENTS
Requirement
ID

Requirement specification

Rationale

MV&T1

Subjecttoperformanceconstraints,servers,
desktops,networkattachedstoragedevices,
oranyotherstorageappliancesshallhave
suitableantivirussoftwareinstalledandkept
uptodate.

Thefirstlineofdefenseistokeep
MV&Toutoffilesentirely.

MV&T2

Anydatastoredonpubliclyavailableservers
(includingthirdpartyserviceproviders)shall
haveanassociatednumericalsumchecksum
toverifyfiletransmissionintegrity

Checkingthischecksumwillprevent
datafrombeingmodifiedintransit
orfromusingoutofdateversionsof
software.

MV&T3

Datastoragepointsshouldincludefilebased
integritycheckersthatrunperiodicallyto
reportonanyfilemodifications.

Filebasedintegritycheckerscan
automaticallydetectmodifications
toanystoredfileandreportonthe
variance.

MV&T4

Virusscanningshallbeappliedtoanybackup
mediapriortouse.

Intheeventofaviruscompromise,
orsomeonecompromisesbackup
datastorage,thismeasurewill
mitigatereplicatingavirusbackonto
amachinebeingrestored.

MV&T5

Thirdpartyprovidersneedto
Offsitedatastorageprovidedbythirdparty
datamanagementprovidersshallcomplywith oversightauditsduetovarying
ServiceLevelAgreementsandperiodicaudits implementationsofsecuritysystems.
conductedbytheassetownertoensurethat
antivirusandmalwareprotection
mechanismsandproceduresareinplace,up
todate,andareproperlyperformed.

MV&T6

Rootkitanalysisshallbeappliedperiodicallyto Rootkitsareoftennotfoundbyanti
alldatastoragedevices
virussoftwareandcanbevery
difficulttodetectwithoutspecial
tools.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page21

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement
ID
MV&T7

Requirement specification

Rationale

Activeportandservicesscansshallbe
performedperiodicallytoidentifynew
networkservicesthatareenabled.

Backdoorsmayoftenbeinstalledor
writtenthatdonotmatchknown
virussignatures(suchasusingnetcat
toestablishasocket).Periodically
reviewingandcomparingtolastrun
willlimitthisexposure.

SECURITYOFTHEINDUSTRIALCONTROLNETWORK

3
4
5
6

ISA99.00.01includesareferencemodeldescribingzones,conduitsandtargetsecurityassurancelevels
inprocesscontrolsystemsthatneedtobeprotectedfromcyberattack.Thenormativeclausesdefine
therequirementssetsneededforperimeterdefenseandintrazonedefenseindepthprotectionagainst
selectedthreatassessmentvectors.

7
8

Informativeinformationisneededtosupporttherecommendationtoembedobjectsincontrolnetwork
routingdevicesandterminaldevicestoimprovetheprotectionofferedbyothermechanisms.

9
10
11
12
13

"Integrated security" describes the security functionality that is provided on a networking


device, for example on a router, switch, or wireless access point. As traffic passes through a
networking device, it must be scanned and analyzed, then allowed to continue, partitioned, or
rejected. This requires that the integrated security device possess intelligence, performance,
and scalability.

14
15

"Embedded security" refers to security functionality that is distributed across key locations in
the plant network infrastructure and terminal devices.

16
17
18
19

Embedded,integratedsecuritymustdefendthenetworkagainstexternalandinternalthreat,always
strikingabalancebetweentheneedforaccessandtheneedforprotection.Thatmeanssecurity
functionalitymustbeembeddedandintegratedeverywhere,butthatitalsomustbetransparenttothe
userandapplication.

20
21
22

Thegoalistodeployasetofsecuritycapabilitiesthattogethercreatean"intelligentselfdefending
network"thatcanidentifyattacksastheyoccur,alertasappropriate,andthenautomaticallyrespond,
withoutuserintervention.

23
24
25
26
27

EMBEDDINGPERIMETERDEFENSEOBJECTSINTERMINALDEVICES
Fromarequirementsanalysispointofview,theterminaldeviceispartofazoneasdefinedintheISA
99.0.01referencemodel.Becauseofoverlapswithotherrequirementsetsdefinedforcomponentsin
thezone,theterminaldevicerequirementsetislimitedtotheadditionalrequirementsthatarenot
addressedbyothercomponents.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page22

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3

Ifrequiredbyacompanyssecuritypolicy,highintegritysecuritysolutionsthatcreateahardware
enforcedsecurityenvironmentmaybeneeded.Becauseofthespecialissuesintroducedbytheinsider
threat,theuseofaPortableTerminalDevice(PTD)mustbeaddressed.

4
5
6

TheterminaldevicerequirementsetsspecifiedinISA99.00.04requiresecuritymechanismsthatshould
beimplementedwithacommonfoundationalbasetominimizedeploymentofuniquesolutionswhich
arenotinteroperable,oraredifficulttomanage.

7
8
9
10
11
12
13

Specialattentionmustbegiventoportableterminaldevices.Intodaysindustrialautomationsystems,
mobilecomputingisfastbecomingthenorm.Mobiledevices,suchasnotebooksforengineeringoreven
PDAscanbeconnectedeverywhereinordertocollectdata,tomaintainproductprocessortostartup
complexindustrialplants.Andthatswherethelies.Forthosesoinclined,improperlyprotecteddatais
thereforthetakingateverypointwhereamobiledeviceisconnected.Itissimplyamatterof
motivation.Ontheotherhand,mobiledevisearesuitablealternatehostsforallkindsofviruses,
wormsorTrojans,whichcanbemovedanddistributedfromonelocationtoanother.

14

VULNERABILITIESOFTHETERMINALDEVICE

15
16
17
18
19
20
21
22
23
24
25
26

ThreatsandtheresultingsecurityvulnerabilitiesdefinedinISA99.00.02[2]areapplicabletothecontrol
network.Thisspecificationaddsnoadditionalthreatsorresultingsecurityvulnerability.However,,the
terminaldeviceintroducessomeuniqueconsiderations.

27
28
29
30
31

Thedominantconcernistheinsiderthreat.
Theterminaldeviceandtechnicianmaybefromanexternalorganization.
Terminaldevicesmaybeusedforconfigurationchanges,testdrivers,monitoring,etc.
Theterminaldevicemaynotbeunderstrictconfigurationandusecontrol(mightbeusedfor
otherpersonaluseorcompanyuserequiringaccesstononsecurenetworks).Forthisreason,
malwaresuchasvirusinfection,Trojans,areofparticularconcern.
Patchmanagementandconfigurationmanagementmustincludesecuritymechanismsneeded
toensuretheconfidentialityandintegrityofthepatchestobeinstalledbytheservice
technician.
SECURITYREQUIREMENTSETSFORTERMINALDEVICES

Requirementsetsarespecifiedforthefollowing:

IdentityandaccessmanagementseeTable4
Confidentiality,integrityandavailabilityseeTable5
DefenseindepthseeTable6

SP99Part4Draft1Edit0320080310Word972003format.doc

Page23

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE4IDENTITYANDACCESSMANAGEMENTSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

I&AM6

Thereshallbeapolicyinplace,which
ensures,thatterminaldevicescan
connectedonlytowelldefined(access)
pointsofthecompany.Thispolicyshallbe
enforcedbytechnicalmeasureswhichmay
differ,dependingofthecurrenttechnical
configurationandtheusecaseofthe
terminaldevice.

Terminaldevicesaresuitabletobypass
perimeterborderlines,e.g.whenthey
areconnectedbehindasecuritygateway.
Sotheusecasehastobebalancedwith
possiblesecurityrisks.

I&AM7

Aminimumoftwofactorauthentication
shouldberequiredtogainaccesstoany
networkordevicetowhichtheterminal
deviceisphysicallyorlogicallyattached.

Twofactorauthenticationrequiresthat
thepersongainingaccesshavean
authenticationkeyandacontrolledPIN
numbersomethingphysicaland
somethingknown.Theadvantageoftwo
factorauthenticationisthataccess
privilegescanbecontrolledandare
auditable.

I&AM8

Alldevicestowhichtheterminaldevicehas Unauthorizedaccessattemptsshould
accessshallbealarmed.
resultinanalarmthatcanberemotely
monitored.

I&AM9

Allaccesses(unsuccessfulattemptsand
successfulentry)shallbeloggedand
reportedtoanexternalmonitorlogging
facilitywithin5(TBR)seconds.

Agoodsecuritypolicyrequirestheability
toauditallactivitythatcouldresultina
breachofsecurity.Thereportshould
includeallforensicinformationneeded.

I&AM10

Allidentityinformationrelatedtotheentry
shallbeadequatelyday/timestampedand
includedwiththereporttothemonitor
loggingfacility.

:Day/timestampsareneededto
correlateinformation.

Requirementsaregroupedintothreesets:confidentiality,integrityandavailability.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page24

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

TABLE5CONFIDENTIALITY,INTEGRITYANDAVAILABILITYSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

CIA1

Inaccordancewithcompanysecurity
policy,allmissioncriticalinformation
residingontheterminaldeviceshallbe
encrypted.

Confidentialityrequiresthatinformation
onlybeavailabletothosewhoare
authorizedandauthenticatedtoviewthis
informationandtopreventconfidential
informationfrombeingtransferredfrom
onevenuetoanothervenue.

CIA2

Accesstoencryptedinformationresiding
ontheterminaldeviceshallbe
controlledthroughtheuseofdigitally
signedcertificatesorotheracceptable
securitymechanisms.

Confidentialityrequiresthataccessto
informationonlybeavailabletothosewho
areauthorizedandauthenticatedtoreceive
thisinformation.

CIA3

Givenaccesstoencryptedinformation
residingontheterminaldevice,use
(read/write)privilegesshallbe
controlledthroughtheuseofdigitally
signedcertificatesorotheracceptable
securitymechanisms.

Confidentialityrequiresthatread/writeuse
ofinformationberestrictedtoonlythose
whoareauthorizedtoperformaspecific
task.

CIA4

Inaccordancewithcompanysecurity
policy,bothsourceintegrityanddata
integrityshallbeimplementedusing
standardandwellunderstood
mechanisms.

Integrityrequiresthattheoriginatorofthe
informationbeknownandcredible,andthe
securitymechanismspreventinadvertentor
maliciousmodificationsofthedata.

CIA5

Asaminimum,astandardchallengeand
responsealongwithasharedsecretkey
toprovideauthenticationshallbe
implemented.

Challengeandresponsemechanismsare
effectivemeanstoinsurethattheoriginator
oftheinformationisknownandcredible.

CIA6

Asaminimum,signeddigitalcertificates
shallbeusedtopreventintegrity
violations.

Whereascryptographydetectsintegrity
violations,accesscontrolpreventsintegrity
violations.

3
4
5

Denialofserviceattacksareextremelydifficulttoprotectagainst,whilemaintainingthecommunication
abilitiesoftheterminaldevice.Thereisvirtuallynosecuritymechanismthatcanbeimplementedinthe
terminaldevicepersethatprotectsagainstsuchadenialofserviceattack.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page25

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3

Defenseindepthmay,dependingontheconclusionsofriskassessments,requireadditionalsecurity.
Thisrequirementsetassumesthateitherthesecurityprovidedbyotherdomainshasbeen
compromised,orhasnotbeenenabled.

TABLE6DEFENSEINDEPTHSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

DiD1

Ifappropriate,thecompanyshall
providededicatedterminaldevices
andcomponents(harddrive)for
eachfacilityortask.

Dedicatedcomputersandcomponentsthatare
notusedforpersonaluseorforinappropriate
taskswillminimizetheriskofspreadingvirus
infections.

DiD2

Dedicatedterminaldeviceswith
exchangeableharddrivesshouldbe
usedtoensurethataspecific
computerandoperatorare
performinganassignedtaskthatis
appropriateforaparticularfacility.

Computerswithexchangeableharddrives
providethemeansmitigatetheriskof
performinginappropriatetasksfromonefacility
toanother.

DiD3

Asecureinterruptprocessing
featureshallbeusedtoprevent
interruptsfromnonsecuredevices
suspendingsecurityprocesses.

Attackersoftenattempttoforcenonsecure
interruptstogainaccesstosecureterminal
devicecontentonthebusorinsystemcaches.By
separatingtheinterrupts,processcorescan
preventdirectaccesstosecuredataorthe
disruptionofcriticalsecurityprocessingwithin
theterminaldevice.

DiD4

Twoseparatecacheareasinthe
terminaldeviceprocessor,onefor
securecodeandonefornonsecure
code,shallbeimplementedsothat
nonsecurecodewillneverhave
accesstomemoryareaswhere
securecodeisrunning.

Thiseliminatesthepossibilityofnonsecurecode
havingaccesstosecuredatathatmayotherwise
beleftbehindinadatacachethatwasnot
cleared.

DiD5

Theterminaldeviceprocessorshall
useseparatebussesforsecureand
nonsecuredataorprovidethe
abilitytolockoutthebuswhilethe
processorisinasecuremodeof
operation.

Thisisneededtoimplementsecurityfeatures
suchasmemoryforcryptographicalgorithmsor
keystorage.Likethesecurecache,sharingthe
buswouldgivenonsecurecodeanddevices
accesstosecurecodeanddata.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page26

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

DiD6

Encryptionshallbeimplementedto Encryptionallowsthecodetobehiddenand
protectcodeprivacy.
preventreverseengineering.Possiblymore
importantistheabilitytosingthecodesothat
authenticationisrequiredpriortoexecution.This
willgoalongwaytowardsinsuringthatnoone
hastheabilitytochangethecodeaswellasto
ensurethatitistheoriginalcode.Thisfeature
givesthesecuritydomaintheabilitytoverifythe
systembeforestartup.Itcanalsoperformself
tests,asrequiredbysecuritystandardssuchas
FIPS1402.,priortostartup,including
verificationandinitializationofprogrammable
hardwaredevices.

DiD7

Whenalgorithmsareimplemented
insoftware,thekeysarealso
availableinsoftware;therefore,
cryptographicenginesshallbe
implementedinacombinationof
softwareandhardware.

Ifanadversaryisabletoreverseengineerthe
algorithms,chancesarehellalsohaveaccessto
thekeys.Protectingthekeysisoneofthemost
importantfactorsindesigningasecuresystem.
Totrustaterminaldevice,youmusttrustthat
thekeyshavenotbeencompromised.Hardware
encryptionisbestbecauseitprovidesbetter
performanceandismuchmoredifficulttoattack.
Moreimportantly,hardwareencryptionprovides
theabilitytoprotectkeyinginformation.By
storingencryptionkeyswheretheycanonlybe
accessedbythehardware,softwarerunningon
thegeneralpurposeterminaldeviceprocessor
cannotaccessthekeys.Anattackerwouldhave
toreverseengineertheprocessorcoresatrun
timetogainaccesstothekeyingmaterial.

DiD8

Systemcontrolinformation,user
IDs,errorlogsandpersonal
informationstoredontheterminal
deviceshallbeencrypted.

Modificationofprivilegescangiveauseraccess
tosensitiveinformation.Andaccesstoeventlogs
canenableattackerstofindacontrolsystems
weaknesses.Insomecountries,encryptionofthis
sensitiveinformationisrequiredbylaw.

DiD9

Ifrequiredbycompanysecurity
policy,securitygatewaysshallbe
implementedtoactasaproxy
serverforaccessbyaportable
terminaldevice.

TBD

SP99Part4Draft1Edit0320080310Word972003format.doc

Page27

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
DiD10

Accesstoacontrolnetworkortoanautomation
Ifimplemented,accessfrom
terminalserversoutsidethecontrol deviceismoresecureifaccessisthroughaserver
networktocontrolnetworkdevices locatedintheDMZ.
andautomationdevicesshallbe
throughaserverlocatedinthe
DMZ.

HARDENINGTHECONTROLNETWORKINFRASTRUCTURE

1
2
3
4
5
6
7

Rationale

Thepracticesandrecommendationsspecifiedinthisclausehelpsecuretherouters,switchesand
wirelessaccesspointsinthecontrolnetwork 3 .Inadditiontorouters,switches,andwirelessaccess
points,networksalsorequireadditionalservicestomanagethenetwork,providedomainname
resolution,andperformotherfunctionsasdescribedintheoverlappingandintersectingrequirement
setsinISA99.00.04.Whilesomeofthetechniquesarealsoapplicabletoprotectingthesehosts,the
specificapproachesinthisclausefocusonthesecurityofcontrolnetworkroutingdevices.
CONTROLNETWORKROUTINGDEVICESECURITY

8
9
10

Controlnetworkroutingdevicesecuritycanbedividedintothreeelements:physicalsecurityofthe
router,0peratingsystemsecurityandconfigurationhardening.

11
12
13
14
15
16

ISA99.00.04doesnotproviderecommendationsonphysicalsecurity,otherthantostatethe
ratherobviousfactthatrestrictingthephysicalaccesstoanynetworkequipmentisthefirststepin
securingit.Manyoftheexploitsthataretrivialtopreventfromremotelocations,asdescribedin
ISA99.00.01,butareextremelydifficulttopreventiftheattacker(theworrisomeinsiderthreat)is
abletoaccessthecontrolnetworkroutingdevicemanagementportordevicemanagement
console.

17
18
19

Theinherentsecurityofthecontrolnetworkroutingdeviceoperatingsystemalsoplaysanimportant
roleinthesecurityofthedevice.Iftheoperatingsystemitselfisnotsecurethedevicecanbe
compromisedregardlessofcarefulandsecureconfiguration.

20
21
22
23
24
25

Forexample,oneofthecommontechniquesanattackerusestocompromiseroutersistoelicitbuffer
overflowsbyfindingweaknessesinrouteroperatingsystemcode.Topreventsuchexploitation,the
operatingsystemmustbeextremelystableandrobust.Routermanufacturersmusttakeextremecare
toensurethateachreleaseofsoftwareisasstableandbugfreeaspossible,butafewadditional
techniquesandguidelineswillensurethateventheraresoftwarefaultwillnotexposethesystemto
attack.

Thepracticesandrecommendationsdescribedin(PejahanandKolonn.d.)werecloselyfollowed,and
toalargeextentparaphrasedtoapplytoprocesscontrolnetworks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page28

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4
5

Configurationhardeningistheprocessofapplyingsoundsecuritypoliciesusingthetoolsthataremade
availablebythecontrolnetworkroutingdeviceoperatingsystem.Givenarobustsetofsecuritytools,
virtuallyanydeviceconfigurationcanoperatetoanacceptablelevelofsecurity.Evenwithsuchtools,it
ispossibletomisconfigureaperfectlysecureoperatingsystemandtherebymakethecontrolnetwork
routingdevicevulnerable.

6
7
8
9
10

Fiveaspectsofconfigurationhardeningareaddressed:defaultsettings,accesssecurity,protocol
security,protectingthecontrolnetworkroutingdeviceengineandsecurityauditing.Controlnetwork
routingdevicesoftwareshouldpresentahardenedtargettotheattackerimmediatelyafteritisinstalled
andarootaccountpasswordhasbeenconfigured.Table7includesalistofcommondeviceconcerns
thatthesoftwareshouldaddressinitsdefaultcondition.

11

TABLE7NETWORKROUTINGDEVICEHARDENINGSECURITYREQUIREMENTS

12

Requirement Requirementspecification
ID
NRH1

Asecureoperatingsystemshouldalso
includefeatures,suchascomplex
passwordsorpassphrases

Rationale

Helpoperatorsprotectthesystem
fromattacks,soaknowledgeableuser
canminimizewhatevervulnerability
existsasaresultofnecessary
configurationparameters.

NRH2

Operatingsystemforrouters,switchesand
accesspointsshallcomplywithFIPS1402,
Clause4.6(NISTFIPS14022001).

FIPS1402,Clause4.6(NISTFIPS1402
2001)addressestheoperatingsystem
forcryptographicmodules,thesame
requirementsshouldbeaddressedfor
theoperatingsystemofhardened
networkrouters,switchesandwireless
accesspoints.

NRH3

Thedevicesoftwareshouldnotforward
directedbroadcasts.

Directedbroadcastservicescanbeused
toattackotherusersacrossthecontrol
networkbysendingpingrequestsfroma
spoofedsourceaddresstoabroadcast
addresssuchas200.0.0.255.Ifsuchpings
areallowedonthe200.0.0.0/24network,
asinglepingrequestcanelicitupto254
responses,allaimedatthesupposed
sourceofthepingwhichactually
becomesthevictimofadenialofservice
(DoS)attack.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page29

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

NRH4

Remoteaccesstothedeviceshouldbe
Onlyconsoleaccesstotherouteris
disabledbydefaultandmustbeexplicitly enabledinadefaultconfiguration.This
enabled.
restrictionshouldapplytoall
managementaccessprotocolssuchas
telnet,FTP,andSSH.

NRH5

ThesoftwareshouldnotsupportSNMPv3 WhilethesoftwaremaysupportSNMPv3
setcapabilityforeditingconfiguration
setcapabilityforconductingcontrol
data.
networkmonitoringandtroubleshooting,
thisexposesnoknownsecurityissues
andcanbedisabledintheconfiguration.

NRH6

Thesoftwareshouldbydefaulthavea
ratelimiterappliedonARPpacketsthat
gottotheroutingengine.

ThispreventsanARPstormattack
eitherthroughmisconfigurationor
maliciousbehavior.Tofurtherratelimit
ARPmessages,anARPpolicercouldbe
placedonEthernetinterfaces.

NRH7

Atleasttwofactorauthenticationand
themechanismsdescribedin(ANSIX9.69
1998)shallbeusedtoverifythattheuser
hasauthorizedaccessrightsand
privileges.

Secureaccessisessentialtomanaging
andmaintainingarouterinfrastructure.
Thesoftwareshouldproveinitialaccess
securitybydisablingallaccessbydefault.
Thisensuresthatnoaccessispossible
unlessdeliberatelyturnedonbyan
authorizeduser.

NRH8

Thedeviceshouldsupportoutofband
managementwithadedicated
managementEthernetinterfaceora
dedicatedserial/consolport.

Note:theoutofbandnetworkcanitself
becompromised.

NRH9

Theoutofbandmanagementinterface
shallconnectdirectlytotherouting
engine.

NRH10

Notransittrafficshallbeallowed
throughthisinterfacesoastoprovide
completeseparationofoperationaldata
andmanagementtraffic,ensuringthat
congestionorfailuresintransitnetwork
donotaffectthemanagementofthe
controlnetworkroutingdevice.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page30

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

NRH11

Aseparatemanagementnetworkshallbe
providedtofacilitatemanagementofthe
controlnetworkroutingdeviceeven
duringDoSattacksorotheroutages.

NRH12

SSH(orHTTTP(S)ratherthantelnetis
recommended 4 .

Inbandmanagementallowsconnection
tothedeviceusingthesameinterfaces
throughwhichtheprocesscontroltraffic
flows.Whilethisresponseissimpleand
requiresnodedicatedmanagement
resources,ithassomedisadvantages.
Managementandtransittrafficflowsare
mixedtogether.Anyattacktrafficthatis
mixedwiththenormaltrafficcanaffect
theabilitytocommunicatewiththe
controlnetworkdevice.
Thelinksbetweencontrolnetwork
devicesmaynotbetotallytrustworthy,
leadingtothepossibilityofwiretapping
andreplay.Themostcommonmethods
tocommunicatewiththecontrol
networkroutingdevicefromaremote
consolearetelnetandSSH(secureshell).

Astrongerstatementistorequireanencrypted,authenticatedprotocolsuchasSSHv2orSSLv3/TLS(or
anythinginsideaVPNtunnel)andprohibitunencryptedprotocolssuchastelnet,FTP)

SP99Part4Draft1Edit0320080310Word972003format.doc

Page31

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
NRH13

Rationale

SSHaccesstothedeviceshallbedisabled Thesecureshellprovidessecure
bydefault.
encryptedcommunicationsoveran
insecurenetworkandisthereforeuseful
forinbandcontrolnetworkrouting
devicemanagement.Whenenabled,SSH
accessisallowedandtheoperatorcan
setoperationparametersusedtocontrol
thenumberofconcurrentSSHsessions
andthemaximumnumberofSSHsession
thatcanbeestablishedinoneminute.
Theratelimitparametercanbeusefulin
protectingagainstSYNfloodDoSattacks
onanenabledSSHport.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page32

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
NRH14

SCPisrecommendedasanalternativeto
FTPforcopingfilesbetweencontrol
networkroutingdevices,especiallywhen
thetransitpathcrossesuntrusted
networks.

Rationale

Thesecurecopyprotocol(SCP)usesthe
SSHencryptionandauthentication
infrastructuretosecurelycopyfiles
betweenhosts.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page33

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
NRH15

Rolebasedaccesscontrolwithstrong
identificationmanagementshouldbe
providedbyanIdentityManagement
System(IMS).

Rationale

Themanagementofmultiplerouting
devicesbymanydifferentpersonnelcan
createasignificantuseraccount
managementproblem.Becausethe
organizationstructureandoperational
philosophyissodiverseinlargeprocess
controlenterprises,itseemsreasonable
toestablishazoneorconduitof
responsibilityforestablishingall
authorizationsandprivilegesneededto
managetheroutingdevices.The
organizationresponsibleforaspecific
zoneorconduitisempoweredtoexecute
andmanagethekeyingmaterialwithin
theirdomainofresponsibilityasspecified
inANSIX9.69 5 (ANSIX9.691998)thisis
viewedasdistributedmanagement
executionwithinthecentralizedcontrol
oftheEnterpriseAuthority.Asstated
before,centralizedcontrolensuresthat
properextensionoftheenterprise
securitypoliciesandprocedureare
enforcedthroughalldomainsand
responsibleorganizations,including
supportvendorsandbusiness
partnerships.
Withineachdomainofresponsibility,and
incompliancewithANSIX9.69,
organizationalunitsareresponsiblefor
assigningrightsandprivilegestoall
entities(peopleanddevices)forwhich
theyareresponsible.Thisrequireseach
domainandorganizationalunitto
replicatethenecessaryIMSfunctions
neededtocarryouttheirassigned
responsibilities.

ANSIX9.69anditscompanionstandardsarecurrentlybeingcodifiedinISO22895.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page34

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

NRH16

TheIMSshallprovidethecapabilityto
issue,change,orrevokecertificatesof
identity,authorization,anduseprivileges
inatimelyresponsetoorganizational
changesaswellastochangeszone
perimeterconfigurationandconduit
segmentationincludingallhardwareand
softwarecomponentsofthezoneor
conduit.

Aswithanyorganizationitwill
experiencenormalturnoverofpersonnel,
terminationofpersonnel,andchanging
rolesandresponsibilityofpersonnelas
theymoveoraddassignmentsthatcross
organizationalboundaries,andmany
timesacrossdomains.Forexample,itis
verycommonthatpersonnelexperienced
inprocesscontroloperationswillleave
thecompanyandgotoworkfora
supplierofequipmentusedbythat
company.

NRH17

Identitymanagement,authorization,and
useprivilegesshallbeassignablefora
selectedtimeperiodandmanagedbythe
organizationalunitauthority(s)thathave
directsupervisionoverthetasks
performedbytheindividual.

Thiswillprobablyrequireagreementsof
cooperationbetweendomainauthorities
andbetweenorganizationalunit
authoritiesasdescribedinANSIX9.69.

NRH18

Individualcertificatesshallbestoredon
anAuthenticationKeythatisassignedin
accordancewithcompanypoliciesand
procedurestoanyindividualor
automationentity.

NRH19

Inaccordancewithcompanypolicyand
procedures,IMSshallsupportsecure
distributionofkeyingmaterialor
revocationofkeyingmaterialover
modems(dialuporwireless),corporate
intranets,WideAreaNetwork(WAN),
andtheInternet.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page35

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

NRH20

Routingdevicesshallensurethatthey
formroutingprotocolrelationships
(peeringorneighboringrelationships)to
trustedpeers.

Themaintaskofacontrolnetwork
routingdevicesistouseitsroutingand
forwardingtablestoforwardusertraffic
toitsintendeddestination.Adversaries
cansendforgedroutingprotocolpackets
toaroutingdevicewiththeintentof
changingorcorruptingthecontentsofits
routingtableorotherdatabases,which
inturncandegradethefunctionalityof
theroutingdeviceonthecontrol
network.Onewayofdoingthisisby
authenticatingroutingprotocol
messages.

NRH21

TheIMSmechanism(NRH15)shallbe
usedtoauthenticateroutingprotocol
messages.

NRH22

Theroutingdevicemanagement
softwareshould,asaminimum,support
HMACMD5authenticationforthe
BorderGatewayProtocol(BGP),the
OpenShortestPathFirst(OSPF),the
IntermediateSystemtoIntermediate
System(ISIS)protocol,theRouting
InformationProtocol(RIP),andthe
ResourcereSerVationProtocol(RSVP).

HMACMD5usesasecretkeythatis
combinedwiththedatabeing
transmittedtocomputeahash.The
computedhashistransmittedalongwith
thedata.Thereceiverusesthematching
keytorecomputedandvalidatethe
messagehash.Ifanadversaryhasforged
ormodifiedthemessage,thehashwill
notmatchandthedatawillbediscarded.

NRH23

OSPForISISmaybeusedtoallowfast
internalconvergence,scalabilityanduse
oftrafficengineeringcapabilitieswith
MultiProtocolLabelSwitching(MPLS).

AlthoughIGPssupportauthentication,
someIGPsareinherentlymoresecure
thanothers.BecauseISISdoesnot
operateatthenetworklayer,itismore
difficulttospoofthanOSPF,whichis
encapsulatedinIPandthereforesubject
toremotespoofingandDoSattacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page36

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

NRH24

Astatefulfiltershouldbeappliedonlyto
theroutingdevicesloopbackinterface.

Authenticationisrequiredtomakesure
thatroutingdevicesformrouting
relationshipsonlywithtrustedpeers.
Althoughthishelpsprotectrouting
protocols,itstilldoesnotcompletely
preventmaliciousoruntrustedpackets
fromreachingaparticularprocessonthe
RoutingEngine(RE).Forexample,an
adversarycouldstilllaunchanattack
againstaroutingdevicebytargetinga
particularprotocolwithforgedpackets.
Althoughthesepacketswillfailthe
authenticationcheck,theattackmaystill
consumeroutingdeviceresources(CPU
cyclesandcommunicationqueues)on
theRE.Statefulfiltersshouldbe
embeddedintheroutingdeviceswithout
compromisingforwardingspeed.

NRH25

Thesinglefilter(NRH24)shouldcheckall
trafficdestinedfortheREthatentersthe
routingdevicefromthecustomer
interfaces.

Addingormodifyingfiltersforevery
interfaceontheroutingdeviceisnot
necessary,whichisasignificant
departurefromequivalentprocedureson
legacyrouters.

NRH26

Astatefulfiltershallbeconstructedsoas Whenconstructingastatefulfilterto
toadmitonlyfriendlytraffictothe
admitonlyfriendlytraffictotheRE,
routingengine.
consider:servicesandprotocolsthat
needtoberunningontherouting
device,routingprotocols(BGP,OSPF,
RSVP,etc.),managementservices(SSH,
DNS,NTP,etc.),diagnosticand
troubleshootingprotocols(ICMP,trace
route,etc.),thedestinationaddresses
andportsoftheaboveservicesand
protocolsontheRE,thetrustedsource
addressofthepeerswithwhom
communicationisintended,andthe
trafficratethatcanbeallocatedto
eachoftheservices.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page37

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

Oncethenecessaryservicesand
protocolsaredetermined,eachofthem
shouldbecombinedwiththesource
addressfromwhicheachserviceis
expectedtooriginatetocreateamatch
conditioninthestatefulfilter.

Thecorrespondingactionistoaccept
packets,andtodiscardandothertraffic.

NRH28

LimitingICMPtrafficdestinedforthe
routerisrecommended.

ProtectsagainstISMPfloodsand
similarattacksagainsttheRouting
Engine.

NRH29

AllowingonlythosetypesofICMP
messagethatrequiredforproper
networkoperationandtroubleshooting
isrecommended.

Anattackercanuseseveraldifferent
typesofICMPmessagestoeither
degraderouterfunctionalityortoscan
machines.

NRH30

RatelimitingTCPSYNmessagesis
recommended.

AnothercommonformofattackisaTCP
SYNflood,inwhichtheattackerusesa
scriptorprogramtocreateTCP
connectionrequests(SYNmessages)ata
ratefasterthanthevictimreleasesthem.
BecauseestablishingaTCPconnection
requiresonlyathreewayhandshake,
limitingtherateofincomingSNYpackets
to500Kbps(TBR)cansafelybedone.

NRH31

Theroutingdevicemanagement
softwareshallimplementthealgorithms
definedinRFC1858.

Inanattack,IPfragmentationcanbe
usedtodisguiseTCPpacketsfromIP
filtersusedinroutingdevicesandhosts.
RFC1858(IEEE1995)talksaboutusing
smalloffsetsinpotentialDoSattacks,it
alsorecommendsalgorithmstoprotect
againstsuchattacks.

NRH27

SP99Part4Draft1Edit0320080310Word972003format.doc

Page38

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
NRH32

Rationale

Astatefulfiltershallbeconfiguredsothe Thestatefulfilterconfigurationthat
manyusersimplementwilldrop.
firstpacketfragmentcontains
destinationport(andothermatch

criteria),andthesepacketswillbe
acceptedandallowedtopass.
Subsequentfragmentsofthesame
packetshallnothavethedestination
portinformation,willnotmatchthe
statefulfiltersetting,andwillbe
discarded(becauseofthedefault
setting).

Fragmentsthataresmallarenot
valid,theyshallbediscarded.

Allfragmentsfromtrusted
sourcesshallbeaccepted.

NRH33

PacketswithIPoptionsshallbedropped.

IPoptionsprovidecontrolfunctions
neededinsomespecialsituations,butfor
mostpracticalcommunicationtheyare
notnecessary.Partofthefunctionality
thatoptionsprovideincludestimestamps
andspecialrouting.Optionstellthe
transitrouterstoexaminethepackets
thatarenotdestinedtothemmore
closely;hencetheseoptionedpackets
willgouptotheRoutingEnginefor
processing.Afloodingofsuchpackets
couldthereforeoverwhelmtherouting
engineandcreateasuccessfuldenialof
servicecondition.

NRH34

TheburstsizelimitforRSVPpackets
shouldaccountfortheRSVPpacketsize
andthenumberofmessagesreceivedby
aroutingdeviceduringonesecond.

Becauseofthebusinessofthecontrol
traffic,animportvalueintheratelimiter
istheburstsizelimit.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page39

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
NRH35

Rationale

Topreventroutingdevicestobeusedas Onecancombatreflectionattacksby
reflectorsthecapabilityshallbeprovided configuringadefaultroutewhich
tosilentlydiscardpacketswherethereis pointstothediscardinterface.
nodestinationfor.
Thiswayapacket,withnovalidroutein

theforwardingtablewillbesilently
discarded,andbyinstallingafilterwhich
logsthesediscards,thecontrolnetwork
administratorcananalyzethisattack
traffic.
Routingdevicesbydefaultwillrespond
withICMPdestinationunreachable
errormessagestothesourcesofpackets
forwhichtheyhavenoroute.This
behaviorcanbeexploitedbyadversaries
whocanturnroutingdevicesinto
reflectorsbyspoofingrequestsfromthe
victimtoalargesetofroutersthatwillin
turnsendtheircombinedrepliestothe
victim.Anadversarycansendpacketsto
nonexistingdestinationswiththesource
addresssettothevictimsaddressand
therebyfloodavictimwithICMPerror
messages.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page40

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
NRH36

Ratelimitingroutingprotocolisnot
recommended

Rationale

ToprotecttheRoutingEngine,itis
importanttoconstrainthetrafficload
fromeachoftheallowedservicestoa
ratedeterminedduringtheanalysisof
theFilterConfiguration.Ratelimiting
controltraffichelpsprotecttheREfrom
attackpacketsthatareforgedsuchthat
theyappeartobelegitimatetraffic,and
arethensentatsuchahighrateasto
causeaDoSattack.
Routingandcontroltrafficareessential
totheproperfunctioningoftherouting
device,andrapidconvergenceofrouting
protocolsiscrucialforstabilizingthe
controlnetworkduringtimesofcontrol
networkinstability.Whileitmightseem
desirabletolimittheamountofrouting
protocoltraffictoprotectagainstvarious
typesofattacks,itverydifficultto
determineafixedmaximumratefor
protocoltraffic,becauseitdependsupon
thenumberofpeersandadjacencies,
whichvariesovertime.

NRH37

Providethecapabilitytoallocateafixed
amountofbandwidthtoeachtypeof
managementtraffic

Becausemanagementtrafficisless
essentialandmoredeterministicthan
routingprotocoltraffic,itcanbepoliced
toafixedrate,topreventitfrom
consumingresourcesnecessaryforless
flexibletraffic.Thispreventsan
adversaryfromconsumingallthe
routingdevicesCPUifanattackis
launchedusinganysingleservice.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page41

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

NRH38

Providethecapabilitytologall
significantprotocolandroutingdevice
eventstoaremotesystemlog(syslog)
server.Syslogfilesshouldtheneitherbe
parsedinrealtimetoidentifysuspicious
behaviororarchivedforlaterreview.

Controlnetworkoperatorsare
responsibleformonitoringthesignificant
eventsthatoccurontheirnetworks,and
systemeventlogsareusuallytheprimary
sourcesofthisinformation.Althoughthe
loggingofeventsandactionsdoesnot
itselfincreaseroutingdevicesecurity,
logscanbeusedtomonitorthe
effectivenessofcurrentsecuritypolicies
androutingdevicesconfiguration.They
canalsobeusefulwhenreactingtoa
continuedanddeliberateattack,by
identifyingthesourceaddress,routing
device,orportoftheattackerstraffic.
Finally,logscanalsoprovideimportant
forensicevidenceforprosecutingan
adversary.

NRH39

Providethecapabilitytologall
authenticationandcommandeventstoa
syslogserver.

Afilewhichrecordswhenauthentication
andauthorizationisgrantedand
rejected,aswellasallusercommands,
providesanexcellentwaytotrackall
managementactivityontherouting
device.Checkingthesefilesforfailed
authenticationeventscanhelpidentify
attemptstohackintothecontrol
networkroutingdevice.Thesefilescan
alsoprovidelogsofallcommands
executedontheroutingdeviceandwho
hasperformedthem.Asecurity
administratorcanreviewlogsofthe
commandsexecutedontherouting
deviceandcorrelateanyeventinthe
networkwithchangesmadeata
particulartime.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page42

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

NRH40

Providethecapabilitytologallrouting
protocoleventsanderrorstoasyslog
server.

Routingprotocoleventsanderrorsare
goodindicatorsofattacksagainstrouting
protocols.Forexample,theseevents
includeprotocolauthenticationfailures,
whichmightpointtoanattackerthatis
sendingspoofedorotherwisemalformed
routingpacketstotheroutingdevicein
anattempttoelicitaparticularbehavior.

NRH41

Providethecapabilitytologalltraffic
beingdeniedtoasyslogserver.

Loggingalltrafficthatdoesnotpassthe
routingdevicestatefulfilterscanprovide
anexcellentwayofidentifyingattackers.
Scriptscanparsethesyslogfilesinreal
timeandsendanalarmtodesignated
engineersforfurtherinvestigation,or
theycanpreservetheselogsforanalysis
atalatertime.Notonlycansuchalog
indicateifandwhenthereisanattackon
theroutingdevice,buttheycanalsohelp
determinethesourceandtypeofpackets
usedintheattack.

FIELDCOMMUNICATIONSANDFIELDDEVICESECURITY

3
4
5
6
7
8

Securityrequirementsfortheportionofindustrialmeasurementandcontrolthatisknownasthe
"field",whichisthatportionoutsideofcontrolroomsandadjacentwiremarshallingareasarespecified
inthisclause.Itisintendedforgeneralusewithinindustrialmanufacturingfacilities.Such
communicationssystemsareusedtoprovideplannedcommunicationsamongautomatedequipment
withinthefacilityandtemporarycommunicationsbetweenahumanandanearbyautomation
equipment.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page43

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
ControlNetwork
Interconnection

ECI2,ECI3,ECI4,
ECI5,ECI18,
ECI31,ECI35,
ECI36,ECI37,
ECI38,ECI46,
ECI47

ECI2,ECI23,
ECI24,ECI25,
ECI26,ECI27,
ECI28,ECI29,
ECI30,ECI31,
ECI32,ECI33,
ECI34,ECI38,
ECI39,ECI40,
ECI41,ECI42,
ECI43,ECI44,
ECI45,ECI46

ECI19,ECI20,
ECI25,ECI35,
ECI38,ECI39,
ECI40

InterControl
Center

ICC7,ICC8,
ICC9,ICC10,
ICC11,ICC12,
ICC13,ICC14,
ICC15,ICC16,
ICC17,ICC18,
ICC19

ICC1,ICC2,
ICC3,ICC4,
ICC5,ICC6,
ICC7,ICC8,
ICC11

ICC1,ICC2,
ICC3

SP99Part4Draft1Edit0320080310Word972003format.doc

Page44

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3

AnnexE:FieldCommunicationandDevicesprovidesaninformativeunderstandingofthespecial
considerationsthatneedtobeaddressedwhenselectingappropriaterequirementsrecommendedin
thisclause.

Themajorissuesthatsecuredindustrialdevicetodevicecommunicationsmustaddressare:

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Robustcommunicationsservicessuitableforindustrialmeasurementandcontrol
Minimizedlifecycleburdenofsecureddevicesandnetworksduringinstallationandlongterm
operation
Strongsecurity,suitableforprotectionofassetsuptothelevelofnationalcriticalinfrastructure,
integratedwithotherplantsecuritysystemsandfullysupportingallcontrolparadigmsand
modesofusage
Owner/operatorselectionoftheextentofcommunicationsanddevicesecurityasafunctionof
regulationandperceivedriskvs.theincrementalcommissioningandoperationalburdenofthat
security,withtheabilitytorevisitthatselectionaftersystemdeploymentasthethreatand
regulatoryenvironmentchange

Eachoftheseareasinvolvestradeoffs,soISA99.00.04providesoptionstopermitanappropriatefit
betweencostandcomplexityversustheneedsofaspecificautomationsystem.Forexample,some
systemsmaybenaturallyisolatedandsonotrequireextensivesecurity,ordelayactivatingsecurity
measuresuntilthereisdetectedevidenceofattack(e.g.,asmallplantwithnonhazardousprocesses
andanoncriticalproduct).

SP99Part4Draft1Edit0320080310Word972003format.doc

Page45

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE 8FIELDCOMMUNICATION ANDFIELDDE VICESECUR ITYREQUIREMENTS


Requirement Requirementspecification
ID
FC&FD1.

Fieldcommunicationsshallprovidethe
capabilitytoroutetrafficbetween
differingsubnetworktechnologiesand
protocols.

Rationale

Wirelesscommunicationstechnologyis
evolvingrapidly,asaremeshandother
adaptivelocalroutingprotocols.Both
areasarecurrentlyintheirinfancyand
bestpracticesareexpectedtochange
massivelywithinthenextfiveyears.Any
standardforsecuredfieldcommunications
needstoaccommodatemajorevolutionin
lowlevelcommunicationstechnologies,
specificallyinthesetwoareas.
Becauselargeindustrialsystemsare
upgradedpiecemealthroughouttheirlife,
theyarelikelytoinvolveamixofnetwork
technologies,dependingprimarilyon
whentheclustersofequipmentare
installed.Theseallwillneedto
communicatewithcentralizedmonitoring
andcontrolsystemsandinsomecases
witheachother.Forexample,lowspeed
subnetworksmayneedtoconnectto
centralizedsystemsbytunnelingthrough
higherspeedsubnetworks.

FC&FD2.

Securitymechanismsshallbemodularso
astofacilitatemodificationsafterinitial
systemdeployment.

Thedecisiontoemploycommunications
security,andtheextentofsuch
employment,shouldbedecisionsmadeby
thesystemassetowner,notthe
equipmentsupplier.Suchdecisionsare
subjecttoreconsideration,eitherdueto
increasedperceivedriskortoregulatory
action.Thus,noassetownercansafely
determineattimeofequipmentpurchase
orinstallationthatahighlysecuredsystem
willbeunnecessaryinthefuture.

FC&FD3.

Physicalinstallationofasecuredsensoror Thegoalistominimizecost.
actuatorgenerallyshouldbenomore
difficultthaninstallationofanequivalent
unsecureddevice.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page46

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

FC&FD4.

Providethecapabilityforsecuredfield
devicestospecifyameansforadeviceto
beassignedatagnamethatuniquely
identifiesitsfunctionalroleintheplant
automationsystembeforethedevice
becomesoperational,eitherpriortoor
duringinstallationofthedeviceinthe
physicalplant.

Iftheassetownerhaschosentoprepare
forsecureoperationofthewireless
system,thentheinstallermayalsoatthis
timeprovidethedevicewithunique
devicespecificcryptographiccertificates
orsymmetrickeyingmaterialorboth.If
suchisprovided,itmustbedoneina
mannerthatissecurefromattack.

FC&FD5.

Securedfieldnetworksshallsupport
devicesthatfunctionwithouta
continuousexternalpowersource,
permittingthosedevicestooperateinan
energysparingmodethatalternates
betweenfullpoweractivityandreduced
powerquiescence.

Somedeviceshaveareliableexternal
energysourcethatprovidessufficient
powerfortheircommunications
subsystem(s)tooperatecontinuously.
Thosedevicesmayhavethepotentialto
serveasrouterswithinthesubnetworkto
whichtheyareconnected,evenwhen
theirprimarypurposeisthatofan
actuatoror,lesscommonly,asensor.
Somedevicesarepoweredfromnon
rechargeablebatteriesorfuelcellswhose
replacementisasignificantoperational
burden.Theymusthoardtheirenergy,so
theyalwaysfunctionasendpointnodeson
asinglesubnetwork,typicallywithavery
lowdutycycle.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page47

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
FC&FD6.

Any"direct"accesstooperationalfield
devicesthatismadebyfieldpersonnel
shouldbeprovidedinsuchawaythat
therearepermissionchecksappliedto
thataccess;thereispersonal
accountability(e.g.,recordkeepingwith
humanidentity)foranyactionviathat
access;andtheresultingdevicestate
remainsconsistentwithanycopiesofthat
statethatarecachedbythecontrol
system.

Rationale

Withoutsuchcachecoherence,control
systemswouldcontinuallyneedtorequest
adevice'scurrentstatebeforeinitiating
anyactionorinterpretinganyalarmor
alert.Forexample,interpretationofa
highlimitalarmisdependentonthe
currentlimitvalueinthedevice,which
withoutcachecoherencycoulddifferfrom
thecentralcontrolsystem'slocallycached
lastknownvalue.Suchcontinualrequests
forseldomchanginginformationwould
constrictfieldnetworksanddepletefield
devicestoredenergysupplies.
Note:Onewaytoachievethesegoalsis
forthegatewaytoproxyany"direct"
accessmadebyfieldpersonnel.
Wirelessaccesspointsinthefieldthat
gatewaytohighdataratefieldnetworks
mayprovideameansforanadversary
withintheplanttousethoseroutersas
repeaters,tocommunicatethrough
appropriatehumaninterfacesoftwareto
fielddevices.

FC&FD7.

Whencommunicatingwithdevicesthat
arepartoftheoperatingplant,allsuch
communicationsshouldberoutedthrough
agatewaythatinterfacestoacentralized
plantmonitoringorcontrolsystem.That
gatewayshouldregulateandtracksuch
communicationsothatitdoesnot
interferewiththetimelinessofhigher
prioritycontroltraffic,andsothatthe
centralizedmonitoringorcontrolsystemis
apprisedofanychangestoplantdevice
configurationoroperationthataremade.

FC&FD8.

Securedfieldnetworksshouldsupportuse Thegoalistoensureacosteffectiveand
gracefulmigrationanddeploymentof
ofunsecureddevices,butshouldplace
strictlimitsontheresourcesthattheycan securitysolutions.
demand,tolimittheabilitytousesuch
unprotecteddevicesasvectorsfordenial
ofserviceattacksonsecuredfielddevices
andnetworks.

FC&FD9.

Securablefieldnetworksshouldsupport
thedetectionanddiscardofalmostall
noiseinducederrorsinreceived
messages.

Inunsecurednetworks,suchdetectioncan
beprovidedateachforwardingstepbya
messagechecksumorframecheck
sequenceappendedtothemessage.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page48

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
FC&FD10.

Securednetworksshallprovidethe
capabilitytodetectanddiscard
intentionallyinducedchangesin,or
forgeriesof,messagesthatoriginatefrom
attackerswhodonothaveaccessto
currentnetworkkeys.

FC&FD11.

Providethecapabilitytomatchthelength
oftheauthenticatortagtotheattack
rejectionraterequiredforthespecific
classofsession.

FC&FD12.

Insecurednetworks,providethe
capabilitytoincreasethelengthofAPDU
authenticatortags,ortoreinitializethe
authenticatedsessionswithoutdisrupting
processcommunications,whenchangesin
thenationalthreatlevelorplantthreat
levelwarrantincreasedauthentication.

FC&FD13.

Insecurednetworks,ifthenetwork
supportsmulticastsessions,providethe
capabilityformembersofamulticast
sessiontoauthenticatethataspecific
multicastmessagecamefromtheclaimed
sourceandnotfromanothersession
participantthatmayhavebeensuborned.

Rationale

Thiscanprotectsuchsecurednetworks
fromallbutthebestfundedattackers.
Note:Insecurednetworks,composite
detectionofbothnoiseinducederrors
andchangesorforgeriesbynon
participantattackerscanbeprovidedby
eachrouterthroughakeyedmessage
authenticatortagattachedtoeachlow
levelmessagewithinthesubnetwork,
keyedbyanetworkkeythatisshared
amongallsubnetworknodes(e.g.,asub
networkbroadcastkey).Suchearly
detectionanddiscardinroutersprevents
theattackerfromusingtheroutersto
magnifytheattack.
Insecurednetworks,compositedetection
ofotherwiseundetectednoiseinduced
errors,andofchangesorforgeriesbynon
participantattackers,canbeprovidedat
receivingsessionendpointsbyakeyed
messageauthenticatortagattachedtothe
deliveredAPDU,keyedbyasessionkey
thatissharedamongallsessionendpoints.

Broadcastisthespecial"allnodes"caseof
multicast,sorequirementsformulticast
applytobroadcast.However,inpractice
theuseofbroadcastistypicallylimitedto
thecontrolsystemasthebroadcast
source,andtimesynchronizationasthe
dominantuseofbroadcast,sospecialized
meansofsourceauthenticationmaybe
appropriate.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page49

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

FC&FD14.

Thegoalistoprovidesecuritywithout
Securedfielddevicesshouldprovidethe
degradingthequalityofservice.
capabilitytodetectanddiscardreceived
messageswhosereceptiontiming,relative
totheexpectedmomentoftheir
transmission,orwhosesequenceviolates
thequalityofservicecharacteristicsofthe
communicationssession.

FC&FD15.

Ifduplicatemessagesarereceived,and
suchareexpectedasaconsequenceof
redundantoralternatepathsthroughthe
communicationsnetwork,thecapability
shouldbeprovidedtodeletethese
messages.

FC&FD16.

Ifimproperlyorderedmessagesare
received,andsuchareexpectedasa
consequenceofredundantoralternate
pathsthroughthecommunications
network,thecapabilityshouldbe
providedtodeletethemessages,reorder
themessagesordeliveredasdetermined
bythequalityofservicecharacteristicsof
thereceivingsession.

FC&FD17.

Ifexcessivelydelayedmessagesare
received,thecapabilityshouldbe
providedtologanddeletethemessages.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page50

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
FC&FD18.

Thesecurityprotocolshallprovidethe
capabilitytoauthenticatetheequivalence
betweensenderandreceiverofany
informationwhosemismatchcouldbe
usedtospooformisleadareceiving
device.

Rationale

Becausesessiontype,highorderbytesof
messagesequencenumbersthatcannot
repeatwithinthelifetimeofasessionkey,
andotherrelativelystaticpersession
informationareunlikelytobesentintheir
entiretyineachsecuredmessage,the
sessionendpointsneedtodetectlossof
synchronyofthisinformationaspartof
theirmeansofdetectingspoofing.
Note:Itispossibletousetheextended
authenticationtechnologytoprovide
detectionofinconsistencieswithin
communicationsstackstateinformation
(e.g.,networkID,keyingmaterialepoch,
etc)thatneedtobeidenticalbetween
sendingandreceivingendpoints.

FC&FD19.

Securedfielddevicesshallprovidethe
capabilitytosupportAPDUconfidentiality
andsemanticsecuritysoastoconcealthe
contentsofthemessageAPDUsandany
relationshipsbetweenmessageAPDUs
otherthanAPDUlengthandaddressing
fromeavesdropping.

Asageneralrule,thedegreeofneeded
longtermconfidentialityisdeterminedby
theeconomicvalueoftheinformationso
protected.Thisisinmarkedcontrastto
shorttermconfidentialityandanti
spoofingmeasures,whichneedtobe
strongenoughtoprotectnationalcritical
infrastructurefromattackbyothernation
states.

FC&FD20.

Secured field networks shall provide


the capability to determine proof of
identity before use from automation
devices or from adversaries access in
the network.

Unconstrainedaccesswouldfacilitate
denialofserviceattacksbyanydevice
whichcaninjectmessagesintothe
securednetwork,bypermittingan
attackertouserouterforwardingof
spoofedmessagesasanattackmultiplier.

FC&FD21.

Plantautomationandinternetworking
devicesonhighdataratenetworksshall
providethecomputepowerandmemory
toimplementcomplexcryptographic
algorithmsandmanagementfunctions
certifiedbyrecognizedauthorities.

Thispermitstheuseofcryptographic
techniquesthatlocalizeallprivate
cryptographicsecretstotheemploying
device.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page51

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
FC&FD22.

Rationale

Certificatesissuedbyanotherauthority
Securedfielddevicesshalluse
cryptographiccertificatesissuedbyaplant doesnotimplyauthorizationtofunction
withintheplant.
certificateauthoritytoattesttodevice
identity.

AUTOMATIONCELLSECURITY

3
4
5
6

Thisrequirementsetdescribesrequirementsonthesecurearchitecture,implementation,andoperation
ofaninterconnectionbetweenautomationcellswhichareusuallypartofaprocesscontrolnetwork.If
missioncritical,automationcellsshouldbedesignedtoahighsecurityassurancelevel(SAL),and
possiblyahighsafetyintegritylevel(SIL).

7
8
9
10
11

Thenetworkinsidetheautomationcell(AC)mustbeconsideredastrusted,becauseaninjuryofone
partoftheautomationcellismissioncriticalforthewholeautomationcell.TheNetworkoutsidetheAC
isinmostcasesaprocesscontrolnetwork(PCN).Forthefollowingrequirementsetitisconsideredas
untrustedwithexceptionswithregardtonetworktraffictypesandvolumesaswellasuserintentions
andcapabilities.

12

Automationcellsecurityrequirementsspecifiedinthisclauseaddressthefollowingthreats:

13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Availability:AdversaryoutsidetheACcausesacommunicationoverloadinordertodisturb
productionoperations.
Integrity:AdversaryoutsidetheACtriestomanipulatethedataflowfromorintotheAC.
Confidentiality:AdversaryoutsidetheACtriestospyonthedataflowfromorintotheAC.
Accesscontrol:ManipulationofdeviceoperationinsidetheAC,orunintentionalaccessonthose
devices.

AutomationcellsecurityrequirementsspecifiedinthisclausedonotaddressInjuriescausedby
compromisedsystemsoutsidetheAC(e.g.byvirusesorworms),whichresultfromauthorized
communicationwithcomponentsoftheAC,ortheinsiderthreatwithbyanadversarywhohasthe
appropriatecredentialsforaccessanduseofthesystemsoutsidetheAC.

NETWORKTOPOLOGYSECURITYREQUIREMENTS
Figure1showsatypicalautomationcellnetworkconfigurationusedtodeveloptheautomationcell
securityrecommendationsandguidelinessetforthinthisclause.Boxesdenotehostsandtheir
functions,butkeepinmindthatfunctionsmaybecombinedonthesamehost.Networksegmentsare
shownasabusarrangement,buttheycanalsobeimplementedasahuborswitch.Encrypted
communicationsisshownasVirtualPrivateNetworks(VPN)withinthenetworkconduit.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page52

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

FIGURE1TYPICALAUTOMATIONCELLNET WORKCO NFIGURATION


Encrypted
communication
between a
device and an
automation cell

dev0.1

dev0.2

Encrypted
communication
between two
automation
cells

SGW 1

SGW 2

...
dev1.1

dev1.n

dev2.1

automation cell 1

2
3

dev1.2

...
dev2.2

dev2.n

automation cell 2

TAB LE9AUTOMATIONCE LLINTERCONNECTIO NSECURITYREQUIREMENTS


Requirement Requirementspecification
ID

Rationale

ACI1

TheSGWdeviceshallcontainstateful
inspectionfilteringandencryption
features.

Dependingonthedifferentsecurity,
networkingandproductionrequirements
itmaybeoptimaltousethisdeviceasa
firewall,aVPNapplianceoracombination
ofboth.

ACI2

TheSGWdeviceshallrunonlythe
securityanditssupportingapplications.

Theriskthatanadversaryisableto
compromiseahostincreaseswiththe
numberofapplicationsandserviceson
thathost.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page53

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ACI3

SGWdevicesofthisrequirementset
shallbeadministratedviasecurelo gical
channels.Ifthesecuritymanagement
channelhastobeconnectedtoexternal
networkstheinterconnectionbetween
thesecuritymanagementchanneland
theexternalnetworkshallconformto
therequirementsetofthisstandard.In
thiscase,thecorrespondingsecurity
devicesmaybeadministratedviathe
samesecuritymanagementchannel.

Administrationofthesecurityand
networkingdevicessuchasfirewalls,
switches,routers,andintrusiondetection
system(IDS)sensorsmustbefeasible
evenwhenanattack,ortheresponseto
anattack,haveinterrupted
communicationforproductiontraffic.
Also,thisrequirementensuresthatan
adversarycannotusethecommunication
pathforproductiontraffictodirectly
attacktheconfigurationinterfacesofthe
securitymechanisms.Note,connectionof
thesecuritymanagementnetworkto
externalnetworksmaybenecessaryfor
ruleupdatesorrealtimecommunication
withexternalsecurityserviceproviders.
Ontheotherhand,itisnotusefulto
establishwidespannedseparate
networksformaintainingtheSGWofa
controlnetwork.

ACI4

SGWshallfailclosed.

Incaseafirewallcannotcontinueto
provideitsaccesscontrolandsupporting
functions,e.g.duetoasoftwarefailure,
logexhaustion,resourceexhaustion,or
trafficoverloaditshalltrytoindicatethe
problemtoasupervisoryinstanceandgo
intoastatethatblocksallincomingand
outgoingproductiontraffic.This
requirementpreventsthatanadversary
candisabletheprotectionprovidedbythe
firewallviaarelativelysimpletypeof
attackthatdoesnotsubvertthefirewall
itself,e.g.highvolumetrafficortraffic
thatcreatesmanylogentries.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page54

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

ACI5

Devicesinsidetheautomationcellshallbe
implementedonphysicallyseparate
networkingequipment.

Thisrequirementaddressestheuseof
virtualLANs(VLANs)etc,whichrun
logicallyseparatecommunication
networksonthesamemedium.With
todaystechnologyitisrelativelyeasy,e.g.
viaflooding,tocompromisethenetwork
separationprovidedbyVLANswitches,
whichwouldpotentiallyremovesecurity
mechanismsfromtheattackpath.

ACI6

Allincomingoroutgoingtrafficnot
explicitlypermittedshallbedeniedatthe
SGW.

Inacontrolsysteminterconnectthereis
likelyonlyarathersmallsetofpermitted
traffictypes,sothatdefiningpassrules
(i.e.exceptionstoadenyall)arefaster
andlesserrorpronetoconfigureand
maintainthandenyrules(i.e.exceptions
toapassall).

ACI7

Thereshallbeadocumentedbusiness
justificationwithriskanalysisanda
responsiblepersonforeachpermitted
incomingoroutgoingdataflow.

Preventsflowsthroughthefirewallare
permittedforwhichnorealbusinessneed
existsand/orforwhichnobodyis
responsibleincaseitisexploitedforan
attack.

ACI8

Trafficflowintotheautomationcell
shouldberatelimitedonSGW.

PreventsmaliciousattacksoutsidetheAC
thatmayinjectlargeamountsoftraffic
intotheACandcauseadenialofservice
throughnetworkfloodingthere.Thelimit
rateshouldbesufficientlylowsothat
evenifitisfullyused,theperformanceof
theACissufficientinalloperative
situations,includingalarms.

ACI9

SGWdeviceshalllogatleastall
managementactivitiesandallrejected
connections.

Managementactivities,suchascreatingof
newusersormodificationoffirewall
rules,areextremelysecuritycritical,as
theycancompromisethefirewall.Logs
shouldbesenttocentrallogserversto
facilitatelogconsolidationandanalysis,to
avoidexhaustionofthelimitedlog
storagespaceonthefirewall,andtoavoid
thatanattackercanmodifythelogsafter
compromisingthefirewall.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page55

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ACI10

TrafficthroughtheSGWdevicemaybe
initiatedbyeitherside.

Both,nodesinsidetheACanddevices
outsidetheACwithcommunication
permissionsintotheACareconsideredas
trusted.

ACI11

Thereshallbeclearlydocumentedrulesof
whoisauthorizedtoaccesswhatdataand
functionalitywithinthedevices,hosts,and
applicationsintheautomationcelland
whatpurposethisaccesscanbeused.

Adocumentedaccesscontrolpolicyisthe
prerequisiteforimplementingand
auditingtechnicalaccesscontrolrulesand
procedures.MuchofthedataintheAC
maybesubjecttoprivacylawsincertain
legislatures.Inthiscase,detailed,
documentedauthorizationdecisionsfrom
managementarenecessarytoprovide
guidanceandprotectionagainstlegal
persecutionforthesystemandsecurity
administrationpersonnel.

ACI12

Therevocationoftheaccessrightsshould
beimplementedwithin24hours(TBR)
fromthemomenttheaccessright
cancellationwasdecided.

Usersleavetheorganizationorlosetheir
accessrightsduetomanycircumstances.
Itisimportantthatsuchchangesare
quicklyimplementedandenforcedbythe
authenticationandaccesscontrol
components.The24hourstimeframeisa
compromisebetweentechnicaland
administrativefeasibilityandincurredrisk.

ACI13

Thereshallbeanexplicit,documented,
andenforcedprocessformanagingany
temporaryexceptionsfromthe
prescriptionsofthisstandardandpolicies
derivedfromit.Anysuchexceptions
shouldlastonlyfortheminimumtime
(TBR)necessary.

Theremaybeoperationalreasonsto
deviatefromtheprescriptionsofthis
standard.Whilethisisundesirablefrom
thesecuritypointofview,itwillhappen.
Ifthereisnoprocessdefinedapriorito
dealwithexceptions,exceptionswillbe
handledinanadhocfashionleadingto
lossofcontroloverthetiming,duration,
andextentoftheexceptionandlossof
accountabilityandpersonalresponsibility
foranynegativeconsequences.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page56

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

CONTROLNETWORKHOSTSECURITY

2
3
4
5
6
7

Thisrequirementsetdescribesrequirementsonthesecurearchitecture,implementation,andoperation
ofhostsinthecontrolnetwork.Therequirementsettargetshostswithcommercialofftheshelfoffice
operatingsystemssuchasvariantsofUnix,Linux,orWindows.Therequirementsapplytobothserver
andworkstationhosts.Aworkstationhostisunderstoodtobeahostwithaninteractivehumanuserat
theconsole.Inanautomationsystemthesamehostmayplayserverandworkstationroles.Thetext
belowwillclearlyindicatewheretherequirementsforworkstationsandserversmaydiffer.

8
9
10
11
12
13

Inthespiritofdefenseindepthitspecifieslastlineofdefensesecuritymeansagainstanetworkbased
attackoriginatingfromthecontrolnetworkorothernetworks.Suchattacksmaybecausedbyan
outsideadversarywhohasmanagedtobreakthroughthevariousperimeterdefenses(ase.g.specified
byprofilesECIandIRA),orbyacompromiseofoneormultiplehostsonthecontrolnetworkitself
throughamaliciousinsiderattack,aninfectedportablecomputer,oraninfectedportablestorage
medium.Securitymechanismstocounterthisthreatfocusonthefollowing:

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

Reducingthenetworkbasedattacksurfacesothatonlyrequiredservicescanbeaccessedfrom
thenetwork
Reducevulnerabilitiesofexposedservices
Loggingunusualnetworkbasedaccess
Authenticatingcommunicationpartners
Limitingaccesstoauthorizedcommunicationpartners
Ingresspacketfiltering
Egresspacketfiltering
Preventingexploitationofnetworkstackbehavior
Limitingtheinformationthatcanbecollectedaboutthehostanditsservicesviathenetwork

Thisrequirementsetalsospecifiessecuritymeansagainstunauthorizedactionsoftheinteractive
humanuserworkingattheconsoleofanautomationsystemhost.Securitymechanismstocounterthis
threatfocusonthefollowing:

Identifyinginteractiveusersinanonreputableway
Preventingaccessbyunauthorizedusers
Documentinguseractions
Monitoringuseractions
Limitinguseractions
Limitingcapabilityofusertoimportarbitrarydataintothehost

Twounderlyingassumptionsguidedthedevelopmentoftheseprescriptiverequirements.
1. Allusersattheconsole,allotherhostsinthecontrolnetwork,andallcommunicationpartners
areuntrusted.Thisassumptiondefinesthethreatmodelforthisrequirementset.Whileitisnot
generallyassumedthatusersandhostsinthecontrolnetworkareuntrusted,thelastlineof
defensestancetakeninthisrequirementsetintendstokeeptheautomationsystemhost
operatingandfunctionalwithoutrelyingonotherparties.
2. Asecuritymanagementsystemisinplacefortheplant,includingtheControlNetworkandany
connectedDMZNetwork(s).Thisrequirementsetisconcernedwithtechnicalmechanismsand
SP99Part4Draft1Edit0320080310Word972003format.doc

Page57

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4
5

theirconfigurations,andtoasmallextentwithrequirementsetspecificprocesses.Itisnot
concernedwiththedesignandimplementationofageneralinformationsystemsecurity
managementsystemthatincludessecuritypoliciesandadministrativeandmaintenance
processesandprocedures,whichare,ofcourse,allneededtoensurethatthemechanisms
describedinthisrequirementsetoperateasintendedovertheirentirelifecycle.

TABLE10CONTROLNETWORK HOSTSEC URITYREQUIREMENTS


Requirement Requirementspecification
ID

Rationale

CNH1.

Networkbasedservicesaretheentry
pointsintothehoststhatanattackercan
exploit.Fewerexposedservicesmeans
thattherearefewerentrypointsand
potentialvulnerabilitiesthatanattacker
canleveragetocompromisethehost.

Onlynetworkbasedservicesthatare
requiredfortheoperation,management,
andmaintenanceoftheautomation
systemshallbeexposedtothenetwork.

NoteTherearetwomaintechnical
approachestoachievethisobjective:One
candisableallunneededservicesorone
canuseahostbasedfirewall(alsoknown
aspersonalfirewall)runningonthehost
torejectpacketsdestinedforthose
unneededservices.
CNH2.

Asfarasperformancerequirementsallow,
unneedednetworkbasedservices
[SRL:{LOW,REDUCED}:should,SRL:{HIGH}:
shall]bebothdisabledandthenetwork
traffictotheseservicesdeniedbyahost
basedfirewall.

Boththefilteringrulesandtheservice
activationsettingscanbemisconfigured.
Thedefenseindepthapproachofusing
bothmitigationmechanismsreducesthe
chanceoftheexistenceofanexposed
vulnerability.

CNH3.

Onlydataflowsthatarerequiredforthe
operation,management,andmaintenance
oftheautomationsystemshallbeallowed
toleavethehost.

Protectsthehostagainstunauthorized
informationdisclosure,topreventremote
controlviabackdoors,andtoprotect
otherhostsinthenetworkagainstattacks
(e.g.flooding,scanning)originatingfrom
thishostafterapartialcompromise.

CNH4.

Thecommunicationparametersof
requirednetworkservicesonthehostand
incoming/outgoingdataflowswithother
hostsanddevicesinthesystemshallbe
documented.

Forriskanalysis,aswellasinorderto
defineandauditfilteringrulesandservice
activationsettings,itisnecessarytohave
documentationabouttheservicesand
dataflowstheautomationsystem
requires.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page58

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

CNH5.

Asfarasthisispossibleandpractical,the
accesspoints(e.g.TCP/UDPports)of
activeservicesshallbechangedtovalues
thatarenotcommonlyused.Any
exceptionshallbedocumentedand
authorizedbytheresponsibleperson.

Thisisaninstanceofsecurityby
obscurity.Nevertheless,itincreases
securitybecauseitstopsunskilledand
automatedattacksthatidentifyfurther
targetsbyportnumbers(asmanyworms
do),anditmakes(automated)detection
ofattacksfromaccesslogseasier.

CNH6.

Asfarasthisispossibleandpractical,
informationthatallowsidentificationof
operatingsystem,services,orclient
applications(type,version)shallbe
removedorchanged.

Thisisaninstanceofsecurityby
obscurity.Nevertheless,itincreases
securitybecauseitmakesitmoredifficult
foranadversarytoselectattacksandtools
thattargetthevulnerabilitiesofspecific
services.
Note:Ahostprovidesawiderangeof
identifyinginformationtoaclient.This
includesbannersforinteractiveservices
(FTP,TELNET,SSH,),hostinformationin
requestsandresponses(SMTP,HTTP),and
operatingsystemfingerprintsderived
fromspecificnetworkstackbehavior. 6
Note:Forsomeapplicationsand
applicationscenariositmaybenecessary
toidentifyservicetypesandversionsto
enableprotocol/capabilitynegotiationfor
interoperability.Ifthisisnecessary,it
wouldbedesirabletoauthenticatethe
communicationpartnerbeforeexposing
thenegotiationinformation.

seee.g.http://lcamtuf.coredump.cx/p0f.shtml

SP99Part4Draft1Edit0320080310Word972003format.doc

Page59

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
CNH7.

Onlynecessaryuseraccountsshallexiston
thehostorwithintheauthentication
domain.Eachaccountshallbe
documented,statingareasonforits
existenceandthepersonresponsiblefor
additionandremovaloftheaccount.Each
account,bothforhumansandprocesses,
shallhaveonlytheminimalprivileges
neededforitstask.Quotasonresources
usage(CPUload,memoryconsumption,
storagespaceconsumption,networkload,
etc)shouldbedefinedforeachaccountor
process.Proceduresshallbeestablished
andenforcedtoensurethattheexistence
andprivilegelevelofeachaccountis
regularlyreviewed.

Rationale

Unnecessarydefaultorlegacyaccounts
arefrequentlyusedtocompromisea
system.Accountswithunnecessary
privilegesfacilitateinsiderattacksorallow
anexternaladversarytoelevatehis
privilegesafterapartialcompromise.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page60

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH8.

Communicationpartnersonthenetwork
(hostsorprocesses)shallberequiredto
authenticatethemselvesinordertoaccess
networkbasedservices,andthereshallbe
anaccesscontrolfacilitybasedonthis
authentication.

Rationale

Afterpreventingaccesstounnecessary
services,therequiredservicesarestill
exposedtoanattack.Inordertofurther
reducetheattacksurface,only
communicationsfromidentifiedand
authorizedpartnersareacceptedforthese
services.Thismeansthatanattackcannot
originatefromanyhostonthenetwork,
butthattheadversaryfirsthasto
compromiseoneofthelegitimate
communicationpartnersofthetarget
host.
Note:Dependingonthecommunication
protocolandserviceused,various
authenticationmechanismsareavailable.
Ifthenativeprotocol/servicedoesnot
offersecureandstrongauthenticationit
maybetunneledthroughaVPNprotocol
(likeIPSec)forthispurpose.
Note:Authenticationcouldimposea
performanceloadthatmaybe
unacceptableforthesystem.Inthiscase,
theuseofexternalhardwarelikeIPSec
offloadnetworkinterfacecardsshouldbe
considered.

CNH9.

Avirus/malwarescannershallbe
executingonthehost.Itshallcheckeach
fileonthesystemwheneveritisaccessed.
Certainhosts,directories,orfiletypesmay
havetobeexemptedfrommalware
scannercoverageduetoperformance
considerations.Suchexceptionsshallbe
documented,includingadescriptionof
thereasonfortheexemption.

Intheory,ifallprecautionsaretakenas
requiredbythisstandard,nomalware
shouldbeabletoreachanautomation
host.Inpractice,usingamalwarescanner
providesanadditionallineofdefensein
casesomeoftheothermalwaredefense
mechanismshavebeenineffective.
Note:Informationaboutsupported
virus/malwarescanningproductsmaybe
obtainedfromtherespectiveautomation
systemvendors.Theyshouldalsobeable
toprovidescannerconfigurationsthat
takespecificperformanceconstraintsof
theirsystemsintoaccount.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page61

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

CNH10.

Virus/malwarescannersignaturesonthe
hostshallbeupdatedwithinonedayafter
becomingavailable.

Signaturebasedmalwarescannersare
onlyeffectivewithcurrentsignatures.

Afilesystemintegritycheckershall
regularly,atleastonceperday,examine
keyfiles(operatingsystemand
automationsystembinariesand
configurationfiles)onthehost.Thefile
signaturebaselinedatabaseshouldonly
beaccessibleforreadingfromthehost.
Certainhostsordirectoriesmayhaveto
beexemptedfromregularintegrity
scanningduetoperformance
considerations.Suchexceptionsshallbe
documented,includingadescriptionof
thereasonfortheexemption.Forthese
hostsintegritychecksshallatleastbe
conductedeverytimetheautomation
systemperformanceallows,e.g.duringa
plantmaintenanceshutdown.

Anunexpectedfilechangecanbean
indicatorofamalwareinfection,aremote
systemcompromise,anunauthorized
actionofalocaluser,orhardware
degradation.Filecorruptionmayplacethe
automationsysteminanuncontrolledand
uncontrollablestate.Thereforeitis
importanttoascertainregularlythatthe
hostfilesystemisstillintheexpected
state.

CNH11.

Note:Therehavebeenincidentswhere
suchsignatureshavefalselyidentified
certainlegitimateapplicationfilesas
malware.Inordertopreventdenialof
servicebecauseofincorrectmalware
scanneroperationitisthusnecessaryto
testcarefullywhetheracertainsignature
updatemaybeusedonahostofaspecific
automationsystem.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page62

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH12.

Arealtimehostbasedintrusiondetection
system(HIDS)shouldbeactiveonthe
host.

Rationale

ThecapabilitiesofhostbasedIDS,
networkbasedIDS,andfilesystem
integritycheckersarecomplimentary.A
hostbasedintrusiondetectioncanalert
userstounusualorclearlyillegitimate
activitiesonahost.
Note:Integritycheckersareoftenalso
countedasHIDS.However,theydonot
immediatelyalerttoongoingattacks.Real
timeHIDScontinuouslymonitoroperating
systemstateandactivity,suchassystem
calls,toimmediatelyrecognizeevents
thatfalloutsidethenormalorapproved
behavior.

CNH13.

Thehostshallmonitoritsconsumptionof
criticalresourcessuchasmemory,disk
space,CPUcapacity,networkinterface
capacity,andlogstoragecapacity.Itshall
alertthelocaluserifcriticalthresholdsare
passed.Itshouldmakeresourcestatus
and/orresourcealertsalsoavailablefora
performancemonitoringfacilityofthe
automationsystem.

Anunexpectedchangeinhostresource
consumptionmaynegativelyinfluencethe
abilityofthehosttofulfillitsdutiesaspart
oftheautomationsystem.Suchchange
mayalsobeindicativeofanongoing
attackonthehost,orevenacompleted
compromise.
Note:Whenmakingsuchsystemdata
availabletootherhostsinthesystem,e.g.
aspartofacentralizednetworkand
systemmonitoringfacility,itmaybe
necessarytomakeatradeoffbetween
thesecuritybenefitofthismeasureand
securitydisadvantagesofunsecure
protocolsusedforthispurpose(e.g.
SNMPv1).

SP99Part4Draft1Edit0320080310Word972003format.doc

Page63

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

CNH14.

Asystemaudit,eitheraspartofaregular
auditregimeoraspartofaforensic
investigationtodetermineanattackand
itsscopecanbeconductedwithmuchless
effortandhigherreliabilityifthereisa
knowngoodbaselineagainstwhichthe
findingscanbecompared.

Anauditbaselineshallbedocumentedfor
theknowngoodhost.Theauditbaseline
shallatleastcontain:listeningnetwork
ports,runningservices,runningprocesses,
userandgroupaccounts,filesystem
status,andsecuritysettings.

Note:Ithastobeensuredthattheknown
goodbaselinehasreallynotbeen
compromised.
Note:Agoodtimetocreatethisaudit
baselineisdirectlyafterinstallation.
Note:Thefilessystemstatuscanbe
baselinedwithafilesystemintegrity
scanner.
CNH15.

Eachhumanuseronthehostandinthe
domainoftheautomationsystemshall
haveanindividualuseraccount.
Credentialsshallnotbesharedwithother
users.

Withshareduseraccountstheoriginator
ofaspecificactioninthesystemcannot
beidentified.Ausermaybeableto
plausiblydenyinvolvementinamalicious
action.

CNH16.

Useractivitieswithregardtoautomation
systemoperation,hostmanagement,and
securitymanagementshallbelogged.

InsidersareasignificantdangerforIT
systems.Asinsidershave,bydefinition,
authorizedaccesstothesystem,oneof
themostimportantmeansofdefense
againstthemisdeterrencebasedon
punishmentafterdetectionoftheattack
andidentificationoftheadversary.

Systemlogsshouldbetamper
resistant(seeNote2).

Systemlogsshouldbesenttoa
centrallogserver.

Note1:Locallegalrequirementsregarding
loggingofuseractionshavetobe
respected.

Systemlogsshallonlybedeletedor
modifiedbyusersinaspecificauditor
role.
Note2:TheUniversityofCambridgehas
reportedsystemlevelfailuresoftamper
Alllogmanagementactivitiesshallbe
proofing(Drimer,MurdochandAnderson
logged.
February2008).Securityassuranceneeds
toaddressthisissue.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page64

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH17.

Astrategyforhostbehaviorincaseoflog
storagespaceexhaustionshallbedefined,
documented,andimplemented.

Rationale

Attackactivitiesmaygeneratesomanylog
entriesthattheallocatedlogstorage
spaceisexhausted.Inthissituationthree
basicsystemreactionsarepossible:

Stopsystemuntillogiscleared:This
preservesthefullaudittrailsbut
compromisesavailability.

Overwriteolderlogentries:This
preservesavailability,butallowsan
adversarytoerasecriticallogentries
fromthetimeoftheoriginal
compromisebygeneratingmanymore
logentries.

Stoplogging:Thispreserves
availability,butallowsanadversaryto
continuewithattackactionsthatare
notlogged.

Dependingonthespecificsystemorhost,
anyoneofthethreelogexhaustion
strategiesmaybemostappropriate.CNH
17requiresthatacleardecisionregarding
thestrategyistaken.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page65

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

CNH18.

Theauthenticationsystemhastobeso
strongthatitcannotbeeasilybypassedor
credentialsguessed.Examplesof
authenticationprinciplesthatmaybe
combinedformultifactorauthentication
aree.g.passphrases,biometrics,onetime
passwordgenerators.Forsomesystems,
multifactorauthenticationwillnotbe
appropriate.Especiallyinthiscase,the
strengthofthepassphraseisimportant.
However,thelengthofapassphrasethat
isconsideredsecurewillchangeovertime
andthecharacterchoiceavailablefor
creatingapassphrasemaydependon
locality.Forthisreason,CNH18doesnot
prescribespecificparametervaluesbut
onlyrequiresthatrulesaremadeand
enforcedforeachspecificsystem.

Multifactorauthenticationshouldbe
usedtoauthenticateusersforinteractive
sessionsonthehost.Passphrasebased
credentialsshallmeetdefinedand
documentedcomplexityrequirements
withregardtolengthandcharacterset
variety.Toolsshouldbeusedtoenforce
compliancewiththesecomplexity
requirements.

Note:Inthecontextofauthenticationmanagement
itisalsoimportanttodefinewhathastohappenin
caseofanauthenticationfailure.Alternativesare
e.g.unlimitedretry,unlimitedretrieswith
progressivedelay,orlockoutafteralimited
numberofretries.
Note:Eachsite/systemshoulddefinerulesonpass
phraseexpiryandchangehandling.
Note:Asitemayrequireanemergencyoverride
capabilitytobypassthetechnicalauthentication
andaccesscontrolsystemincertaincircumstances,
especiallyincaseoftechnicalfailuresofthe
authenticationandaccesscontrolsubsystem.
Technicalorproceduralmeansareneededto
ensurethatthisbypasscannotbeusedtocreatea
situationofuncontrolleduseraccessorplausible
deniabilityofactions.
Note:Asitemaywanttoinstituteanescrow
processforcertainorallusercredentialsinorderto
beabletoregainaccessafterknowledgeaboutthe
credentialvaluehasbecometemporarilyor
permanentlyunavailablefromthecorresponding
user.Technicalorproceduralmeansareneededto
ensurethatthisescrowprocesscannotbeusedto
createasituationofuncontrolleduseraccessor
plausibledeniabilityofactions.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page66

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH19.

Ifauserleaveshisconsole,itshallbe
ensuredthatnootherhumancantake
overhisinteractivesession.

Rationale

Thesystemwillassociatetheloggedin
user,theuserthatestablishedthesession,
withallactionstakenfromthatconsole.If
adifferentpersoncanexecutecommands
fromthatconsolewithouthavingto
authenticatehimself,useraccountability
cannotbeensured.
Note:CNH19maybefulfilledbytechnical
means,suchasconsolelockingafteran
idleperiodorafterremovalofa
smartcard.Incertainoperational
situations,itmaybedesirabletolockonly
inputdevicesbuttocontinuetodisplay
screencontent.Inotheroperational
situationsitmaybeundesirableor
unfeasibletolocktheconsole,e.g.to
avoidalogindelay.Inthiscasenon
technicalmeans,suchasarequirement
foratleasttwopeopletobepresentin
thecontrolroomatalltimes,maybe
appropriatetomeetthisrequirement.

CNH20.

Theaccessrightsofausershallbe
allocatedaccordingtoroleorroles.Access
controltotheautomationsystemshallbe
enforcedonafinegranularleveldownto
individualautomationobjectsand
functions.

Evenforauthorizedusersthereislikely
notthenecessitytohavefull(read,write,
delete,create)accesstoallpartsofthe
system.Assigningonlytheminimally
necessaryaccessrightsandprivilegesto
usershelpstoprotecttheautomation
systemagainstintentionalandincidental
maloperationandtoprotectthe
individualuseragainstliability.Rolebased
accesscontrolisawellestablished
schemeformanagingaccessrightsfor
largergroupsofuserswithdifferentand
timevaryingaccessrequirements.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page67

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

CNH21.

Theusershallhaveaccesstothe
underlyingoperatingsystemoritstools
onlyasfarasisnecessaryforhisapproved
role.Accesscontroltotheoperating
systemshallbeenforcedonafine
granularleveldowntoindividualfilesand
configurationsettings.

Operatingsystemstoolsallowsignificant
modificationsofthestateand
configurationofthehostandthewhole
automationsystem.Thismayhave
negativeconsequencesforthefunction
andthesecurityoftheautomation
system,suchasdeletionoffiles,changing
ofoperatingsystemornetworksettings,
orinstallationofunauthorized
applications.Restrictingaccessto
operatingsystemtoolshelpstoprotect
thehostagainstintentionalandincidental
maloperationandtoprotectthe
individualuseragainstliability.Manyusers
oftheautomationsystem,suchas
operators,maynothaveanyneedfor
directaccesstotheoperatingsystem.

CNH22.

Theautomationsystemshallprovide
meansforselectivelyrequiringdual
approvalofuseractions.Suchmeans
shouldbeappliedtoactionsthatare
criticaltoplantandproductsafety.

Thetwopersonruleensuresthatactions
withespeciallydisastrousconsequences
cannotbeinitiatedbyonepersonalone.
Thisprotectsagainstintentionaland
incidentalmaloperation.Dualapprovalis
oneofthemosteffectivemeansagainst
insiderattacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page68

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH23.

Itshallnotbepossibletoimport
unauthorizedorinfectedfilesfromnon
approvedsourcesviathenetwork.

Rationale

Intentionalorincidentalimportof
maliciousfilesintothesystemisa
significantthreat.Corresponding
prescriptionsinthesecuritypolicyshould
beaugmentedbytechnicalmeans.
Note:CNH23maybemetbynotinstalling
suchapplications(e.g.emailclient,web
browser,IRCclient,ftpclient,P2P
applications,etc)onthehost,orby
configuringtheseapplicationsorthe
networkinginfrastructure(firewalls,
routers)suchthattheycanonlyaccess
approvedservers.
Note:Itmaybedesirabletohaveless
restrictedelectroniccommunication
facilities(webaccess,emailaccess)
availableinthecontrolcenter.Forthis
purposeitisrecommendedtomake
dedicatedhostsavailablethatarelocated
inthecontrolcentre,butnotconnectedto
controlnetwork.Theymayinsteadbe
connectedtotheenterprisenetworkor
directlytheInternet.

CNH24.

Proceduresshallbeestablishedand
enforcedtoprotectagainstimporting
unauthorizedorinfectedfilesfromnon
approvedsourcesviaportablestorage
media.

Intentionalorincidentalimportof
maliciousfilesintothesystemisa
significantthreat.Corresponding
prescriptionsinthesecuritypolicyshould
beaugmentedbytechnicalmeans.
Note:CNH24maybemetbyremoving,
locking,temporarilydisabling,or
permanentlydisablingthephysical
interfacesofthehostfortherelevant
portablestoragemedia.
Note:Forthesecurehandlingofportable
storagemediaseeClauseFehler!
Verweisquellekonntenichtgefunden
werden..

SP99Part4Draft1Edit0320080310Word972003format.doc

Page69

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
CNH25.

Theoperatingsystem,automationsystem,
andauxiliaryapplicationsshallbepatched
andrulesetsandsignaturesforsecurity
applicationsshallbeupdatedaccordingto
theinstructionsoftheautomationsystem
vendororsystemintegrator.

Rationale

Ingeneral,itisdesirabletokeepthe
systemasuptodateaspossibleand
installsecuritypatchesandupdatesas
theybecomeavailable.However,apatch
orupdatemayconflictwiththecontrol
system,resultingindegradedor
unavailablefunctionalityordegraded
timingbehavior.Therefore,apatchor
updateshallonlybeappliedafterithas
beentestedandapprovedbythe
automationsystemvendor.
Note:Obviously,theautomationsystem
vendorisunabletotestapatchorupdate
foranypossibledeployedcontrolsystem
variation,inparticularforhighly
customizedsystems.Itistherefore
recommendedtodoadditionaltesting
alsoattheplant,andtotakethe
possibilityofpartialsystemfailureaftera
softwaremodificationintoaccountwhen
planninganddeployinganupdate.
Backup,training,ordevelopmentsystems,
ifavailable,maybeusedforinplant
testing.Astageddeploymentmaybe
prudenttoretainsomecontrolcapability
incaseofproblemswiththesoftware
modification.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page70

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
CNH26.

Allimportantfilesonthehostshallbe
regularlybackedup.Thebackupmedia
shallbestoredatasafeandsecure
location.Accesstobackupmediashallbe
controlled.Backupsaswellasthe
backup/restoreprocessshallpreserve
electronicaccesscontrolrestrictions
associatedwiththefiles.Backupfilesas
wellasthebackup/restoreprocessshall
beregularlytested.Theintegrityof
backupshallbeverified.

Rationale

Incaseofasuccessfulattackorincidental
systemfailureabackupmayhelptoget
thesystemquicklybackintoworking
state.Experienceshowsthatincaseofa
realincidentoftenthebackupfails
becauseofpreviouslyundetectedflawsin
thebackup/restoreprocess.Also,
backup/restoretoolsandprocessesthat
arenotsecurityawaremayleadto
violationofsecurityobjectivessuchas
confidentialityandintegrity.
Note:Dependingonthelevelofsystem
availabilitythatistobesupportedbythe
backupprocess,varioustechnicalbackup
measuresexist.

Backupofdatafilestotapesorother
archivalmediaprotectsagainstdata
lossbutdoesnotsupporthigh
availability.

Completecopiesofthewholehard
disk(mirroring,ghosting)including
operatingsystem,dataand
applicationfilesfacilitatesfaster
rebuildingofasystem,limitedonlyby
thetimetocopythedata,butnot
additionalinstallationand
configurationeffort.

Completecopiestoanexchangeable
harddiskenableevenfasterrecovery,
asonlytheharddiskshavetobe
swappedandthehostrestarted.

Thebackupschemewiththefastest
recoverytimeisastandbyhostto
whichallfilemodificationsare
mirroredinrealtime.Inordertoavoid
thatthestandbyhostfallsvictimtoan
attacktogetherwiththeprimary,it
shouldnotbeconnectedtothe
controlnetwork,butonlytothe
primaryhostviaadirectlink.
SP99Part4Draft1Edit0320080310Word972003format.doc
Page71

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

CNH27.

Loggingasdeterrentagainstmalicious
insiderattacksisonlyeffective,ifthelogs
areactuallyreviewedinawaythatwill
detectsuchattackandallowlegal
prosecution.

Allsecuritylogsshallberegularly
reviewedandtransferredtosecureand
safearchivalstoragebyanindependent
securityauditorwhohasnooperationalor
systemadministrationdutiesinthe
controlsystem.

Note:Locallegalrequirementsregarding
chainofcustodyforevidencehavetobe
respectedifthelogsareintendedtobe
usedaslegalevidence.

INTERACTIVEREMOTEACCESSSECURITY

2
3
4
5
6
7
8

Interactiveremoteaccess(IRA)securityisspecifiedinthisclauseforoperationofaremoteaccess
connectiontoacontrolsystemthatrequiresahighsystemsecurityassurancelevel.Remoteaccess
includesconnectionviatelephonedialup,directInternetconnection,thecorporatenetwork,orother
networksthatare,fromtheperspectiveoftheprocesscontrolnetwork,untrustedwithrespectto
networktraffictypesandvolumeaswellasuserintentionsandcapabilities.Particularemphasisis
placedonthesecurityoftheexternalclient,whichislikelytobetheweakestpointinthisarchitecture.

9
10
11

Oneoftheguidingprinciplesforthisrequirementsetistoseparatetheaccesstechnology(Internetvia
corporatenetwork,directInternetlinkortelephonedialup)asmuchaspossiblefromtherequired
securitymechanismsandmeasures.

12
13
14
15

Thisprofileisapplicableforusagescenarioswhereacontrolsystemisinteractivelyaccessedfrom
clientsintheenterprise,oranywhereontheInternet,ordirectdialupfordiagnosticormaintenance
servicesorforinformationretrieval.Interactiveaccessimpliesrequestssendfromtheclient,requires
fastresponse,andincludesoperationviakeyboardandotherinputdevicesonamirroreddesktop.

16
17
18
19
20
21
22
23
24
25

Thisprofileisnotintendedforusagescenarioswhereacontrolsystemonlysendsoutreports
andnotificationsaboutproductionstatusandstatuschangestoreceiversintheenterprise
networkorsupplychainpartnersconnectedviaInternet,orreceivesbatched,nonrealtime
datafromclientsintheenterprisenetworkortheInternet,suchasproductionordersandother
productionrelatedinformation,controlsoftwareupdates,orapplicationupdates.
Thisprofileisnotintendedforusagescenarioswhereacontrolsystemiscontrolledinrealtime
fromaremotesiteandwhereafailureinthecommunicationwouldleadtoimmediatesevere
consequencesforthecontrolledphysicalplant.Measuresfromthisrequirementsetmightbe
usedinthiscase,butadditionalthreatmitigationmeasures,especiallywithregardtoensuring
availability,maybenecessary.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page72

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

IRAREFERENCETOPOLOGY

2
3
4

Figure2showsanotionalIRAreferencetopologyusedtovisualizethearrangementofcomponents
discussedintheIRAsecurityrequirementset.Thefigureisnotional,anexample,andisnotanormative
specificationofISA99.00.04.

FIGURE2NOTIONALIRAREFERENCETOPOLOGY
remote client

remote client

VPN
terminator / client

VPN
terminator / client

FW

FW

broadband
modem /
access router

modem

Connectivity
option (a):
EN-Internet

Connectivity
option (b):
direct Internet

public switched
telephone network
(PSTN)

Internet

Enterprise Network (EN)

Connectivity
option (c):
dial-up

broadband
modem /
access router

modem

FW1b

FW1c

see also profile ECI

Security Management
Network (SMN)

External
Connectivity
Gateway
(ECG)

FW1a

NIDS
Semi-Protected Network
(SPN)

security
mangement host

RADIUS
server

FW2

VPN
terminator

Control Network (CN)


remote access
workplace

SP99Part4Draft1Edit0320080310Word972003format.doc

domain
authentication
server

Page73

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

THREATSADDRESSEDBYIRAREQUIREMENTS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Thisrequirementsetcontributes,inthesenseofadefenseindepthstrategy,tothemitigationofthe
followingthreats:

Attacksontheremoteclientwheretheadversarycompromisesthehostclientinorderto
obtainconfidentialinformationaboutproductionoperations,ortodisturbproduction
operationsortogaincontroloverproductionoperations.
Attacksonthelegitimatetrafficontheconnectingnetworkwheretheadversaryobtains
confidentialinformation,otherthanauthenticationorauthorizationinformation,fromdata
flowingbetweentheremoteclientandthecontrolsystem.
Attacksontheconnectingnetworktoobtainauthenticationoraccesscontrolinformationfrom
dataflowingintothecontrolsystemthroughlegitimatechannelsinordertofacilitateother
attacksonthecontrolsystem.
Attacksintendedtomodifyinformationflowingortoinjectinformationintotheflowbetween
theremoteclientandthecontrolsysteminordertodisturbproductionoperationsortogain
controloverproductionoperations.
Attacksintendedtocausedenialofservicetotheremoteclientinordertodisturbproduction
operations.
Attacksonthesecuritysystemprotectingthecontrolsystemstofacilitateotherattacksonthe
controlsystem.

Thisrequirementsetisnotintendedtomitigateinsiderthreatsdesignedtodisturborcontrolsystem
operationsviadenialofserviceattackortodisturbproductionoperations.

ASSUMPTIONSUNDERLYINGTHEIRAREQUIREMENTS

23
24

Allnetworksoutsidethecontrolnetwork,includingtheenterprisenetworkandanynetworksatthe
remoteclientsite,areconsideredasuntrustedanduntrustworthy.

25
26
27
28
29

Rationale:Eveniftheenterprisenetworkisitselfbehindoneormultiplefirewallstooutsidepublic
networksandisthusatrustednetworkfromtheperspectiveofenterpriseIToperations,itstillhasa
significantlybiggerandmorediverseuserpopulationthantheprocesscontrolnetwork.Usersonthe
enterprisenetworkmayengageinactivitieslikereadingemailorbrowsingthewebwhichexposethem
todirectedandundirectedattacksatlevelsofriskthatareunacceptablefortheprocesscontrolsystem.

30
31

Eachcommunicationpathbetweenthecontrolnetworkandoutsidenetworksconformstoa
requirementsetofISA99.00.04.

32
33
34
35
36
37
38

Rationale:ISA99.00.04reducestheriskofelectronicattacksoncontrolnetworksandequipmentby
prescribingcertainmeasuresandrequirementsthatprovideaseriesofdefensive,detective,and
reactivecontrolsbetweenanattackeranatarget.Thedifferentrequirementsetsofthisstandardstrive
foranequivalentlevelofprotectionwheredifferenttypesofcommunicationpathsbetweenan
adversaryandatargetexistsinparallel.Theriskreductionthatthisstandardaimsforcannotbe
achievedifpartsofthecommunicationpathbetweentheadversaryandthetargetareshortcircuited
bylesssecuremeansofcommunication.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page74

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2

Equipmentandfunctionsinthesemiprotectednetworkarenotcriticaltotheoperationofthecontrol
networkandtheassociatedphysicalprocess.

3
4
5
6
7
8

Rationale:Thesemiprotectednetwork(SPN)isnotunderthefullprotectionofallsecuritymeasuresfor
thecontrolnetworkandthusmorelikelytobesubvertedbyanadversary.Partoftheprotection
philosophyforthecontrolnetworkdependsonthefactthatanattackthatovercomestheoutermost
defensesofthecontrolnetworkasdescribedinISA99.00.04isdetectedandcontainedwithintheSPN,
whichmayresultindestruction,modification,unavailability,ordisclosureofalldataandfunctions
withintheSPN.

9
10

Theavailabilityofdataflowbetweentheremoteclientandthecontrolnetworkisnotcriticaltothe
operationofthecontrolnetworkandtheassociatedphysicalprocess.

11
12
13
14
15

Rationale:Theavailabilityandintegrityofthecommunicationpathanddataflowbetweenthecontrol
networkandtheremoteclientcann otbeguaranteedbyISA99.00.04.Also,partoftheprotection
philosophyforthecontrolnetwork dependsonthefactthatanattackisstoppedorcontainedby
interruptingthetrafficbetweentheoutsideandthecontrolnetworkatanypointintheexternal
connectivitygateway.

16
17

Thecontrolsystemismanned.Thereisstaffavailableatthecontrolcentertoinitiateandmonitor
remoteconnectio nsandtoexecutecertainprocedures.

18
19
20
21
22
23
24

Rationale:With staffonthecontrolnetworksideitispossibl etodisallowtheexecutionofcertainhigh


riskoperationsfrom theremoteclient.Suchactionsincludee. g.rebootofhosts,reinstallationofhosts,
orimportofexternaldata(afterverificationofauthenticityandexaminationformalware).Itstrongly
reduces theexp osuretoexternalattacksifcooperationisne ededfromthecontrolnetworkstaffto
initiatearemote connection(e.g.byelectricallyswitchingon amodem,unlockinganaccount,or
generatingaon etimepassword).Italsoreducesthedanger ofinsiderattacksbytheuserontheremote
clientifeachremotesessioniscontinuouslymonitoredonth econtrolnetworkside.

25
26

Asecuritymanagementsystemisinplacebothforthecont rolnetwork/semiprotectednetworkand
theremoteclientsite.

27
28
29
30
31
32

Rationale:Thisrequirementsetisconcernedwithtechnicalmechanismsandtheirconfigurations,andto
asmallextentwithspecificprocesses.Itisnotconcernedwiththedesignandimplementationofa
generalinformationsystemsecuritymanagementsystemincludingsecuritypoliciesandadministrative
aswellasmaintenanceprocessesandprocedures,whichare,ofcourse,allneededtoensurethatthe
mechanismsdescribedinthisprofileoperateasintendedovertheirwholelifecycle.Thesemattersare
prescribedinParts2and3ofthisseriesseereferences[2]and[3].

33
34
35

Thereisaseparatecommunicationpathbetweentheremoteclientsiteandthecontrolnetworksite
toexchangedatabetweenusersatthosesites.Thiscommunicationpathisconnectedtoneitherthe
controlnetworknortheremoteclient.Thiscommunicationpathneedonlybeavailableondemand.

36
37
38
39

Rationale:Itmaybenecessaryforthepurposeoftheremoteaccessactivitytouploadordownloadto
orfromthecontrolnetwork.Theremoteclientshouldnothavetheauthorizationtodothis,butinstead
thesedataarecommunicatedviaaseparatecommunicationpathisolatedfromthecontrolnetworkand
remoteclientsothatcontrolnetworkstaffcanapplyproceduresonthosedataasrequiredbypolicy,
SP99Part4Draft1Edit0320080310Word972003format.doc

Page75

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4

e.g.verificationofauthenticityandexaminationformalware.Note:Thiscommunicationpathmaybe
realizedbyahostinthecontrolnetworksidecontrolcenter,whichisconnectedtotheenterprise
network,butnotthecontrolnetwork,andahostattheremotesiteoffice,notconnectedtotheremote
client,bothlinkedviaemailfacilitiesthatuseencryptionanddigitalsignatures.

5
6

Thisrequirementsetisconcernedwiththesecurityoftheremoteclientonlyasfarastheprotection
oftheconnectedcontrolnetworkisconcerned.

7
8
9
10
11

Rationale:Thehostsanddevicesontheremoteclientsidemaybeusedforotherpurposesand
governedbyothersecuritypoliciesduringtimeswhentheyarenotconnectedtoacontrolnetwork.
Also,theremightbeaspectsofinformationsystemsecurity,e.g.concerningprivacylaws,thatmightbe
aconcernfortheremoteclientorganization,butarenotrelevantforthesecurityofaconnectedcontrol
network

12

IRASECURITYREQUIREMENTS

13
14
15

IRAnetworktopologysecurityrequirementsarespecifiedinTable11.Becausetherequirementsare
thesameastheECInetworksecurityrequirementsspecifiedinTable16theyarecrossreferencedusing
[ECIx]notation.

16

TABLE11IRANETWORKTOP OLOGYSE CURITYREQUIREMENTS


Requirement Requirementspecification
ID

Rationale

IRA1.
[ECI1]

Theobjectiveistopreventasubversionof
asinglehost,e.g.ontheoperatingsystem
ornetworkstacklevel,disablesboth
firewallsatthesametime.Also,a
configurationmistakeforthefirewallrule
setwillnotleavethecontrolnetwork
completelyunprotected.

Thetwofirewalls(FW1a/b/candFW2)
showninFigure2shallbedeployedon
differenthosts.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page76

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA2.
[ECI2]

Thetwofirewallsshallbediverse.

Rationale

Theobjectiveistopreventthepossibility
thatasinglevulnerabilityinthefunctional
principle,implementation,orconfiguration
ofthefirewallfunctioncanbeexploitedby
anattackertoovercomeallfirewall
protectionprovidedbytheexternal
connectivitygateway(ECG).
Note:Diversityshouldberealizedbyusing
differentfirewallapplicationsrunningon
differentplatforms.Thedifferentfirewall
applicationsmaybepurchasedfromthe
samevendor.Thesamefirewallapplication
ondifferentplatforms,e.g.ageneral
purposePCandadedicatedappliancedoes
notrealizediversity.

IRA3.
[ECI3]

Firewall2shallberealizedasan
enhancedstatefulprotectionfirewall.

Firewall2carriesthemainresponsibility
forcontrollingtrafficaccesstothecontrol
network(CN)andthusshouldusethemost
sophisticatedfilteringfunctionality
available.Performanceislesscriticalthan
forFW1,asnohighvolumetrafficis
expectedfortheproductiontraffic
betweenCNandoutsideandmalicious
highratetrafficwillalreadyhavebeen
rejectedbyFW1.

IRA4.
[ECI4]

Firewall1mayberealizedasafiltering
router.

Firewall1hastofendoffapotentiallyhigh
volumeofunauthorizedtrafficfromthe
outsideforwhichafilteringrouterisbetter
suitedthanaproxyfirewall.Asfirewall2
willprovideproxylevelinspectionand
protection,itisjustifiabletoemployas
FW1alowercostfilteringrouter.
Note:Manyactualfilteringrouterproducts
onthemarketalreadyprovidesecurity
functionality,e.g.statefulfiltering,that
goesbeyondtheminimumdefinitionofa
filteringrouterinthisstandard.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page77

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA5.
[ECI5]

Allhostsinthesemiprotectednetwork
shallbesecured.

Firewallhostsareessentialelementsofthe
securityarchitecture.Inordertomakeit
difficultforanattackertosubvertthem,
theyshouldbeconfiguredsothatan
attackerhasthesmallestpossiblesetof
workingpointsforanattack.This
philosophyofconfigurationisalsoknown
ashardeningandcomprisesactionssuch
asremovingunnecessaryuseraccounts,
applications,andservices,settingtight
accesscontrolrulesonresources,and
requiringstrongauthentication
mechanisms,segregationofduties,and
principleofleastprivilegeforauthorized
useraccounts.

IRA6.
[ECI6]

Firewallhostsshallrunonlythefirewall
applicationandsupportingapplications.

Theriskthatanattackerisableto
compromiseahostincreaseswiththe
numberofapplicationsandserviceson
thathost.
Note:Supportingapplicationsaccordingto
theintentofthisclauseareapplications
thatsupportthesecurityandaccess
controlpurposeofthefirewallthrough
functionssuchasVPNtermination,
authentication,logging,intrusion
detection,virusfiltering,orapplication
levelprotocolinspection.Thisclause
prohibitsotherapplications,especially
thosethataresourcesordestinationsof
productiontraffic.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page78

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA7.
[ECI7]

Securitydevicesandotherhostswith
securityfunctionalityshallbe
administratedviachannelsthatareout
ofbandwithrespecttoproduction
traffic.Ifthesecuritymanagement
channelhastobeconnectedtoexternal
networkstheinterconnectionbetween
thesecuritymanagementchanneland
theexternalnetworkhastoconformtoa
profileofthisstandard.Inthiscase,the
correspondingsecuritydevicesmaybe
administratedviathesamesecurity
managementchannel.

Rationale

Thisrequirementrequiresthatsecurity
managementtrafficflowsvia
communicationpathsthatareseparate
(outofband)withrespecttoproduction
traffic.Administrationofthesecurityand
networkingdevicessuchasfirewalls,
switches,routers,andintrusiondetection
system(IDS)sensorsmustbefeasibleeven
whenanattackortheresponsetoan
attackhaveinterruptedcommunicationon
thecommunicationpathforproduction
traffic.Also,thisrequirementensuresthat
anattackercannotusethecommunication
pathforproductiontraffictodirectlyattack
theconfigurationinterfacesofthesecurity
mechanisms.
Connectionofthesecuritymanagement
networktoexternalnetworksmaybe
necessaryforruleupdatesorrealtime
communicationwithexternalsecurity
serviceproviders.
Note:Applicationnote:Therequiredout
ofbandcommunicationcanberealized
e.g.viaafixedSecurityManagement
Network(SMN)asshowninFigure2,orvia
adhocconnectionsbetweenthesecurity
deviceandtheadministratorhost,aslong
asthisdoesnotopenanydirectorindirect
connectionbetweenthecommunication
pathfortheproductiontrafficandthe
managementinterfaceofthesecurity
devices.TheSMNcouldbebasedon
Ethernetorserialprotocols.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page79

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA8.
[ECI8]

ItcannotrealisticallybeexpectedthatFW1
willstopallattacks.Asuccessfulsecurity
architecturereliesnotondefensealone,
butalsoondetectionandreaction.TheECI
thereforehastoprovidethecapabilityto
detectattacksthatgetbeyondFW1,andto
initiatecountermeasureswithina
timeframethatmakesithighlyunlikely
thattheattackercaninthemeantimealso
overcomethedefensesprovidedbyFW2.

Anetworkbasedintrusiondetection
systemsensor(NIDS)shallbedeployed
onthesemiprotectednetwork(SPN).

Note:TheNIDScouldusedeterministic
rulesorstatisticalanomalydetectionor
anycombinationthereofasfunctional
principles,accordingtotheIDSevaluation
philosophyandcapabilityoftheenterprise.
[MN:Whowillberesponsibleforrule
creation,customizationandmaintenance]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page80

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA9.
[ECI9]

Intrusiondetectionsensorsonthesemi
protectednetworkshallhaveno
connectiontothecontrolnetwork,or
outsidenetworks,andshallnotbe
addressablefromthesemiprotected
network.

Rationale

ThereisnoneedfortheIDSsensorto
receivedirectedtrafficfromtheSPN.
Makingitsinterfacenotaddressable
reducesitsattacksurfaceanddecreases
thelikelihoodthattheattackercan
compromisetheIDSsensorhost.
Note:Technically,thisrequirementmeans
thatnoIPaddressisassignedtotheNIDS
sensorinterfaceconnectingtotheSPN,a
practicealsoknownasastealth
interface.Theinterfaceisinstead
configuredforpromiscuousmode,which
allowscapturingallpacketsonthe
network,notonlythoseaddressed
specificallytotheinterface.Inorderto
captureandinspectalltrafficontheSPN,
theIDSsensorinterfacehastoseethis
traffic.Thisisnotpossibleinnormal
switchedEthernet.Varioustechnical
solutionsexist,e.g.useofhubs(low
performance),useofspecialswitches
wherealltrafficcanbemirroredtoone
port,ornetworktaps.

IRA10.
[ECI10]

Firewallsshallfailtoablockingstate.

Incaseafirewallcannotcontinueto
provideitsaccesscontrolandsupporting
functions,e.g.duetoasoftwarefailure,log
exhaustion,resourceexhaustion,ortraffic
overloaditshalltrytoindicatetheproblem
toasupervisoryinstanceandgointoa
statethatblocksallincomingandoutgoing
productiontraffic.Thisrequirement
preventsthatanattackercandisablethe
protectionprovidedbythefirewallviaa
relativelysimpletypeofattackthatdoes
notsubvertthefirewallitself,e.g.high
volumetrafficortrafficthatcreatesmany
logentries.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page81

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA11.
[ECI11]

Enterprisenetwork,controlnetwork,
securitymanagementnetworkandthe
semiprivatenetworkshallbe
implementedonphysicallyseparate
networkingequipment.

Thisrequirementaddressestheuseof
virtualLANs(VLANs)etc,whichrun
logicallyseparatecommunicationnetworks
onthesamemedium.Withtodays
technologyitisrelativelyeasy,e.g.via
flooding,tocompromisethenetwork
separationprovidedbyVLANswitches,
whichwouldpotentiallyremovesecurity
mechanismsfromtheattackpath.

IRA12.

Eachseparatecontrolnetworkshallbe
accessedonlyfromdedicatedremote
clients,whichareconfiguredaccordingto
theremoteaccesspolicyforthisspecific
controlnetwork.

Thisrequirementintendstoprevent
productioninformationandauthentication
credentialstoleakfromoneCNtoanother
CN(bothofwhichmaybelongtodifferent
companies)viaasharedremoteclientand
itsassociatedstorage.Italsofacilitates
implementationofCNspecificsecurity
policiesandmechanismsandavoidsthe
needtoinstallapplicationsontheremote
clientthatarenotneededforaccesstoa
certainCNandthuscreateanunnecessary
risk.
Note:Therequirementforadedicated
remoteclientmaybefulfilledbyusinga
singlecomputerdeviceandexchangeable
storageunits(e.g.harddisks,aslongasthe
sharedcomputationaldevicewithoutthe
storageunitdoesnotcreateariskfor
informationleakage).

SP99Part4Draft1Edit0320080310Word972003format.doc

Page82

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA13.

Rationale

Item1and2ofthisrequirementintendto
1. Theremoteclientshallnotbe
preventthataproperlyauthenticated
connectedtoanynetworksother
thantheoneusedforremoteaccess. remoteclientcanbeusedbyanattackeras
gatewayintotheCN.Thiscoulde.g.bethe
2. Onthesameconnectingnetwork,
caseiftheremoteaccessclientisatthe
theremoteclientshallnothave
sametimeconnectedtoaCNviadirect
activecommunicationconnections
dialupandtotheInternetviaADSL.Item3
withotherpartnersthanthe
and4supportsindividualaccountabilityfor
remotelyaccessedcontrolnetwork. anaccesslinkandisaprerequisiteforthe
correctworkingofclientsidepolicy
3. Splittunnelingshallnotbe
enforcementtechnologies.
permitted.
4. Thesameremoteaccesslinkshall
notbeusedconcurrentlybymultiple
remoteclients.

IRA14.

Theremoteclientshallbeprotectedbya
firewalland/orapersonalfirewallwhich
rejectsallconnectionattemptsfromthe
connectingnetworkthatarenot
associatedwithongoingremoteaccess
session.

Ifapublicnetworkisusedasconnecting
network,itwouldbepossibleforan
attackeronthisnetworktoattackand
compromisetheremoteclientbeforeor
whileitisinasessionwithaCNandattack
theCNthroughthischannel.

IRA15.

Theremoteclienthostsshallbesecured.

Theremoteclientistheweakestlinkinthe
securityarchitecture.Inordertomakeit
difficultforanattackertosubvertthem,
theyshouldbeconfiguredsothatan
attackerhasthesmallestpossiblesetof
workingpointsforanattack.This
philosophyofconfigurationisalsoknown
ashardeningandcomprisesactionssuch
asremovingunnecessaryuseraccounts,
applications,andservices,settingtight
accesscontrolrulesonresources,and
requiringstrongauthentication
mechanisms,segregationofduties,and
principleofleastprivilegeforauthorized
useraccounts.

2
3
4

IRAdataflowsecurityrequirementsarespecifiedinTable12.Becausetherequirementsarethesameas
theECIdataflowsecurityrequirementsspecifiedinTable17theyarecrossreferencedusing[ECIx]
notation.
SP99Part4Draft1Edit0320080310Word972003format.doc

Page83

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE12IRADATAFLOWSECURI TYREQUIR EMENTS


Requirement Requirementspecification
ID

Rationale

IRA16.
[ECI12]

Allincomingoroutgoingtrafficnot
Inacontrolsysteminterconnectthereis
explicitlypermittedshallbedeniedatthe likelyonlyarathersmallsetofpermitted
traffictypes,sothatdefiningpassrules(i.e.
firewalls.
exceptionstoadenyall)arefasterand
lesserrorpronetoconfigureandmaintain
thandenyrules(i.e.exceptionstoapass
all).

IRA17.
ECI15

Nosingleencryptedconnectionshall
crossbothfirewalls.

Encryptedconnectionscannotbeexamined
bytheIDSorothercontentinspection
mechanismsintheECG,thusalltraffichas
tobeincleartext(exceptcredentials)inthe
SPN.
[MN:Arewesurewewantthis?Notethat
thiswouldalsoprohibitSSLandSSH
connections,notjustIPsec?WhyisIPsec
oftentreateddifferentlyfromSSL/SSH?
Whataboutencryptionintheremote
desktopsharingprotocol?]

IRA18.
ECI16

Firewallsshalldroppacketswith
malformedOSIlayer1to4headers.

Packetswithunusualcombinationsof
headerflagsandoptions,wrongheader
fields,fragmentation,orunusualsizesare
mostlyindicatorsofanattackastheyare
oftenusedtopassfirewallsandescape
detectionbyanIDS.Thereisnoneedto
processsuchpacketsintheproduction
flow.

IRA19.
ECI15

Firewallsshalldroppacketswithspoofed Packetswithspoofedsourceaddressesare,
sourceaddresses.
forinstance,packetsthatcomefromthe
outsidewithaninsidesourceaddress.
Suchpacketscannotoccurduringnormal
operationandareindicatorsofanattackas
theyareoftenusedtopassfirewalls.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page84

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

IRA20.
ECI18

Notrafficshallberoutedthrougha
firewallwithoutbeingsubjectedtoa
filteringaccordingtothefirewallrules.

Firewallsareoftenalsorouters.A
misconfigurationofthefirewall,especially
offirewall2ifitisimplementedona
generalpurposepersonalcomputer,may
routepacketsbetweentheinterfacespast
thefilters.

IRA21.
ECI19

Nonetworkorsecuritydeviceor
Ifmanagementofapplicationsor
applicationmanagementtrafficshallflow networkingandsecuritydevicesinsidethe
intothecontrolnetwork.
CNfromexternalnetworksisallowed,there
isariskthatanattackermaycompromise
andabusethosemanagementfacilities.

IRA22.
ECI20

TrafficflowintotheCNshallberate
limitedonfirewall2.

Thisrequirementpreventsthatmalicious
attacks,malfunctionsormisconfigurationof
applicationsontheremoteclientorSPN
mayinjectlargeamountsoftrafficintothe
CNandcauseadenialofservicethrough
networkfloodingthere.Thelimitrate
shouldbesufficientlylowsothatevenifit
isfullyused,theperformanceoftheCNis
sufficientinalloperativesituations,
includingalarms.

IRA23.

Theremoteclientshallnotbecomeafull
memberofthecontrolnetwork.Instead,
itshallonlyhostamirroreddesktop
includingmouseandkeyboardinput
meansofaremoteaccessworkplacein
thecontrolnetwork.Firewallsonthe
clientandsemiprivatenetworksides
shallbeconfiguredsuchthatonlythe
remotedesktopsharingprotocoland
trafficnecessaryforsessioncontrolcan
pass.Theremoteaccessworkplaceshall
providemeansforonlinemonitoring
andcontroloftheactionsinitiatedonthe
remoteclientbyapersonlocaltothe
controlnetwork.

Thisrequirementintendstopreventthata
compromised,e.g.worminfected,remote
clientcanattackanyotherhostsontheCN
simplybyopeningnetworkconnections.In
ordertosuccessfullyinfiltratetheCN,the
maliciousapplicationontheremoteclient
wouldhavetocorruptthedesktopsharing
clientapplicationinawaythatthedesktop
sharingprotocolcouldbeusedasattack
vector.Also,astheremoteclientcanonly
manipulatetheshareddesktopofthe
remoteaccessworkplace,itsaccess
authorizationsandactualactionscanbe
controlledandmonitoredthereatasingle
location.
[MN:Shallwerequiredoubledesktop
remotingwithanintermediateserver/client
intheSPN?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page85

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA24.

AnECGthatimplementsremoteaccessvia
differentconnectingnetworks,e.g.direct
InternetaccessandaccessfromtheEN,as
wellasanECGthatimplementsprofilesECI
andIRAmayhavedifferentoutside
connectionstoFW1.Inordertopreventan
attackfromspreadingbetweenthese
outsideconnections,theyhavetobe
isolatedfromeachother.

ExternalinterfacesofFW1shallbe
isolatedfromeachother.

Note:Thiscanberealizedeitherthrough
theuseofseparateHWdevicesforFW1(in
Figure2indicatedasFW1a/b/c),orby
connectingthoseoutsideconnecting
networkstoseparatenetworkinterfacesof
thesamefirewalldevice,togetherwith
filterrulesthatpreventanytrafficflow
betweenthoseoutsideconnecting
networks.
IRA25.

Incomingconnectionsintothesemi
privatenetworkshallonlybeaccepted
frompreconfiguredremoteclienthosts
ornetworks.

TheserversintheCNorSPNdonotneedto
offerservicestotheanonymouspublic.The
requiredauthenticationprovidesadditional
protectionagainstscanningandbreakins.
Note:Therestrictiontoallowconnections
onlyfrompreconfiguredclientscouldfor
exampleberealizedusingcaller
identificationand/orfixeddialbackfor
telephonenetworksorfirewallfiltering
withVPNauthentication.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page86

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA26.

Nofilesshallbeuploadedfromthe
remoteclienttothefilesystemofahost
intheCN.

Rationale

TheCNorganizationshallhavefullcontrol
overalldataimportedintotheCNaswell
asthetimingofthisimport.TheCN
organizationisresponsibleforverifying
beforeimportthatthosedataarefreeof
malwareandhavenotbeentamperedwith
ontransit.
Note:Incasetheuploadofcertainfilesis
necessary,theseparatechannelmaybe
usedtotransportthefileformtheremote
clientsitetotheCNsite.AttheCNsite,CN
staffwouldberesponsibleforsubjecting
thisfiletothecontent,authenticityand
integrityverificationproceduresaccording
tothelocalsecuritymanagementsystem
beforeactuallyimportingitintothesystem.

IRA27.

Filedownloadfromthecontrolnetwork
toaremoteclientshallberestricted.The
policytorestrictdownloadsisalocal
matter.

Thisrequirementintendstoprevent
unauthorizeddisclosureofinformationand
disclosureofinformationwithoutcontrol
andknowledgeoftheCNside.
Note:Forcertainremoteaccesspurposes,
e.g.diagnostics,itmightbenecessaryto
downloadcertainfiles.Eitherfinegrained
accesscontrolorcooperationoftheCNside
staffandseparatecommunicationpaths
canbeusedforthispurpose.

IRA28.

InthecontextoftheIRArequirement
set,thereshallbenoincomingor
outgoingconnectionsotherthan
betweenthecontrolnetworkandthe
remoteclient.

Thisrequirementonlyimposes
requirementsontheremoteaccess
connection.Ifthesystemalsoimplements
otherprofilesofthisstandard,additional
connectionsmightbeimplemented,but
theymustbegovernedbyrequirements
fromtheseotherprofiles.Alackof
restrictinginstructioninthisprofilewith
respecttoconnectionsoftheCNto
externalpartnersotherthantheremote
clientshallnotbeinterpretedasa
permission.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page87

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE13IRASECURITYCOMPONENTSECU RITYREQUI REMENTS


Requirement Requirementspecification
ID
IRA29.
ECI22

Managementofsecurityandnetworking
devicesaswellaslogsshallrequire
multifactorauthentication

Rationale

Configurationchangesonswitches,
routers,IDSs,firewalls,VPN
terminators,etccanpreventthe
correctfunctionofthosesecurity
devices.Astheyareparticularlylikely
tobetargetedbyanattackerthey
needtobesecuredparticularly
strongly.Logsarealsoanimportant
securitymechanismagainstinside
attackers,forwhichitmightbeeasier
toacquireweakauthentication
credentials.
[MN:Canthisbetechnicallyrealized?Is
ittoorestrictivewithrespecttosecurity
products/vendorsthatcanimplement
this(singlevendorlockin)?Isit
necessary,consideringweonlyallow
localaccessfromtheSMNanyway?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page88

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA30.

Firewallsshalllogatleastallmanagement
activitiesinanauditableway.Firewall2shall
alsologallrejectedconnections.Logging
shouldbesentviawriteonlyprotocolstoa
centrallogserver.

Rationale

Managementactivities,e.g.creatingof
newusersormodificationoffirewall
rules,areextremelysecuritycritical,as
theycancompromisethefirewall.With
aproperlyconfiguredfirewall1there
shouldbehardlyanyconnections
rejectedatfirewall2.Thusanysuch
eventishighlyindicativeofasecurity
problem.
Logsshouldbesenttocentrallog
serverstofacilitatelogconsolidation
andanalysis,toavoidexhaustionofthe
limitedlogstoragespaceonthe
firewall,andtoavoidthatanattacker
canmodifythelogsafter
compromisingthefirewall.
Note:Thecentrallogservershould
resideintheSMNoritmayresidein
theEN.ItshallnotresideintheCN,as
thiswouldrequiretoopenFW2for
incominglogtraffic.

IRA31.
ECI23

Allsecuritydevicesintheexternal
connectivitygatewayshallbetime
synchronizedwith10ms(TBR)accuracy.

Timesynchronizationofdevicesisa
preconditionforaccuratetimestamps
onlogevents,whichareneededforlog
consolidationandanalysis.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page89

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
IRA32.
ECI24

Atleastfirewall2shouldbeprotectedbya
hostbasedintrusiondetectionsystem.Ifitis
implementedontopofageneralpurpose
operatingsystem,itshallbeprotectedbya
hostbasedintrusiondetectionsystem.

Rationale

Firewall2isthemaindefensive
elementintheECIsecurity
architecture.AHIDSonthishost
monitoringboththefirewall
applicationandconfigurationandthe
operatingsystemfilesprovides
additionalprotectionagainst
compromiseorundetectedincidental
configurationchangesonthishost.
Note:TheHIDSshouldbeofthe
integritycheckingtype,witha
referencedatabaseonamedium
whichcannotbemodifiedfrom
firewall2,e.g.aCDreader.The
integritycheckingHIDScouldbe
augmentedbyadditionalHIDSbased
onotheroperatingprinciples,suchas
monitoringoperatingsystemcalls.
[MN:Canthisbetechnicallyrealized
withpopularfirewallappliances,e.g.
CiscoPIX?Isitagoodideatorequirea
nonappliance,PCbasedfirewallfor
FW2?]

IRA33.
ECI25

Itshouldbepossibletointerrogatethe
firewallsabouttheirstatusfromwithinthe
controlnetwork.

Asaninterrupteddataflowthroughthe
ECGmayhavenegativeinfluenceson
theproductionprocess,thecontrol
systemcouldimplementindicatorsin
thecontrolsystemHMIand/oralarm
managementsubsystemtoalert
operatorstoproblemswiththis
dataflow,causedbyahardwarefailure,
asoftwarefailure,orareactiontoa
detectedattack.

IRA34.

Theremoteclientandassociateddevicesshall Timesynchronizationofdevicesisa
betimesynchronizedwithin10ms(TBR)
preconditionforaccuratetimestamps
accuracytothecontrolnetwork.
onlogevents,whichareneededforlog
consolidationandanalysis.
[MN:Isthisvaluetoorestrictive?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page90

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

IRA35.

Theremoteclientshallrunoneormultiple
virusscannerstodetectvirus,worm,Trojan,
andspywareinfections.Thevirusscanner(s)
shallscancontinuouslyinthebackgroundall
fileaccesses.Signaturefilesandscanengines
ofthevirusscanner(s)shallneverbemore
than24h(TBR)outofdateimmediately
beforeandduringaremoteaccesssession.
Thevirusscanner(s)shallfullyscanallstorage
mediaattachedtotheremoteclientorused
forremoteaccessatleastonceevery24
hours(TBR),afteraruleupdate.

Malwareinfectionsarethemost
commonknownsourceofsevere
networksecurityincidentsinindustrial
systems.

IRA36.

Theremoteclientshallrunafilesystem
integritychecker.Thefilesystemintegrity
checkshallatleastcoveralloperatingsystem
andapplicationbinariesandconfiguration
files.Thecomparisondatabaseshallbe
installedonareadonlymedium.

Thisrequirementintendstodetecta
compromiseoftheremoteclienthost
beforeitcanbeusedbytheattackeras
steppingstoneintotheCN.

Theremoteclientshallonlyhaveapplications
andservicesinstalledandrunningthatare
neededfortheworkthatisintendedtobe
doneviaremoteaccess.Theinstalledand
runningoperatingservices,applicationsand
serviceshavetobeapprovedbythecontrol
networkorganizationalauthority.

Everyapplicationandservicecreates
additionalriskthroughknownor
unknownvulnerabilities,
misconfiguration,misoperation,or
hiddenmaliciousfunctionality,thus
reducingthenumberofinstalledand
runningapplicationsandservices
reducestheriskofdamagestotheCN.

IRA37.

Note:Thereadonlymediummaybea
CD/DVDdrive(notCD/DVDwriter).

Note:Specifically,theremoteclient
shallnothaveemailorinstant
messagingclientsinstalled.Thisclause
allows,inadditiontotheremote
accesscommunicationapplications,
alsodiagnosisandengineering
applicationsthatarepossiblyusedin
thecontextofaremoteaccesssession.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page91

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA38.

Theremoteclientisinmostcases
managedbyadifferentorganization
thantheCN.Thisorganizationmay
havedifferentITsecuritystandards
fromtheorganizationresponsiblefor
theCN.Whileacertainleveloftrust
withintheframeworkofdetailed
contractualagreementsbetweenthe
CNorganizationandtheremoteclient
organizationwillbenecessary,theCN
organizationshalluseallmeans
possibletocontinuouslyverifythe
adherenceoftheremoteclient
organizationtothosecontractual
agreements.

Clientsidepolicyenforcementshallbeused
ontheremoteclient.Theevaluationofthe
securitypostureoftheremoteclienthasto
besuccessfulwithrespecttothepolicy
imposedbythecontrolnetworkbeforeany
productiontrafficfromortoitisallowedon
thecontrolnetworkorsemiprivatenetwork.
Clientsidepolicyenforcementshouldcover
IRA34,IRA35,IRA36,IRA37,IRA13,IRA14,
IRA15,IRA39,IRA50.Clientsidepolicy
enforcementshouldprovideevidenceof
tampering.

Note:Multiplevendorsoffersolutions
forclientsidepolicyenforcementas
partoftheirVPNtoolsuites.
IRA39.

Thecommunicationbetweentheremote
clientandthesemiprivatenetworkshallbe
protectedbyavirtualprivatenetworkwhich
providescryptographicintegrityand
confidentialityprotectionaswellas
authentication.

Thisrequirementpreventsanyparties
ontheconnectingnetworktomodify
orreadthetrafficortomountmanin
themiddleattacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page92

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA40.

Technicalmeansshallensurethataremote
accesssessionshallonlybeestablishedwith
explicitinvolvementofanauthorizedcontrol
networkstaffmember.

Rationale

Technicalmeansshallbeusedto
ensurethatCNsidestaffisawareofall
ongoingremoteaccesssessionsand
cancontrolthetimingofremote
accesssessionsaccordingtothestatus
ofthecontrolsystemandthe
availabilityofstaffresourcesfor
supervision.Also,disablingremote
accessfacilitiesmakesthewindowof
vulnerabilityforanattackersmaller,
evenifhemanagestocompromisethe
remoteclientand/orauthentication
credentials.
Note:Thisrequirementcouldbe
implementedbyelectrically
disconnectingorremovingpowerfrom
themodemorbylockingremote
accessuseraccountswhilenoremote
accesssessionisongoing.

IRA41.

Thestatusofremoteaccessconnectionsshall
beindicatedintheoperatorinterfaceofthe
controlsystem.Statusinformationcontainsat
least:connectedanddisconnected,activeand
inactive(timeofinactivityinminutes),
remoteclientsiteanduseridentifier.

Thisrequirementprovidesan
additionalsafeguardagainstremote
connectionsthatareestablished
withoutconsentfromtheCNsideor
arenotproperlyclosed.

IRA42.

Eachremoteaccesssessionshallbeloggedon
thecontrolnetworksideinawaythatallows
reconstructing/replayingthesessioninfull
detail.Thelogshallalsocontainsourcehost,
useridentifier,starttimeanddate,andend
timeanddate.

Thisrequirementservestodocument
attacksconductedviatheremote
accesslinkandtodeterattacksfrom
insidersusingtheremoteclient.

Usersontheremoteclientshallbe
authenticatedbasedonauserdatabase
(domainauthenticationserver)locatedinside
thecontrolnetwork.

Theuserdatabaseisahighlysensitive
assetthathastobeprotectedandthus
shallbelocatedinthemostsecure
zoneofthenetwork.

IRA43.

[MN:Howcanwesecurethoselogs?
Sendtoacentralserver?Howmuch
detailisneeded?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page93

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE14IRAOPERATIONSSECURI TYREQUIR EMENTS


Requirement Requirementspecification
ID
IRA44.

Securityeventsandalarmsfromfirewalls,
intrusiondetectionsystem,andother
sourcesshallbemonitoredonlinearound
theclocktoenabletimelyresponsetoan
attack.

Rationale

Eventlogsthatnobodylooksatare
worthless.TheIRAsecurityarchitecture
consistsofdefense,detection,and
reaction.Ifanattackerbreaksthroughone
ofthedefensivelayersthishastobe
detectedandreacteduponbeforethe
attackcansuccessfullypenetratetheECG
andentertheCN.
Note:Thewordingofthisrequirement
allowsformonitoringandresponse
solutionsusinghumansaswellasthose
basedonautomatedsystems.

IRA45.

Ifahostinstallationisanidenticalcopyof
anothersystemthenmodificationsshall
bemadeafterinstallationtocreatea
uniqueidentityforthissystem.

Thesocalledcloningisaprocessto
efficientlysetupmultiplesystemswith
identicalcharacteristicsfromasingle
templatesystem.Carehastobetakenthat
duringorafterthiscloningprocessthe
systemspecificparameters,e.g.Windows
SID,arechangedtoauniquevalue
differentfromthevalueofthetemplate
system.Ascertainauthenticationand
accesscontroldecisionsaremadebased
onsystemidentity,theexistenceofa
numberofundistinguishablesystems
underdifferentownershipandcontrol
couldbeabusedforanattack.

IRA46.

Allauthenticationcredentialsonhosts,
devicesandapplicationsshallbechanged
atinstallationtimetoothervaluesthan
thefactorydefaults.

Factorydefaultcredentials(e.g.
passwords)areknowntoallpresentand
formeremployeesofthevendorandall
otherusersofthissystemworldwide.
Factorydefaultcredentialshave
historicallybeenoneofthebiggest
securityweaknessesinallindustrial
systems.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page94

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

IRA47.

Alldevicesandhostsconnectedtothe
semiprotectednetworkshallbe
maintainedwiththelatestpatchesand
ruleupdates.Thereshallbeamaximum
24hours(TBR)delaybetweenthe
availabilityofapatchupdatenotification
anditsimplementation.

Patchingandupdatingrulesisessentialto
protectthesecuritymechanismsagainst
compromiseduetonewvulnerabilitiesand
todetectnewattacks.Asthehostsand
devicesareallofftheshelfand/ornot
productioncritical,updatescanbe
installedwithouthavingtowaitfor
approvalfromthecontrolsystemvendor.
24hoursbetweenupdate/patch
announcementandcompleted
implementationisafeasiblecompromise
betweenanefficientlymanageableIT
maintenanceprocessandtheprotection
reserveobtainedbytwodiversefirewalls
inseries.

IRA48.

Thereshallbenoshareduseraccountson
hosts,devices,andapplicationsthatmake
uptheenterpriseconnectiongateway,
exceptwheretechnicallyunavoidable.All
suchexceptionsshallhaveadocumented
businessjustificationwithriskanalysis
andaresponsibleperson.Forallsuch
casesproceduralortechnicalmeansshall
beimplementedtoensurethatan
individualusercanbeproventobe
accountableforanyactionexecuted
underthesharedaccount.

Ensuringnonrepudiableaccountabilityis
oneofthemostimportantmeasures
againstinsiderattacks.Alsooutside
intrusionsonsharedaccountsareless
likelytobedetected,aslegitimateusers
oftenassumethatchangesthatthey
encountermusthavebeencreatedbyone
oftheotherlegitimateaccountusers.

IRA49.

Userrightsandpermissionsonthehosts,
devices,andapplicationsintheenterprise
connectiongatewayshallbesetaccording
totheprincipleofleastprivilege.Different
usersshallhavetherolesofsystem
administratorandsecurityadministrator.

Therestrictionofeachusersprivilegesto
theminimumnecessaryforhisworklimits
theeffectivenessofanadversarywhohas
compromisedanaccountandreducesthe
dangerofinsiderattacks.Aseparationof
usersintodifferentmutuallycontrolling
rolesalsoreduceslikelihoodofinsider
attacks.
[MN:Wouldabetterseparationbeintoan
administrator(makesnormalandsecurity
changes)andanauditor(canreadand
managelogs,butnotchangeanything)?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page95

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

IRA50.

Theremoteclientandassociateddevices
shallhavethelatestoperatingsystemand
applicationupdatesandpatchesapplied
beforearemoteaccesssessionisstarted.
Duringanongoingremoteaccesssession,
theremoteaccessclientandassociated
devicesshallapplythelatestupdatesand
patchesatleastevery24hours(TBR).

Unpatchedoperatingsystemsand
applicationswithknownvulnerabilitiesare
oneofthemostcommoninroadsof
directedandundirectedattackson
informationsystems.Astheremoteclient
isnotrunninganyproductioncritical
applications,itcanberequiredtokeepthe
remoteclientconstantlyuptodate
withouthavingtowaitforpatch/update
qualificationsfromcontrolsystem
vendors.

IRA51.

Onlyindividualaccounts,noshared
accounts,shallbeusedontheremote
clienthostandforthemanagementof
associateddevices(e.g.firewall,virtual
privatenetworkterminatorontheremote
clientside).

Ensuringnonreputableaccountabilityis
oneofthemostimportantmeasures
againstinsiderattacks.Alsooutside
intrusionsonsharedaccountsareless
likelytobedetected,aslegitimateusers
oftenassumethatchangesthatthey
encountermusthavebeencreatedbyone
oftheotherlegitimateaccountusers.

IRA52.

Onlyindividualaccounts,noshared
accounts,shallbeusedforauthentication
forremoteaccesstothecontrolnetwork.

Ensuringnonreputableaccountabilityis
oneofthemostimportantmeasures
againstinsiderattacks.Alsooutside
intrusionsonsharedaccountsareless
likelytobedetected,aslegitimateusers
oftenassumethatchangesthatthey
encountermusthavebeencreatedbyone
oftheotherlegitimateaccountusers.

IRA53.

Userrightsandpermissionsonthe
remoteclientandassociateddevicesshall
besetaccordingtotheprincipleofleast
privilege.Differentusersshallhavethe
rolesofsystemadministratorandsecurity
administrator.

Therestrictionofeachusersprivilegesto
theminimumnecessaryforhisworklimits
theeffectivenessofanattackerwhohas
compromisedanaccountandreducesthe
dangerofinsiderattacks.Aseparationof
usersintodifferentmutuallycontrolling
rolesalsoreduceslikelihoodofinsider
attacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page96

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

IRA54.

Nocontrolnetworkauthentication
credentialsshallbestoredontheclient
side.

TheCNsideorganizationcannotcontrol
physicalaccesstotheremoteclienthost.
Anattackerwhogainsphysicalaccesstoa
storagedevicecanwithhighlikelihood
retrievedata.Thisrequirementintendsto
reducetheriskofdisclosureofCN
authenticationcredentialsontheremote
clientside.

IRA55.

Physicalaccesstotheremoteclienthost
shallbecontrolledandlimitedto
authorizedstaff.Thestrengthofphysical
accesscontrolshallbeapprovedbythe
authorizedcontrolnetworkorganization
unit.

Thisrequirementintendstoreducetherisk
thatanattackercanduringoraftera
remoteaccesssessionacquireknowledge
fromaremoteclienthostthatwould
facilitateanattack.

IRA56.

twoauthenticationrealmsaretypically
Theauthenticationrealmofthecontrol
undercontrolofdifferentorganizations.
networkshallbeseparatefromthe
authenticationrealmoftheremoteclient,
withoutadirectortransitivetrust
relationshipbetweenthem.

IRA57.

Userrightsandpermissionsonthe
remoteaccessworkplaceandotherparts
ofthecontrolsystemaccessiblethrough
theremoteaccessconnectionshallbeset
accordingtotheprincipleofleast
privilege.Differentusersshallhavethe
rolesofsystemadministratorandsecurity
administrator.

Therestrictionofeachusersprivilegesto
theminimumnecessaryforhisworklimits
theeffectivenessofanattackerwhohas
compromisedanaccountandreducesthe
dangerofinsiderattacks.Aseparationof
usersintodifferentmutuallycontrolling
rolesalsoreduceslikelihoodofinsider
attacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page97

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE15IRASECURITYPO LICYREQU IREMENTS


Requirement Requirementspecification
ID

Rationale

IRA58.

Thereshallbeanexplicit,
documented,andenforcedprocess
formanaginganytemporary
exceptionsfromtheprescriptionsof
thisstandardandpoliciesderived
fromit.Anysuchexceptionsshould
lastonlyfortheminimumtime
necessary.

Theremaybeoperationalreasonstodeviate
fromtheprescriptionsofthisstandard.While
thisisundesirablefromthesecuritypointof
view,itwillhappen.Ifthereisnoprocess
definedaprioritodealwithexceptions,
exceptionswillbehandledinanadhocfashion
leadingtolossofcontroloverthetiming,
duration,andextentoftheexceptionandloss
ofaccountabilityandpersonalresponsibilityfor
anynegativeconsequences.

IRA59.

Thereshallbeclearlydocumented
rulesofwhoisauthorizedtoaccess
whatdataandfunctionalitywithin
thedevices,hosts,andapplications
intheenterpriseconnection
gatewayandwhatpurposethis
accessisused.

Adocumentedaccesscontrolpolicyisthe
prerequisiteforimplementingandauditing
technicalaccesscontrolrulesandprocedures.
SomeofthedataintheECG,especiallylogdata,
maybesubjecttoprivacylawsincertain
legislatures.Inthiscase,detailed,documented
authorizationdecisionsfrommanagementare
necessarytoprovideguidanceandprotection
againstlegalpersecutionforthesystemand
securityadministrationpersonnel.

IRA60.

Thereshallbeclearlydocumented
rulesofwhoisauthorizedtoaccess
whatdataandfunctionalitywithin
thecontrolsystemandcontrol
networkthroughtheremoteaccess
connectionandwhatpurposethis
accesscanbeusedfor.

Adocumentedaccesscontrolpolicyisthe
prerequisiteforimplementingandauditing
technicalaccesscontrolrulesandprocedures.
Clearlydocumentedauthorizationsarealsoa
prerequisiteformakingtheremoteclientside
liablefordamagescausedbyunauthorized
actions.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page98

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
IRA61.
ECI46

Therevocationoftheaccessrights
ofanyuser,includingthoseofthe
remoteclientorganizations,shallbe
implementedwithin24hours(TBR)
fromthemomenttheaccessright
cancellationwasdecided.

Rationale

Usersleavetheorganizationorlosetheiraccess
rightsduetoothercircumstances.Itis
importantthatsuchchangesarequickly
implementedandenforcedbythe
authenticationandaccesscontrolcomponents.
The24hourstimeframe,alsorequiredin
NERC1300,isacompromisebetweentechnical
andadministrativefeasibilityandincurredrisk.
Note:Thiswillrequirethedefinitionof
processesandpotentiallyrequiretoolsupport
onthesideoforganizationsthataccesssites
remotelytoensurethatallpartiesthatmay
terminateanemployeesauthorizationarealso
capabletoinformtheaffectedCNorganizations
timely,butwithoutdivulgingprivacysensitive
employeeinformation.

1
2

ENTERPRISENETWORK/CONTROLNETWORKINTERCONNECTIONSECURITY

3
4
5
6
7
8
9

Fromtheperspectiveoftheprocesscontrolnetwork,thisclausedescribesrequirementsonthesecure
architecture,implementation,andoperationofaninterconnectionbetweenacontrolsystemwithhigh
security,andpotentiallysafetyneeds.Underlyingthesesecurityrequirementsistheassumptionthat
theprocesscontrolnetworkisuntrustedwithrespecttonetworktraffictypesandvolumeaswellas
userintentionsandcapabilities.Theuntrustednetworkcouldbeeitherapublicnetworklikethe
Internet,anextranet,oranenterpriseintranet.Thelattercaseisinpracticethemostfrequently
occurringscenario.

10
11
12
13
14
15

Enterprisenetworkinterconnection(ECN)securityisneededforusagescenarioswhereacontrolsystem
sendsoutreportsandnotifications.Thesereportsincludeproductionstatusandstatuschanges,which
aresenttoreceiversintheenterprisenetworkorsupplychainpartnersconnectedviaInternet.TheECN
alsoreceivesbatched,nonrealtimedatafromclientsintheenterprisenetworkortheInternet,suchas
productionordersandotherproductionrelatedinformation,controlsoftwareupdates,orapplication
updates.

16
17
18
19
20

Whenthecontrolsystemreceivesrequestswithexpectationofmoreorlessimmediatereactionfrom
clientsontheenterprisenetworkortheInternet,specialsecurityrisksareintroduced.Forthisreason,
thesecurityarchitectshouldconsidereithermirroringthenecessarydataoutofthecontrolsystemto
anoutsidecachingserverwhichthenprocessestherequest,ortoruntheclientapplicationinsidethe
controlsystemandaccessitusingtheInteractiveRemoteAccess(IRA).

21
SP99Part4Draft1Edit0320080310Word972003format.doc

Page99

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4
5

ECIsecuritydoesnotaddressusagescenarioswhereacontrolsystemisinteractivelyaccessedfrom
clientsintheenterpriseortheInternet(seeInteractiveremoteaccesssecurity),orisconnectedtoa
fixedbackuporalternatecontrolcenter(seeIntercontrolcentersecurity).Furthermore,ECIsecurity
doesnotaddresssecuritymeasurestakeninsidethecontrolnetworkusingNIDS,HIDS,antivirus
scanning,personalfirewalls(seeFehler!Verweisquellekonntenichtgefundenwerden.).

ECIREFERENCETOPOLOGY

6
7
8
9

Figure3showsanotionalviewoftheECIreferencetopologyusedtovisualizethearrangementof
componentsdiscussedintheECIsecurityrequirementset.Thefigureisnotional,andexample,andis
notanormativespecificationforISA99.00.04.

10

FIGURE3NOTIONALECIREFERENCETOPOLOGY

11

THREATSADDRESSEDBYTHEECIREQUIREMENTS

12
13
14
15
16
17
18
19
20
21
22
23

Thisrequirementsetcontributes,inthesenseofadefenseindepthstrategy,tothemitigationofthe
samethreatsusedtodeveloptheIRArequirementsseeThreatsaddressedbyIRARequirements.
TheonlydifferenceisthecontextoftheECIdomainratherthantheIRAdomain.

AnadversaryintheenterprisenetworkortheconnectedInternetcausesdenialofserviceinthe
controlsystemnetworkorservicesinordertodisturbproductionoperations.
AnadversaryintheenterprisenetworkortheconnectedInternetcompromisespartofthe
controlsystemorabusescontrolsystemcommunicationsinordertogainpartialorfullcontrol
overproductionoperations.
AnadversaryintheenterprisenetworkortheconnectedInternetconductsreconnaissancein
thecontrolsystemnetworktoobtaininformationaboutnetworktopologyandapplications
usedinpreparationforoneoftheotherattacktypes.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page100

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4
5
6

AnadversaryintheenterprisenetworkortheconnectedInternetobtainsauthenticationor
accesscontrolinformationorinjectsfalseinformationintodataflowingintothecontrolsystem
throughlegitimatechannelsinordertodisturbproductionoperations.
Anadversary,whoisaninsiderwithrespecttothesecuritysystem,compromisespartsofthe
securitysystem,forinstancebymodifyingfirewallrulesordisablinglogging,inordertofacilitate
otherattacksonthecontrolsystem.

7
8
9
10
11

ECIsecurityisnotdesignedtomitigatethreatsresultingfromaninsiderwhodisturbsorcontrols
controlsystemoperationsviadenialofserviceattacksorhostcompromises.Nordoesitaddressthreats
resultingfromdenialofserviceattackonthedataflowbetweentheenterprisenetworkandthecontrol
systemnetworkinanydirection.Andlastly,itdoesnotprotectconfidentialinformation,otherthan
authenticationorauthorizationinformation,fromdataflowingoutoforintothecontrolsystem.

12

ASSUMPTIONSUNDERLYINGTHEECIREQUIREMENTS

13
14
15

TheassumptionsunderlyingtheECI requirementsaresimilartotheassumptionsunderlyingtheIRA
requirementsseeAssumptionsunderlyingtheIRArequirements.Again,thedifferenceisexplained
bythecontextoftheproblemdomain.

16

Theenterprisenetworkisconsidereduntrustedanduntrustworthy.

17
18
19
20
21

Rationale:Evenif theenterprisenetworkisitselfbehindoneormultiplefirewallstooutsidepublic
networksandisthusatrustednetworkfromtheperspectiveofenterpriseIToperations,itstillhasa
significantlylarg erandmorediverseuserpopulationthanth eprocesscontrolnetwork.Usersonthe
enterprisenetworkmayengageinactivitieslikereadingemailorbrowsingthewebwhichexposethem
todirectedand undirectedattacksatlevelsofriskthatareu nacceptablefortheprocesscontrolsystem.

22
23

Eachcommunic ationpathbetweenthecontrolnetworkan doutsidenetworksconformstoISA


99.00.04.

24
25
26
27
28
29

Rationale:ISA99.00.04reducestheriskofelectronicattack soncontrolnetworksandequipmentby
prescribingcertainmeasuresandrequirementsthatprovide aseriesofdefensive,detective,and
reactivecontrolsbetweenanadversaryandatarget.Thereq uirementsetsstriveforanequivalentlevel
ofprotectionwheredifferenttypesofcommunicationpathsbetweenanadversaryandatargetexistsin
parallel.Theriskreductiongoalcannotbeachievedifpartsofthecommunicationpathbetweenthe
adversaryandthetargetareshortcircuitedbylesssecuremeansofcommunication.

30
31

Equipmentandfunctionsinthesemiprivatenetworkarenotcriticaltotheoperationofthecontrol
networkandtheassociatedphysicalprocess.

32
33
34
35
36

Rationale:Thesemiprivatenetwork(SPN)isnotunderthefullprotectionofallsecuritymeasuresfor
thecontrolnetwork,andthusmorelikelytobesubvertedbyanadversary.Partoftheprotection
strategyforthecontrolnetworkdependsonthefactthatanattackthatovercomestheoutermost
defensesofthecontrolnetworkisdetectedandcontainedwithinthesemiprivatenetwork,whichmay
resultindestruction,modification,unavailability,ordisclosureofalldataandfunctionswithintheSPN.

37
38

Theavailabilityofdataflowingbetweentheenterprisenetworkandthecontrolnetworkisnotcritical
totheoperationofthecontrolnetworkandtheassociatedphysicalprocess.
SP99Part4Draft1Edit0320080310Word972003format.doc

Page101

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4
5

Theavailabilityandintegrityofthecommunicationpathanddataflowbetweenthecontrolnetworkand
communicationpartnersintheenterprisenetworkcannotbeguaranteed,astheenterprisenetwork
partofthispathisoutsidethescopeofthisstandard.Also,partoftheprotectionstrategyforthe
controlnetworkdependsonthefactthatanattackisstoppedorcontainedbyinterruptingthetraffic
betweenenterprisenetworkandthecontrolnetworkatanypointintheenterpriseconnectiongateway.

Asecuritymanagementsystemisinplace.

7
8
9
10
11
12

Rationale:ECIsecurityrequirementsaddressthetechnicalmechanismsandtheirconfigurations,andto
asmallextentspecificprocesses.Itisnotconcernedwiththedesignandimplementationofageneral
informationsystemsecuritymanagementsystemincludingsecuritypoliciesandadministrativeaswell
asmaintenanceprocessesandprocedures,whichare,ofcourse,allneededtoensurethatthe
mechanismsdescribedinthisprofileoperateasintendedthroughouttheirlifecycle.Thesemattersare
prescribeinParts2and3ofthisseriesseereference[2]and[3].

13

ECISECURITYREQUIREMENTS

14
15
16

ECInetworktopologysecurityrequirementsarespecifiedinTable16.Becausetherequirementsarethe
sameastheIRAnetworksecurityrequirementsspecifiedinTable13theyarecrossreferencedusing
[IRAx]notation.

17

TABLE16ECINETWORKTOPOLOG YSE CURITYREQUIREMENTS


Requirement Requirementspecification
ID

Rationale

ECI1.
[IRA1]

Thisrequirementpreventsthata
subversionofasinglehost,e.g.onthe
operatingsystemornetworkstacklevel,
disablesbothfirewallsatthesametime.
Also,aconfigurationmistakeforthe
firewallrulesetwillnotleavethecontrol
networkcompletelyunprotected.

Thetwofirewallsshallbedeployedon
differenthosts.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page102

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI2.
[IRA2]

Thetwofirewallsshallbediverse.

Rationale

Thisrequirementpreventsthepossibility
thatasinglevulnerabilityinthefunctional
principle,implementation,orconfiguration
ofthefirewallfunctioncanbeexploitedby
anattackertoovercomeallfirewall
protectionprovidedbytheexternal
connectivitygateway(ECG).
Note:Diversityshouldberealizedbyusing
differentfirewallapplicationsrunningon
differentplatforms.Thedifferentfirewall
applicationsmaybepurchasedfromthe
samevendor.Thesamefirewallapplication
ondifferentplatforms,e.g.ageneral
purposePCandadedicatedappliancedoes
notrealizediversity.

ECI3.
[IRA3]

Firewall2shallberealizedasan
enhancedstatefulprotectionfirewall.

Firewall2carriesthemainresponsibility
forcontrollingtrafficaccesstothecontrol
network(CN)andthusshouldusethemost
sophisticatedfilteringfunctionality
available.Performanceislesscriticalthan
forFW1,asnohighvolumetrafficis
expectedfortheproductiontraffic
betweenCNandEN,andmalicioushigh
ratetrafficwillalreadyhavebeenrejected
byFW1.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page103

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI4.
[IRA4]

Firewall1hastofendoffapotentiallyhigh
volumeofunauthorizedtrafficfromthe
ENforwhichafilteringrouterisbetter
suitedthanaproxyfirewall.Asfirewall2
willprovideproxylevelinspectionand
protection,itisjustifiabletoemployas
FW1alowercostfilteringrouter.

Firewall1mayberealizedasafiltering
router.

Note:Manyactualfilteringrouterproducts
onthemarketalreadyprovidesecurity
functionality,e.g.statefulfiltering,that
goesbeyondtheminimumdefinitionofa
filteringrouterinthisstandard.
[MN:Shallwerequireastatefulfirewall
(notenhanced)here?Thereweresome
commentsthatfilteringroutersaretoo
weak.]
ECI5.
[IRA5]

Firewallhostsshallbesecured.

Firewallhostsareessentialelementsofthe
securityarchitecture.Inordertomakeit
difficultforanadversarytosubvertthem,
theyshouldbeconfiguredsothatan
attackerhasthesmallestpossiblesetof
workingpointsforanattack.This
philosophyofconfigurationisalsoknown
ashardeningandcomprisesactionssuch
asremovingunnecessaryuseraccounts,
applications,andservices,settingtight
accesscontrolrulesonresources,and
requiringstrongauthentication
mechanisms,segregationofduties,and
principleofleastprivilegeforauthorized
useraccounts.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page104

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI6.
[IRA6]

Firewallhostsshallrunonlythefirewall
applicationandsupportingapplications.

Rationale

Theriskthatanattackerisableto
compromiseahostincreaseswiththe
numberofapplicationsandserviceson
thathost.
Applicationnote:Supportingapplications
accordingtotheintentofthisclauseare
applicationsthatsupportthesecurityand
accesscontrolpurposeofthefirewall
throughfunctionssuchasVPNtermination,
authentication,logging,intrusion
detection,virusfiltering,orapplication
levelprotocolinspection.Thisclause
prohibitsotherapplications,especially
thosethataresourcesordestinationsof
productiontraffic.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page105

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI7.
[IRA7]

Thisrequirementrequiresthatsecurity
managementtrafficflowsvia
communicationpathsthatareseparate
(outofband)withrespecttoproduction
traffic.Administrationofthesecurityand
networkingdevicessuchasfirewalls,
switches,routers,andintrusiondetection
system(IDS)sensorsmustbefeasibleeven
whenanattackortheresponsetoan
attackhaveinterruptedcommunicationon
thecommunicationpathforproduction
traffic.Also,thisrequirementensuresthat
anattackercannotusethecommunication
pathforproductiontraffictodirectlyattack
theconfigurationinterfacesofthesecurity
mechanisms.

Securitydevicesandotherhostswith
securityfunctionalityshallbe
administratedviachannelsthatareout
ofbandwithrespecttoproduction
traffic.Ifthesecuritymanagement
channelhastobeconnectedtoexternal
networkstheinterconnectionbetween
thesecuritymanagementchanneland
theexternalnetworkhastoconformtoa
profileofthisstandard.Inthiscase,the
correspondingsecuritydevicesmaybe
administratedviathesamesecurity
managementchannel.

Connectionofthesecuritymanagement
networktoexternalnetworksmaybe
necessaryforruleupdatesorrealtime
communicationwithexternalsecurity
serviceproviders.
Note:Applicationnote:Therequiredout
ofbandcommunicationcanberealized
e.g.viaafixedSecurityManagement
Network(SMN)asshowninFigure3,orvia
adhocconnectionsbetweenthesecurity
deviceandtheadministratorhost,aslong
asthisdoesnotopenanydirectorindirect
connectionbetweenthecommunication
pathfortheproductiontrafficandthe
managementinterfaceofthesecurity
devices.TheSMNcouldbebasedon
Ethernetorserialprotocols.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page106

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI8.
[IRA8]

Anetworkbasedintrusiondetection
systemsensor(NIDS)shallbedeployed
onthesemiprotectednetwork(SPN).

Rationale

ItcannotrealisticallybeexpectedthatFW1
willstopallattacks.Asuccessfulsecurity
architecturereliesnotondefensealone,
butalsoondetectionandreaction.TheECI
thereforehastoprovidethecapabilityto
detectattacksthatgetbeyondFW1,andto
initiatecountermeasureswithina
timeframethatmakesithighlyunlikely
thattheattackercaninthemeantimealso
overcomethedefensesprovidedbyFW2.
Note:TheNIDScouldusedeterministic
rulesorstatisticalanomalydetectionor
anycombinationthereofasfunctional
principles,accordingtotheIDSevaluation
philosophyandcapabilityoftheenterprise.
[MN:Whowillberesponsibleforrule
creation,customizationandmaintenance]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page107

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
ECI9.
[IRA9]

Intrusiondetectionsensorsonthesemi
protectednetworkshallhaveno
connectiontotheenterprisenetworkor
controlnetwork,andshallnotbe
addressablefromthesemiprotected
network.

Rationale

ThereisnoneedfortheIDSsensorto
receivedirectedtrafficfromtheSPN.
Makingitsinterfacenotaddressable
reducesitsattacksurfaceanddecreases
thelikelihoodthattheattackercan
compromisetheIDSsensorhost.
Note:Technically,thisrequirementmeans
thatnoIPaddressisassignedtotheNIDS
sensorinterfaceconnectingtotheSPN,a
practicealsoknownasastealth
interface.Theinterfaceisinstead
configuredforpromiscuousmode,which
allowscapturingallpacketsonthe
network,notonlythoseaddressed
specificallytotheinterface.Inorderto
captureandinspectalltrafficontheSPN,
theIDSsensorinterfacehastoseethis
traffic.Thisisnotpossibleinnormal
switchedEthernet.Varioustechnical
solutionsexist,e.g.useofhubs(low
performance),useofspecialswitches
wherealltrafficcanbemirroredtoone
port,ornetworktaps.

ECI10.
[IRA10]

Firewallsshallfailclose(toablocking
state).

Incaseafirewallcannotcontinueto
provideitsaccesscontrolandsupporting
functions,e.g.duetoasoftwarefailure,log
exhaustion,resourceexhaustion,ortraffic
overloaditshalltrytoindicatetheproblem
toasupervisoryinstanceandgointoa
statethatblocksallincomingandoutgoing
productiontraffic.Thisrequirement
preventsthatanattackercandisablethe
protectionprovidedbythefirewallviaa
relativelysimpletypeofattackthatdoes
notsubvertthefirewallitself,e.g.high
volumetrafficortrafficthatcreatesmany
logentries.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page108

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI11.
[IRA11]

Rationale

Enterprisenetwork,controlnetwork,
securitymanagementnetworkandthe
semiprivatenetworkshallbe
implementedonphysicallyseparate
networkingequipment.

Thisrequirementaddressestheuseof
virtualLANs(VLANs)etc,whichrun
logicallyseparatecommunicationnetworks
onthesamemedium.Withtodays
technologyitisrelativelyeasy,e.g.via
flooding,tocompromisethenetwork
separationprovidedbyVLANswitches,
whichwouldpotentiallyremovesecurity
mechanismsfromtheattackpath.

2
3
4

ECIdataflowsecurityrequirementsarespecifiedinTable16.Becausetherequirementsarethesameas
theIRAdataflowsecurityrequirementsspecifiedinTable12theyarecrossreferencedusing[IRAx]
notation.

TABLE17ECIDATAFLOWS ECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ECI12.
[IRA16]

Allincomingoroutgoingtraffic
notexplicitlypermittedshallbe
deniedatthefirewalls.

Inacontrolsysteminterconnectthereislikelyonly
arathersmallsetofpermittedtraffictypes,sothat
definingpassrules(i.e.exceptionstoadenyall)
arefasterandlesserrorpronetoconfigureand
maintainthandenyrules(i.e.exceptionstoa
passall).

ECI13.

Thereshallbeadocumented
businessjustificationwithrisk
analysisandaresponsibleperson
foreachpermittedincomingor
outgoingdataflow.

Thisrequirementpreventsthatflowsthroughthe
firewallarepermittedforwhichnorealbusiness
needexistsand/orforwhichnobodyis
responsibleincaseitisexploitedforanattack.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page109

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI14.

Protocolswhichsendauthenticationcredentialsin
cleartextaresubjecttothethreatofsniffingand
thusingeneralundesirable.Insomesituationsit
maybenecessaryforbusinessreasons,dueto
compatibilityneedswithlegacyapplications,that
anapplicationontheENorCNisaccessedusinga
cleartextcredentialprotocol(e.g.Telnet,FTP).In
thespiritofaworstcaseanalysisonehastoregard
cleartextcredentialsascompromised(knownto
theattacker).

Noprotocolswithcleartext
authenticationshallcrossboth
firewalls.Thecredentialsusedin
cleartextauthenticationprotocols
shallnotbereusedforanyother
authenticationpurposeanywhere
inthesystem.

Obviously,thisprovidesanattackpaththatis
neitherobstructedbytheauthentication
mechanismofthisprotocolorservice,nor,
potentially,byafirewallorothersecurity
mechanism.Therefore,suchaweaklyprotected
communicationpathmustnotopenadirectattack
pathfromtheENintotheCN.Atleastononeof
thetwopartialpathsENSPMorSPNCN
additional,strong,userspecificauthenticationis
required.
Note:Itisacceptabletorunaprotocolwith
cleartextauthenticationinsideaVPNtunnel,ifthis
tunneldoesnotexposethecredentialsonanypart
ofthepathbetweenthesourcehostandthe
destinationhost
ECI15.
IRA17

Nosingleencryptedconnection
shallcrossbothfirewalls.

Encryptedconnectionscannotbeexaminedbythe
IDSorothercontentinspectionmechanismsinthe
ECG,thusalltraffichastobeincleartext(except
credentials)intheSPN.
[MN:Arewesurewewantthis?Notethatthis
wouldalsoprohibitSSLandSSHconnections,not
justIpsec?WhyisIpsecoftentreateddifferently
fromSSL/SSH?]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page110

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

ECI16.
IRA18

Firewallsshalldroppacketswith
malformedOSIlayer1to4
headers.

Packetswithunusualcombinationsofheaderflags
andoptions,wrongheaderfields,fragmentation,
orunusualsizesaremostlyindicatorsofanattack
astheyareoftenusedtopassfirewallsandescape
detectionbyanIDS.Thereisnoneedtoprocess
suchpacketsintheproductionflow.

ECI17.
IRA19

Firewallsshalldroppacketswith
spoofedsourceaddresses.

Packetswithspoofedsourceaddressesare,for
instance,packetsthatcomefromtheoutside
withaninsidesourceaddress.Suchpackets
cannotoccurduringnormaloperationandare
indicatorsofanattackastheyareoftenusedto
passfirewalls.
[MN:Anymorerequirementsonthefirewall.]

ECI18.
IRA20

Notrafficshallberoutedthrough Firewallsareoftenalsorouters.Amisconfiguration
afirewallwithoutbeingsubjected ofthefirewall,especiallyoffirewall2ifitis
implementedonageneralpurposepersonal
toafilteringaccordingtothe
computer,mayroutepacketsbetweenthe
firewallrules.
interfacespastthefilters.

ECI19.
IRA21

Nonetworkorsecuritydeviceor
applicationmanagementtraffic
shallflowintothecontrol
network.

Ifmanagementofapplicationsornetworkingand
securitydevicesinsidetheCNfromexternal
networksisallowed,thereisariskthatanattacker
maycompromiseandabusethosemanagement
facilities.

ECI20.
IRA22

Trafficflowintothecontrol
networkshallberatelimitedon
firewall2.

Thisrequirementpreventsthatmaliciousattacks
ormalfunctionsormisconfigurationofapplications
ontheENorSPNmayinjectlargeamountsof
trafficintotheCNandcauseadenialofservice
throughnetworkfloodingthere.Thelimitrate
shouldbesufficientlylowsothatevenifitisfully
used,theperformanceoftheCNissufficientinall
operativesituations,includingalarms.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page111

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI21.

Managementactivities,e.g.creatingofnewusers
ormodificationoffirewallrules,areextremely
securitycritical,astheycancompromisethe
firewall.Withaproperlyconfiguredfirewall1
thereshouldbehardlyanyconnectionsrejectedat
firewall2.Thusanysucheventishighlyindicative
ofasecurityproblem.

Firewallsshalllogatleastall
managementactivitiesinan
auditableway.Firewall2shallalso
logallrejectedconnections.
Loggingshouldbesentviawrite
onlyprotocolstoacentrallog
server.

Logsshouldbesenttocentrallogserversto
facilitatelogconsolidationandanalysis,toavoid
exhaustionofthelimitedlogstoragespaceonthe
firewall,andtoavoidthatanattackercanmodify
thelogsaftercompromisingthefirewall.
Note:Thecentrallogservershouldresideinthe
SMNoritmayresideintheEN.Itshallnotreside
intheCN,asthiswouldrequiretoopenFW2for
incominglogtraffic.
1

TABLE18ECISECURITYCOM PONENTREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ECI22.
IRA29

Configurationchangesonswitches,routers,IDSs,
firewalls,VPNterminators,etccanpreventthe
correctfunctionofthosesecuritydevices.Asthey
areparticularlylikelytobetargetedbyanattacker
theyneedtobesecuredparticularlystrongly.
Logsarealsoanimportantsecuritymechanism
againstinsideattackers,forwhichitmightbe
easiertoacquireweakauthenticationcredentials.

Managementofsecurityand
networkingdevicesaswellaslogs
shallrequiremultifactor
authentication.

[MN:Canthisbetechnicallyrealized?Isittoo
restrictivewithrespecttosecurity
products/vendorsthatcanimplementthis(single
vendorlockin)?]
ECI23.
IRA31

Allsecuritydevicesinthe
enterpriseconnectivitygateway
shallbetimesynchronizedwith
10ms(TBR)accuracy.

Timesynchronizationofdevicesisaprecondition
foraccuratetimestampsonlogevents,whichare
neededforlogconsolidationandanalysis.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page112

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI24.
IRA32

Atleastfirewall2shouldbe
protectedbyahostbased
intrusiondetectionsystem.Ifitis
implementedontopofageneral
purposeoperatingsystem,itshall
beprotectedbyahostbased
intrusiondetectionsystem.

Rationale

Firewall2isthemaindefensiveelementintheECI
securityarchitecture.AHIDSonthishost
monitoringboththefirewallapplicationand
configurationandtheoperatingsystemfiles
providesadditionalprotectionagainst
compromiseorundetectedincidental
configurationchangesonthishost.
Note:TheHIDSshouldbeoftheintegritychecking
type,withareferencedatabaseonamedium
whichcannotbemodifiedfromfirewall2,e.g.a
CDreader.TheintegritycheckingHIDScouldbe
augmentedbyadditionalHIDSbasedonother
operatingprinciples,suchasmonitoringoperating
systemcalls.
[MN:Canthisbetechnicallyrealizedwithpopular
firewallappliances,e.g.CiscoPIX?Isitagoodidea
torequireanonappliance,PCbasedfirewallfor
FW2?]

ECI25.
IRA33

Itshouldbepossibletointerrogate AsaninterrupteddataflowthroughtheECGmay
thefirewallsabouttheirstatus
havenegativeinfluencesontheproduction
fromwithinthecontrolnetwork.
process,thecontrolsystemcouldimplement
indicatorsinthecontrolsystemHMIand/oralarm
managementsubsystemtoalertoperatorsto
problemswiththisdataflow,causedbya
hardwarefailure,asoftwarefailure,orareaction
toadetectedattack.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page113

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE19ECIOPERATIONSSECURI TYREQUIRE MENTS


Requirement Requirementspecification
ID

Rationale

ECI26.

Alldevicesandhostsconnectedtothe
semiprotectednetworkshallbe
maintainedwiththelatestpatchesand
ruleupdates.Thereshallbeamaximum
24hours(TBR)delaybetweenthe
availabilityofapatchorupdateandits
implementation.

Patchingandupdatingrulesisessentialto
protectthesecuritymechanismsagainst
compromiseduetonewvulnerabilitiesand
todetectnewattacks.Asthehostsand
devicesareallofftheshelfornot
productioncritical,updatescanbe
installedwithouthavingtowaitfor
approvalfromthecontrolsystemvendor.
24hoursbetweenupdateorpatch
announcementandcompleted
implementationisafeasiblecompromise
betweenanefficientlymanageableIT
maintenanceprocessandtheprotection
reserveobtainedbytwodiversefirewalls
inseries.

ECI27.

Alldatathatenteringthecontrolnetwork
shalldosoonlyonrequestfromthe
controlnetwork.

ECI28.

Aproxyservershallbelocatedinthe
semiprotectednetworktoprovidethe
capabilitytoverifythevalidityofthe
requestsandfilteroutanypotentially
dangerouscontent.Inparticularitshall
examinetherequestforworms,viruses,
andothermalware.

Ifitisnecessaryforbusinessreasonsto
allowincomingrequestsforapplications
andusagescenariosthatcannotbe
convertedtoanarchitecturewherethe
necessarydataaremirroredfromtheCN
toacachingserverintheSPN,which
handlestherequests,thenaproxyservice
intheSPNshallhandlethoserequests.

ECI29.

Thisrequirementpreventsattacktypeslike
flooding,scanning,andspreadingofself
replicatingmalware(worms).

Onlyrequestsoriginatingfromtheproxy
serviceinthesemiprotectednetwork
shallbepermittedtoenterthecontrol
network,andresponsesshallonlybe
allowedtotheproxyservice.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page114

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ECI30.

TrafficthroughFirewall1maybeinitiated
byeitherside.

Rationale

TheSPNislesscritical,thusitmaybe
acceptabletoletunsolicitedtrafficfrom
theENpass.
Applicationnote:Thisallowsan
architecturewherethecontrolsystem
placesdatathroughFW2intotheSPNat
regularintervalsorwheneverthedata
changes,andclientsintheENcanrequest
thosedataatanytimethroughFW1.

ECI31.

Securitypatchesandupdatesfordevices
andapplicationsinsidethesemi
protectednetworkshallbepushedfrom
theenterprisenetworksidethroughFW1
andinstalledthereundercontrolfromthe
enterprisenetwork.

ECI32.

Securitypatchesandupdatesfordevices
andapplicationsinsidethesemi
protectednetworkshallbestagedona
hostinthesemiprotectednetwork,but
shallbepulledbythecontrolnetworkand
installedoncontrolnetworkdevicesand
hostsonlyundercontrolofthecontrol
network.

ECI33.

Patchesandupdatesfordevicesandhosts
inthecontrolnetworkshallbeapproved
forinstallationbytherelevantcontrol
systemequipmentvendorbeforetheyare
installed.

ForthesecurityrelateddevicesintheSPN
speedofpatchingandupdatingisof
highestimportance,soitmaybeadvisable
tointegratethemintocorresponding
workflowsintheEN.FortheCNintegrity
andavailabilityareofthehighest
importance,thusnoupdatesshallbe
imposedfromtheENwithoutCNside
controlwithrespecttodataimportand
installationtimingandtargets.

Updates,e.g.totheoperatingsystem,may
havesideeffectsonthecorrectoperation,
availability,andintegrity,ofthecontrol
systemrunningonthishost,thusupdates
shallonlybeinstalledaftertheyhavebeen
testedandapprovedbythecontrolsystem
vendor.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page115

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI34.

Thisrequirementmakesitclearthat
controlovertheinstallationprocessiswith
theproductionoperationspersonnel,not
corporateIT.Itfurtherpostulatesthatthe
datadownloadedasupdatesorpatches
havetobeexaminedtoensurethatthey
areunchangedcomparedtotheversions
approvedbythevendorandcorporateIT.

Patchesandupdatesfordevicesandhosts
inthecontrolnetworkshallbevalidated
bycontrolsystemoperationspersonnel
taskedwithITdutiesandshouldbetested
onanofflinesystembeforebeingapplied
totheonlinesystem.

Astheactualcontrolsystemmaybe
differentfromthegenericenvironment
usedbythevendorforqualificationtesting
itisstronglyrecommendedtotestthem
againinanenvironmentthatclosely
mirrorstheproductionsystem,e.g.a
backup,development,ortrainingsystem.
Thisrequirementrecognizesthatsucha
localtestenvironmentmaynotbe
availableatallsites.
ECI35.

Securityeventsandalarmsfromfirewalls,
intrusiondetectionsystems,andother
sourcesshallbemonitoredonlinearound
theclocktoenabletimelyresponsetoan
attack.

Eventlogsthatnobodylooksatare
worthless.TheECIsecurityarchitecture
consistsofdefense,detection,and
reaction.Ifanattackerbreaksthroughone
ofthedefensivelayersthishastobe
detectedandreacteduponbeforethe
attackcansuccessfullypenetratetheECG
andentertheCN.
Note:Thewordingofthisrequirement
allowsformonitoringandresponse
solutionsusinghumansaswellasthose
basedonautomatedsystems.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page116

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

ECI36.

Thereshallbenoshareduseraccountson
hosts,devices,andapplicationsthatmake
uptheenterprisecontrolgateway,except
wheretechnicallyunavoidable.Allsuch
exceptionsshallhaveadocumented
businessjustificationwithriskanalysis
andaresponsibleperson.Forallsuch
casesproceduralortechnicalmeanshave
tobeimplementedtoensurethatan
individualusercanbeproventobe
accountableforanyactionexecuted
underthesharedaccount.

Ensuringnonreputableaccountabilityis
oneofthemostimportantmeasures
againstinsiderattacks.Alsooutside
intrusionsonsharedaccountsareless
likelytobedetected,aslegitimateusers
oftenassumethatchangesthatthey
encountermusthavebeencreatedbyone
oftheotherlegitimateaccountusers.

ECI37.

Outgoingconnectionsfromthecontrol
networktotheenterprisenetworkshould
passthroughaproxyserverinthesemi
protectednetwork.

ThispreventsthatsomebodyintheENcan
directlyobservethetrafficandprotocol
characteristicsofhostsintheCN,which
mightallowtopologymappingand
applicationoroperatingsystem
identification.Thisrequirementalsoallows
toscreentheincomingandoutgoing
communicationcontentontheproxy.
[MN:Shouldthisbestatedherealone,or
withareferencetoadata
exchange/proxyserverinDMZprofile,or
completelymovedtothatprofile?]

ECI38.

Outgoingconnectionsfromthecontrol
networkshallonlybepossibleto
preconfigured,trustedservers.No
enterprisenetworkbaseddirectory
servicesshallbeinvolvedinlocatingthe
destinationservers.

Thereisahigherriskofsuccessfulmalware
injectionsormaninthemiddleattacksif
thedestinationsofconnectionsfromthe
CNaredetermineddynamically(e.g.using
DNS)orthroughuserinteraction.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page117

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID

Rationale

ECI39.

TheserversintheCNorSPNdonotneed
toofferservicestotheanonymouspublic.
Therequiredauthenticationprovides
additionalprotectionagainstscanningand
breakins.

Incomingconnectionsfromtheenterprise
networkintothesemiprotectednetwork
shallonlybeacceptedfrompreconfigured
hostsorusers.

Applicationnote:Thisrequirementcould
berealizedviahostoruserauthentication
inherentinaVPNprotocolorviatheIEEE
802.1xprotocol.
[MN:Isauthenticatedequivalentto
preconfigured?]
ECI40.

Theauthenticationrealmofthecontrol
networkshallbeseparatefromthe
authenticationrealmoftheenterprise
network,withoutadirectortransitive
trustrelationshipbetweenthem.

IftheCNreliesonanauthentication
service(WindowsActiveDirectory,
Kerberos,etc)intheEN,thenCNsecurity
dependsonthesecurityofthis
authenticationservice,whichisnotunder
controloftheCN.IftheENreliesonan
authenticationserviceintheCNthen
unsolicitedtraffic(authentication
requests)fromtheENwillhavetobe
allowedintotheCN.

ECI41.

Theauthenticationrealmofthesemi
protectednetworkmaybeintegrated
withtheauthenticationrealmsofeither
enterprisenetworkorcontrolnetwork.

Thebasicrationaleforseparationisthe
sameasabove,butthisclauserecognizes
thatforsimpleSPNsandlowcost
applicationscenariositmightbedesirable
toconnecttheSPNtoeitherCNorEN,but
neverboth.

ECI42.

Allauthenticationcredentialsonhosts,
devices,andapplicationsintheenterprise
connectivitygatewayshallbechangedat
installationtimetoothervaluesthanthe
factorydefaults.

Factorydefaultcredentials(e.g.
passwords)areknowntoallpresentand
formeremployeesofthevendorandall
otherusersofthissystemworldwide.
Factorydefaultcredentialsareoneofthe
biggestsecurityweaknessesinallindustrial
systemsdeployedtoday.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page118

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID

Rationale

ECI43.

Ifahostinstallationisanidenticalcopyof
anothersystemthenmodificationsshall
bemadeafterinstallationtocreatea
uniqueidentityforthissystem.

Thesocalledcloningisaprocessto
efficientlysetupmultiplesystemswith
identicalcharacteristicsfromasingle
templatesystem.Carehastobetakenthat
duringorafterthiscloningprocessthe
systemspecificparameters,e.g.Windows
SID,arechangedtoauniquevalue
differentfromthevalueofthetemplate
system.Ascertainauthenticationand
accesscontroldecisionsaremadebased
onsystemidentity,theexistenceofa
numberofundistinguishablesystems
underdifferentownershipandcontrol
couldbeabusedforanattack.

ECI44.

Userrightsandpermissionsonthehosts,
devices,andapplicationsintheenterprise
connectivitygatewayshallbeset
accordingtotheprincipleofleast
privilege.Differentusersshallhavethe
rolesofsystemadministratorandsecurity
administrator.

Therestrictionofeachusersprivilegesto
theminimumnecessaryforhisworklimits
theeffectivenessofanattackerwhohas
compromisedanaccountandreducesthe
dangerofinsiderattacks.Aseparationof
usersintodifferentmutuallycontrolling
rolesalsoreduceslikelihoodofinsider
attacks.
[MN:Wouldabetterseparationbeintoan
administrator(makesnormalandsecurity
changes)andanauditor(canreadand
managelogs,butnotchangeanything)?]
[MN:Idecidedtodroptherequirement
essentialfunctionsofthefirewallsshould
beinhardwareornonreprogrammable
softwarefromthisdraft,becauseitisthe
onlyonethatisnotrealizablewith
currentlycommerciallyavailable
technology.]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page119

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

2
3
4
5
6
7
8

TABLE20ECISECURITYPOLICYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ECI45.

Thereshallbeclearlydocumented
rulesofwhoisauthorizedtoaccess
whatdataandfunctionalitywithin
thedevices,hosts,andapplicationsin
theenterpriseconnectivitygateway
andwhatpurposethisaccesscanbe
usedfor.

Adocumentedaccesscontrolpolicyisthe
prerequisiteforimplementingandauditing
technicalaccesscontrolrulesandprocedures.
SomeofthedataintheECG,especiallylog
data,maybesubjecttoprivacylawsincertain
legislatures.Inthiscase,detailed,documented
authorizationdecisionsfrommanagementare
necessarytoprovideguidanceandprotection
againstlegalpersecutionforthesystemand
securityadministrationpersonnel.

ECI46.
IRA61

Therevocationoftheaccessrightsof
anyuser,shallbeimplemented
within24hours(TBR)fromthe
momenttheaccessrightcancellation
wasdecided.

Usersareleavingtheorganizationorlosetheir
accessrightsduetoothercircumstances.Itis
importantthatsuchchangesarequickly
implementedandenforcedbythe
authenticationandaccesscontrolcomponents.
The24hourstimeframe,alsorequiredinNERC
CIP002009,isacompromisebetween
technicalandadministrativefeasibilityand
incurredrisk.

ECI47.

Thereshallbeanexplicit,
Theremaybeoperationalreasonstodeviate
documented,andenforcedprocess
fromtheprescriptionsofthisstandard.While
thisisundesirablefromthesecuritypointof
formanaginganytemporary
exceptionsfromtheprescriptionsof view,itwillhappen.Ifthereisnoprocess
definedaprioritodealwithexceptions,
thisstandardandpoliciesderived
fromit.Anysuchexceptionsshalllast exceptionswillbehandledinanadhocfashion
onlyfortheminimumtime
leadingtolossofcontroloverthetiming,
(TBR)necessary.
duration,andextentoftheexceptionandloss
ofaccountabilityandpersonalresponsibilityfor
anynegativeconsequences.

INTERCONTROLCENTERSECURITY
Intercontrolcenter(ICC)securityrequirementsareneedtoensurethesecurityandsafetyofdispersed
byconnectedcontrolcenters.Theusecasesincludeoutsourcedoperationrelatedtopartnershipsand
cooperativeenterprises,collaborativeoperationsneedtoassistinplantoperationorremotecontrol,
businesscontinuitytorespondtodisasters,anddistributedplant(orcompanies)operationthatcross
nationalboundaries.Thecontrolcentersandcontrolsystemsareconnectedbyusingwidearea

SP99Part4Draft1Edit0320080310Word972003format.doc

Page120

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

networkssuchasthepublicinternet,dedicatedleasedlines,orcompanyownedlinescrossingthe
physicalperimeteroftheenterprise.

3
4
5
6

AlthoughtheICCrequirementsethasmanyoverlapswiththeIRAandECIrequirementsets,thereare
somedifferences.ECIdifferencesare:ICCsitesdonthavetobelongtothesamecompany,andthe
approachassumesthatbothconnectedsystemshavethesamesystemlevelsecurityassurance.
DifferencesbetweentheICCandIRAaremorepronounced:

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

IngeneralIRAhasasinglehostfortheremotepartner,whichrequireslowcostclientsecurity
solutions.
IRApartnersareusuallyconnectedtemporarilytothecontrolsystem,whichrequiresstrong
connectionauthentication.
IRApartnershavemanyotherpartners,whichincreasestheriskofmalware,virusandTrojan
infections.
Multiplepartnershipsusingthesameaccessschemerequiresstrongroleanduserbased
authenticationforaccessandusecontrol.
ForICCsystems,thecontrolcenterserverandoperatorworkstationsonbothsidesmustbe
secure,somorecostlysecuritymeasuresarejustified.
ICCsystemsoperateona24/7basisusingpermanentconnection,soconnectionauthentication
overheadisnotanissue.
HighbandwidthisthenormforICCsystemsbecauserawdataforthewholeplantmayneedto
bestreamedtoandfromthecontrolservers,historiansandapplications.
AlthoughICCincludespartnerships,thegroupisusuallysmallandwellknownsothatsecurity
configurationscanbeenforced.

ICCREFERENCETOPOLOGY

24
25
26
27

Figure4showsanotionalviewoftheICCreferencetopologyusedtovisualizethearrangementof
componentsdiscussedintheICCsecurityrequirementset.Thefigureisnotional,andexample,andis
notanormativespecificationforISA99.00.04.ThedashedboxinFigure4representsthescopeofthe
ICCrequirementset.

28
29

ThesecuritygatewaysshowinFigure4shouldbeplacedattheinnersideoftheencryptionentityin
ordertointerpretthedatatransmissionbetweenthetwosites.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page121

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

FIGURE 4NOTIONALINTERCONTROLCENTERNETWORKTOP OLOGY

SP99Part4Draft1Edit0320080310Word972003format.doc

Page122

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ASSUMPTIONSUNDERLYINGTHEICCRQUIREMENTS

2
3

TheassumptionsunderlyingtheICCrequirementsaresimilartotheassumptionsunderlyingtheIRAand
ECIrequirements.Again,thedifferenceisexplainedbythecontextoftheproblemdomain.

4
5

Whenoperationofaplantfromaremotecontrolcenterbecomeimpossible,aplancanbeoperated
ataminimallevelfromalocalcontrolcenter.

6
7
8
9
10

Rationale:Whentheremoteoperationcannotbedonebydetectingasecurityincident,andfailinga
relaynetwork,thestaffinthelocalcontrolcentermustbeabletooperatetheplantsafely.Althoughthe
availabilityofthecommunicationchannelbetweenbothcentersisanimportantissue,itisnotpossible
toincreasesecurityinasimplewaybyestablishingredundantcommunicationpaths.Anunwantedside
effectofthiscouldbeanenlargementoftheattacksurface.

11
12
13

Betweentheorganizationsoperatingthelocalplant,thelocalcontrolcenter,andtheremotecontrol
centerasecurityservicelevelagreementhasbeensetupthatdefinesclearlytheresponsibilitiesof
eachpartyandtheconsequencesofviolationsofthisagreement.

14
15
16

Rationale:Whentrustbreakdownisdetected,networkconnectionbetweenremoteandlocalControl
centershouldbedisconnecteduntilthetrustisrestored.Thelocalcontrolcentershouldoperatethe
plantsafely.Inordertoconfirmthetrustrestoration,asecurityauditshouldbeperformed.

17
18
19

Allnetworksoutsidethecontrolnetworksofthetwo(ormore)controlcenters,inparticularthe
underlyingtechnology,theinvolvedthirdpartiesforprovidingcommunicationbetweentheremote
andthelocalcontrolcenter,areuntrusted.

20
21

Rationale:Thereshouldbenomoretrustedpartiesthannecessaryinanysystemtoreducetherisk.For
example,withmodernVPNtechnology,itisunnecessarytotrustthecarrier.

22
23

Theavailabilityofatleastonecontrolcenterandthedataflowtoandfromtheplantarenotcritical
forthesafetyofthelocalcontrolnetworkandtheassociatedphysicalprocess.

24

Rationale:Neededtoensureavailability.

25
26

Loginformationistransmittedviasecurechannel,whichisoutofbandoftheoperation
communicationchannel.

27
28
29

Rationale:It is assumed that log information traffic flows via a communication path that is separated (outof-band) with respect to operation traffic. Even when an attack interrupts the communication path for
operation, log information is transmitted to the log server.

30
31

ICCSECURITYREQUIREMENTS
ICCnetworktopologysecurityrequirementsarespecifiedinTable21.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page123

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE21ICCNETWORKTOPOLOGYSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ICC1.

This r equirement prevents any parties


on the connecting network to modify or
read the traffic or to mount man-in-themiddle attacks.

ICC2.

Thecommunicationbetweenthelocal
andtheremotecontrolcentershallbe
protectedbyanencryptedchannelwhich
providescryptographicauthentication,
integrity,confidentialityandnon
repudiation.Thisencryptionwillbe
providedbytheVPNTerminatorsAandB
inFigure4.
Theencryptionmethodofthischannel
(ICC1)shallbestrongenoughtooutlive
themaximumtimebetweenmaintenance
withoutbeinghacked.

NOTE Thetechnicalrealizationcouldbe
anestablishedVPNchannel

Normally,ICCusecasesgoalongwitha
continuousdatatransmissionbetween
bothsitesathighdatatransferrate.This
offerspotentialattackersmuchraw
materialforgleaningthekeydataofthe
encryption
Note1:Todayencryptionmethodslike
3DES,AESorRSAareconsideredtofulfil
thisrequirement.ThelegacymethodDES
isconsideredtobehackedwithinseveral
minutesbyusingstateoftheart
technologyandspendingreasonableeffort
(<250k$)
Note2:Thisrequirementisstrongly
coupledwithICC14.Themoreistheneed
forsecurityandtheweakerthekeydatais,
themoreoftenthekeydatahavetobeen
changed.

ICC3.

Thereshallbeakeybasedauthentication
methodbetweentheVPNTerminators.
Thekeysforencryptionshallbebasedon
certificates.

Addressbasedauthenticationcanbe
spoofed.Presharedkeysorpasswordkeys
areconsideredaseasiertobehacked,
becauseoftheregularityintheir
composition.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page124

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ICC4.

ICC5.

Rationale

Thekeyexchangeshallbedoneinaway,
thatthereisnocleartexttransmissionof
thekeydataoverthecommunicationline
betweenbothsites.

Evenifthekeyexchangetakesaveryshort
time,thekeyscouldbesniffedjustinthat
time.

Accessfromtheremoteoperationcenter,
accessviolationdetectedwithfirewall,
andanunauthorizedaccessdetectedwith
anintrusiondetectionsystemshallrecord
andlogatleast,butnotlimitedtothe
followingdata.

Whenasecurityincidentoccurs,thelog
recordcanbeusedasatrackingofan
intruderandanevidenceofintrusion.
Especially,whentheplantoperationis
outsourcedtorelatedcompaniesand
cooperationcompanies,thelogis
importantasanobjectiveevidenceto
clarifytheresponsibilitywhentheaccident
occurs.

Urgency(e.g.Emergency,Alert,
Warning)

Contentofdetectedevent(e.g.,
Authenticationerror,Access
violation..)

Time

Informationofsource(e.g.,IP
address,Hostname..)

Informationofdestination(e.g.,IP
address,Hostname,URL..)

Kindofcommunicationservice(e.g.,
Servicename,Portnumber,
Protocol..)

Note:TechnicalrealizationcouldbeanIKE
procedurebasedontheDiffieHellman
algorithm.

[Needtospecifylevelofdetail]

SP99Part4Draft1Edit0320080310Word972003format.doc

Page125

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

TABLE22ICCDATAFLOWSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ICC6.

Incomingconnectionpermittedbyfirewall
shouldbelimitedtoonlythereverseproxy
serverfromtheHMIclientatthe
beforehanddefinedremotecontrolcenter
orthenetwork.

Thechancesthattheattackercan
intrudethecontrolsysteminfirewallare
decreasedbecauseonlythedataflowof
theminimumrequirementwithFirewall
ispermitted.

ICC7.

Thesecurityandcommunicationequipment
(e.g.,firewallsandVPNterminators)used
forICCcommunicationshallnotbeusedfor
nonICCdataflows.

Prevent split tunnelling and resulting


FW confusion. Allow for simple and clear
access control rules.

TABLE23ICCOPERATIONSSECUR ITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ICC8.

Ifalocalcontrolcenterbelongtoa
separateorganizationwiththeremote
controlcenter,authenticationdomain
shouldbeseparated.

Thesetwoauthenticationrealmsare
typicallyundercontrolofdifferent
organizations.

ICC9.

Onlyindividualaccounts,noshared
accounts,shallbeusedfor
authenticationintohostsandsystemsat
theremotecontrolcenterthatare
directlyorindirectlyusedtoaccessthe
localcontrolcenterorthecontrol
network.

Ensuringnonreputableaccountabilityis
oneofthemostimportantmeasures
againstinsiderattacks.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page126

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ICC10.

Rationale

Asecurityincidentorweaknessdetected Whenasecurityincidentisdetectedbythe
bythesecuritydeviceshallbenotifiedto securitydevice,aswellasitshouldbe
thedesignatedsecurityauthority.
notifiedtotheSecurityManagement
Server,itisnecessarytobenotifiedwithout
delaytothesecuritymanagerofsiteusing
mailandthepopupwindow,etc..Whenan
incidentisnotified,thesecuritymanager
performsthemagnificationpreventionplan
ofdamage,researchofaffectedlevel,and
maintenanceoftheevidenceaccordingto
theestablishedprocedurebeforehand.
Note:Itisimportanttopreparethe
processingprocedureattheincident
occurrencebetweentheconnected
organizationsbeforehand.Detailsarenot
describedinthisrequirementset.

ICC11.

Incaseofsecurityincident,a
contingencyplanshallbepreparedin
accordancewithlocallawsand
regulations.Itshallincludeasa
minimumtheresponsibilityand
proceduresforinvestigationofthe
securityincident,continuityofplant
operationsandrecoveryorrestoration
oftheprocesscontrolsystem.

Whenasecurityincidentoccurred,itisvery
importanttominimizethedamageandto
continueplantoperation.Theresponsibility
andprocedurestonecessaryactivities
shouldbedefinedclearly.

ICC12.

Toeachsystem,securityauditshallbe
performedperiodicallyandthesecurity
policycomplianceshallbeconfirmedin
accordancewithlocallawsand
regulations.

ICC13.

Inordertodetectlossoftrustbetween
periodicaudits,systemaccessanduse
areshallbecheckedperiodicallyin
accordancewithcompanypolicyand
procedures.Theperiodofcheckingshall
beshorterthanperiodicalaudit.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page127

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Requirement Requirementspecification
ID
ICC14.

Theencryptionkeysshallbechanged
periodically.Thetimebetweenthose
chancesmustbebalancedbetween
securityrequirementsanddisturbanceof
thecommunicationchannelbetween
bothsides.

Rationale

Normally,ICCusecasesgoalongwitha
continuousdatatransmissionbetweenboth
sitesathighdatatransferrate.Thisoffers
potentialattackersmuchrawmaterialfor
gleaningthekeydataoftheencryption.This
riskwillbeminimizedbychangingthe
encryptionkeysperiodically.
Note1:Thetimeforestablishinganew
encryptionkeyisusuallyintherangeof
milliseconds.
Note2:Themoreistheneedforsecurity
andtheweakerthekeydatais,themore
oftenthekeydatahavetobeenchanged.

ICC15.

Theclocksforthetimestampson
securitydevicesshouldbesynchronized.

ICC16.

Theclocksofremotecontrolcenterand
localcontrolcentershouldbe
synchronized.

Theeventtimestampsareimportant
informationbecausethelogfileisusedasa
trackingandanevidenceofthesecurity
incident.

TABLE24ICCPOLICYSECURITYREQUIREMENTS
Requirement Requirementspecification
ID

Rationale

ICC17.

Adocumentedaccesscontrolpolicyisthe
prerequisiteforimplementingandauditing
technicalaccesscontrolrulesand
procedures.Detailed,documented
authorizationdecisionsfrommanagement
arenecessarytoprovideguidanceforthe
systemandsecurityadministration
personnel.

Insupportofenterprisesecuritypolicy,
thereshallbeclearlydocumentedrulesof
whoisauthorizedtoaccesswhatdataand
functionalityacrosstheintercontrol
centerlink,andforwhatpurposethis
accesscanbeused.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page128

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

Requirement Requirementspecification
ID
ICC18.

ICC19.

Rationale

Incasethelocalandremotecontrol
centersarelocatedindifferent
jurisdictions,itshallbedocumentedand
ensuredthatpoliciesandproceduresfor
theremotecontrolcentercomplywith
relevantlawsandregulationsatboththe
remoteandthelocallocationaswellas
anyrelevantintermediatelocations.

Thisrequirementstrivestoavoidliability
claimsarisingfromdifferencesinlocal
regulationsandlaws.Thisrequirement
relates,amongothers,toprivacy
protection,ITsecurity,andplantsafety
regulations.

Nocontrolnetworkauthentication
credentialsshallbestoredontheremote
controlcenterside.

TheCNsideorganizationcannotcontrol
physicalaccesstotheremotecontrol
centerhost.Anattackerwhogainsphysical
accesstoastoragedevicecanwithhigh
likelihoodretrievedata.Thisrequirement
intendstoreducetheriskofdisclosureof
theCNauthenticationcredentialsonthe
remotecontrolcenterside.

Note::Ifthetwoormorecontrolcenters
involvedareallusedasremotebackupto
eachother,thisrequirementappliesmulti
laterally.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page129

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ANNEXA:BIBLIOGRAPHY

2
3

Anderson,D.F."PreliminarySystemDynamicsMapsoftheInsiderCyberthreatProblem."Proceedings
ofthe22ndInternationalConferenceoftheSystemsDynamicsSociety,2004.

4
5

ANSIX9.69.FrameworkforKeyManagementExtensions,AmericanNationalStandardsforFinancial
Services.Standard,ANSI,1998.

CarasikHemmi,Anne.BestDamnFirewallBookPeriod.SyngressPublishing,Inc,2003.

7
8
9

Drimer,Saar,StevenJ.Murdoch,andRossAnderson.Thinkinginsidethebox:systemlevelfailuresof
tamperproofing.TechnicalReport,ComputerLaboratory,Cambridge,UK:UniversityofCambridge,
February2008.

10

Fenrich,Kim;."Securiingyourcontrolsystem."PowerEngineering,February2008:4451.

11
12

GRIDConsortium.ICTVulnerabilitiesofPowerSystems:AroadmapforFutureResearch.EuropeanUnion
JointResearchCenter,December2007.

13
14

Herzog,Pete.OpenSourceSecurityTestingMethodologyManual.Manual,InstituteforSecurityand
OpenMethodologies,February25,2008.

15
16

IEC62443.SECURITYFORINDUSTRIALPROCESSMEASUREMENTANDCONTROLNetworkandsystem
security.PublicAvailableSpecification,InternationalElectrotechnicalCommission,2008.

17

IEEE.SecurityConsiderationsforIPFragmentFiltering.RFC1858,IEEE,1995.

18
19

Jurjens,Jan.SecureSystemsDevelopmentwithUML.ISBN3540007016.BerlinHeidelberg,NewYork:
SpringerVerlag,2005.

20
21

MartinezMoyano,IgnacioJ."TowardaGenericModelofSecurityinanOrganizationalContext."
Proceedignsofthe41stHawaiiConferenceonSsytemSciences,2008.

22

Morrison,Foster.TheArtofModelingDynamicSystems.MultisciencePress,Inc.,1991.

23

NISTFIPS1402."FIPSPUB1402SecurityRequirementsforCryptographicModules."Standard,2001.

24

NISTSP80053."RecommendedSecurityControlsforFederalInformationSystems."SpecialPublication.

25
26

Pejahan,Peymani,andMattKolon.JUNOSRouterSecurity,Bestcommonpracticesforhardeningthe
infrastructure.JuniperNetworks.

27

Pick,JamesB."GEOBusiness."Chap.Chapter11inGEOBusiness.JohnWiley&Sons,2007.

28
29

Piscitello,DavidM,andALymanChapin.OpenSystemsNetworking;TCP/IPandOSI.AddisonWesley
PublishingCompany,1993.

30

Powell,Gary."Designingforsecuritywhysoftwareisn'tenough."InformationQuarterly,2006.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page130

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

Singer,BryonL,andNateKube."SecurityAssuranceLevels:ASILApproachtoSecurity."December17,
2007.

3
4

Sterman,JD."BusinessDynamics:SystemsThinkingandModelingforaComplexWorld(FirstEd.)."
Chapter5.Boston,MA:IrwinMcGrawHill,2000.

5
6

Stevens,Richard.TCP/IPIllustrated,Volume1:TheProtocols.Vol.1.AddisonWesleyLongman,Inc,
1994.

Torgerson,MarkD."SecurityMetricsforCommunicationSystems."12thICCRTS.

USDepartmentofEnergy."RoadmaptoSecureControlSystemsintheEnergySector."January2006.

9
10

USDepartmentofHomelandSecurity."CatalogofControlSystemSecurity:Recommendationsfor
StandardsDevelopers."Report,January2008.

11

12

13

14

SP99Part4Draft1Edit0320080310Word972003format.doc

Page131

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ANNEXB:SYSTEMDYNAMICSMANA GINGCOMPLEXITY

3
4
5
6
7
8
9
10
11
12

ISA99definessecurityassuranceasthelevelcorrespondingtotherequiredeffectivenessof
countermeasurestothwartcyberattacksagainstindustrialautomationsystems.ISAintendstoprovide
ascaleofsecurityassurancelevelswhichassetownerscanusetoestablishaminimumsetof
requirements.Eachsetisdesignedtoprotectselectedzonesorconduitsagainstaccesstoanduseof
devices,systemsanddata.Soundsgood,butthecomplexitiesofthisapproachareexposedwhenthe
mathematicsoftheproposedmodelarewellunderstood 7 .Inthisinformativeannexanotional
time/eventmodelisusedtodescribethetemporalcharacteristicsofsecurityassuranceandtheneedto
accountfortimedynamicsandeventdynamics.Becauseofthecomplexities,thecommonapproachis
toimplementdefenseindepthmechanisms.Usingasystemsdynamicsmodel,thispapershowswhy
suchmechanismsmaymakemattersworsebysignificantlydegradingthesecurityassurancelevel.

13

THECYBERSPACEPROBLEMDOMA I N

14
15
16
17
18
19

Beforeaddressingthesecurityassurancelevelmodelmathematicsandissues,wemustagreeonthe
cybersecurityproblemdomainforindustrialautomationandcontrolsystems.Giventhelackof
empiricaldata,onemusttreatthecybersecurityvulnerabilityasalowprobabilityofanextremeevent.
Specifically,weareconcernedwithacyberattack,orseriesofattacks,carriedoutinamannerthatis
destructiveordisruptiveofelectricpowertransmissionanddistributionsystemoperationsand
processeswhicharenetworkedtogetherbyvariouscommunicationstechnologiesandmechanisms.

20
21
22
23
24

Morrison(Morrison1991)suggestedtherearefivetypesinthehierarchofdynamicsystems.TypeIII
systemshavechaoticsolutions.Thesesystemscomprisethetransitionbetweensolvableandnear
solvablesystemsandthosethatarecompletelystochasticorrandom.Becausetheyareleast
susceptibletostudyusingtoolsofmathematicalanalysis,quantifyinganindexparametersuchasSALis
amostdifficultchallenge.

25
26
27
28
29

AsMorrisonhasshown,thedifficultyinvestigatingchaosresultingfromaserioussecuritybreachisnot
infindingit,butinisolatingamanageableamountofit.Thesituationisfurtherexacerbatedbythelack
ofdatainthepublicdomainandthevulnerabilityisalowprobabilityofanextremeevent.Thebest
wecandoistoexaminecausalrelationshipsofcontributingfactorsandtoidentifytrendscharacterizing
thedynamicsofthesystem,includingorganizationalandhumanbehavior.

SingerandKube(SingerandKubeDecember17,2007)andTorgerson(Torgersonn.d.)haveshownthe
difficultiesofthisproblem.SingershowsthattheSILmathematicalapproachwillnotprovideamethod
forcalculatingtheforsecurityassurancelevel.Torgersonclaimsthatmathematicalalgorithmsdonot
exist.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page132

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

THENEEDTOACCOUNTFORTIMEANDEVENTDYNAMICS

1
2
3

Figure5isanotionaldescriptionoftherelativelyslowdegradationofsecuritylevelovertime,andthe
sharpdegradationthatresultsfromanadversaryinitiatedevent.

FIGURE5NOTIONALDEGRADATIONOFSECURITYASSURANCE

5
6

7
8
9
10
11

Initially,theinstalledsecuritylevelofaconduit,zone,subsystem,orsystemisatornearthedesign
securitylevelestablishedbytheassetowner.Thereisanaturaldegradationinthesecuritylevelover
timebecauseofalackofremedialactionorsecuritymaintenance.Forexample,ifpasswordsarenot
changedonaregularbasistheeffectivesecuritylevelwilldegrade.Iftheassetownerisdiligent,the
securitylevelwillplusuponaregularbasis.

12
13
14
15

Atsomepointintime,whichmaybeselectedbytheadversary,aneventisinitiatedthatcausesthe
securityleveltosharplydegrade,resultinginasecuritybreach.Thetimelapsebetweentheinitialevent
andthesecuritybreachmaybenearlyinstantaneous,ordelayed,dependingonthescenarioobjectives
oftheadversary.

16

BEWARYOFMORESECURITYISBETTER

17
18
19
20
21

Issomethingmissing?TheapproachdescribedinthenormativeclauseSecurityassuranceseemsto
provideareasonableframeworktoaddressmissioncriticalfunctions,andtherapidlyevolving
technologies.Butwhataboutthehumanbehaviorresponsetotheadditionalworkloadandmental
stressofadheringtothenewsecuritypolicies?Thatsubjectrequiresadifferentapproachthesubject
ofthissectionofAnnexB.

22
23

Intuitively,onewouldperceivethatthehigherthesecurityassurancelevel,thebetter.Settingcostaside
(youhaveanunboundedsecuritybudget),yourintuitionmaybewrong(MartinezMoyano2008).

24
25
26

Specifically,whensecuritymeasuresgrow,theperceptionofsecuritymeasuresinuseasbeing
excessivealsogrows.Thistypicallyresultsindecreasedmanagementsupportandusersupportaswell
astrustinthesecuritydepartment.Theirsupportisvitaltominimizethedegradationofsecurity

SP99Part4Draft1Edit0320080310Word972003format.doc

Page133

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

assurancedescribedinFigure5.Suchasituationcreatestheconditionsforincreasedriskand
vulnerability.Fortheskeptic,considerthefollowingexample.

3
4
5
6
7
8
9

DIAL UPACCESSTOINTELLIGENTELECTRONICDEVICE(IED)MAINTENANCEPORTSCO UPLED


WITH SIMPLEEASYTOREMEMBERPASSWORDS(CONSISTINGOF4NUMERICVALUES), IS
CONSIDEREDAVULNERABILITYANDHASBEENASSIGNEDSECURITYLEVEL2.TOIMPROVETHE
SECURITYLEVEL,MANAGEMENTINSISTEDTHATNEWIEDSMUSTSUPPORTMULTICHARACTER
PASSWORDSINCLUDINGATLEASTONESYMBOL,ONECAPITALLETTERANDONENUMERIC,AND
MUSTBEAMINIMUMOF8CHARACTERS.THISRAISEDTHEPERCEIVEDSECURITYLEVELTO 3
THETARGETREQUIREMENTIMPOSEDBYTHEITDEPARTMENT.

10
11
12
13
14
15
16

FIELDTECHNICIANSANDSERVICEPERSONNEL,WHOEXHIBITNORMALHUMANBEHAVIOR,
COULDNOTALWAYSREMEMBERTHECOMPLEXPASSWORD,SOTHEYIGNOREDTHESECU RITY
POLICYANDSIMPLYWROTEITDOWN.INEFFECTWRITINGITDOWNMADEITMORE
ACCESSIBLETOANONAUTHORIZEDTECHNICIANANDINCREA SEDTHEVULNERABILITY
RESULTINGFROMUNAUTHORIZEDACCESSTOANDCONTROLOFAMISSIONCRITICALIED.
THUS,THEREALIZEDSECURITYLEVELWASNOWPERCEIVEDTOBE1,WHICHWASLOWERTHAN
THESIMPLEPASS WORDTHATCOULDBEMEMORIZED.

17
18
19

Thebottomlineisthatoneneedstobecarefulaboutpushingforhighersecurityassuranceby
increasingcomplexityorthroughdefenseindepthmechanisms.Theresultcouldbeincreasedriskand
vulnerability.

20
21
22

Clearlyanothermodelisneededtoprovideinsightintothehumanbehaviorandresponsetosecurity.
ResearchershavefoundtheuseofasystemdynamicsmodelhelpfulinthisregardseeAnnexC:
Humanbehaviorresponsetosecurity.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page134

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ANNEXC:HUMANBEHAVIORRESPONSETOSECURITY

3
4
5
6
7

Systemdynamics 8 isanapproachtounderstandingthebehaviorofcomplexsystemsovertime.Itdeals
withinternalfeedbackloopsandtimedelaysthataffectthebehavioroftheentiresystem.Whatmakes
usingsystemdynamicsdifferentfromotherapproachestostudyingcomplexsystemsistheuseof
feedbackloopsandstocksandflows.Theseelementshelpdescribehowevenseeminglysimplesystems
displaybafflingnonlinearity.

8
9
10

Thebasisofthemethodistherecognitionthatthestructureofanysystemthemanycircular,
interlocking,sometimestimedelayedrelationshipsamongitscomponentsisoftenjustasimportant
indeterminingitsbehaviorastheindividualcomponentsthemselves.

11
12

SDM(systemsdynamicmodeling)requirestwomodelingcomponents:thecausalloopdiagramandthe
stockandflowdiagram.

13

DYNAMICTRIGGERS

14
15
16
17
18
19

Acausalloopdiagramisavisualrepresentationofthefeedbackloopsinasystem.Followingthe
exampleintroducedby(MartinezMoyano2008) 9 ,thecausalloopdiagramofthesecurityrisksandthe
emergenceofmaliciousinsidersreadytolaunchattacksmayfollowthedynamictriggerhypothesis
introducedby(Anderson2004).Figure6showsapartialviewofthecausalstructureofthedynamic
triggerhypothesisdescribedbyAndersonanddiscussedbyMartinezMoyanoinwhichthedetection
trap(R1)andthetrusttrap(R2)areidentified.

SystemdynamicsasdefinedbyWikipedia

ThismaterialhasbeenauthoredbyaArgonneNationalLaboratory,managedandoperatedby
UChicago,LLC,fortheU.S.DepartmentofEnergyunderContractNo.DEAC0206CH11367.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page135

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1

FIGURE6DYNAMICTRIGGERHYPOTHESIS

2
3
4
5
6
7

Thedetectiontrapillustratesthatwhentheorganizationaldetectioncapabilityislow,theconsequence
isapoorprobabilitythatactivitybyinsideradversarieswillbedetected.Thecounterclockwisedirection
ofR1denotesanegativereinforcement. 10 AndersonandMartinezMoyanoconcludedthatalowlevelof
maliciousactivitylowerstheorganizationsperceivedrisk,therebydecreasingitsdesiredinvestmentin
securitymeasuresandculminatinginevenlowerlevelsofdetection.

8
9
10
11

AndersonandMartinezMoyanofurthershowedthatthesituationisexacerbatedbythenegative
reinforcementofthetrusttrap,R2.Inthiscase,lowerlevelsofdetectedmaliciousactivityincrease
managerialtrustinsecuritywhichisinterpretedasloweringtheperceivedrisk,andleadstoan
underinvestmentinsecuritytherebyerodingthedetectioncapability.

12
13
14
15

Bothfeedbackloopsactsimultaneously,butatdifferenttimestheymayhavedifferentstrengths.Thus
onewouldexpectimprovedsecurityintheinitialyearsandthendecliningsecurityinthelateryears.The
advantagegoestothepatientinsider,whocanaffordtowaituntilsecuritybecomessolaxthatawell
plannedandproperlytimedattackasshowninFigure5cansuccessfullybeexecuted.

16
17
18
19
20

Arrowsindicatethedirectionofcausality.Signs(+and)indicatethepolarityofrelationships.A+
meansthat,allelseequal,ifthecauseincreases(decreases),theeffectincreasesabove(decreases
below)whatitwouldotherwisehavebeen.Similarly,ameansthat,allelseequal,ifthecause
increases(decreases),theeffectdecreasesbelow(increasesabove)whatitwouldotherwisehavebeen.
(Sterman2000).

10

Balancinglooppolarity(denotedbyBintheloopidentifier)indicatesaregulating(negative)feedback
loop.Reinforcinglooppolarity(denotedbyRintheloopidentifier)indicatesaselfreinforcing(positive)
feedbackprocess.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page136

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

Thedefinitionofpolarityissubtlesinceevenwithpositivepolaritytherearescenarioswherethecause
goesdownwhiletheeffectgoesup(evenwhentherearenoothercausesforthesameeffect).

BEWAREOFDEFENSEINDEPTH

3
4
5

IEC62443(IEC624432008)andISA99.00.01emphasizetheneedforDefenseinDepth(DiD)
implementedinlayersofsecuritytoprotectagainstmaliciousaccesstoanduseofdataordevices.

6
7
8

SDMincludestheconceptofastockandflowdiagram.Astockisthetermforanyentitythat
accumulatesordepletesovertime.Aflowistherateofchangeinastock.Inthecontextofcyber
security,theseentitiesarethemechanismsdeployedtoachieveDiDasshowninFigure7.

9
10
11
12

InFigure7,MartinezMoyanoassumedthattheassetownerhasanoriginalsecurityplanagood
assumption,sometimesoverlookedbyoverzealoussecurityconsultants.Thissecurityplanisusually
designedtoprovideadegreeofsecuritythatprotectscriticalmissionassetsfrommaliciouscyberattack,
andisaffordableintermsofthelegalandliabilityexposuresthatcouldresultfromasuccessfulattack.

13
14
15
16
17

Inthemodel,securitymeasureswhichareimplementedbythesecuritydepartmentshouldbein
proportiontotheperceivedlevelofinsiderattacks.Theirobjectivetodecreasingtheattackerspotential
forattackortheexploitablevulnerabilitiesofthesystem.ThenegativereinforcementloopinFigure7
labeledStoppingtheInsidersshowsthatasmoresecuritymeasuresareimplemented,thereisless
potentialforinsideattack,andthenumberofattacksdecreases.

18

FIGURE7ENABLINGDEFENSEINDEPTH

19

20
21

Thatisgood,butMartinezMoyanoshowedthereisadownside.Asinsiderattacksdecrease,the
perceivedneedforsecurityrelatedeffortdecreases,whichofcoursereducesthenumberimplemented.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page137

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
FIGURE8THECONSEQUENCESOFIMPLEMENTINGSECURITYMEASURES

1
2

ContinuingwithMartinezMoyanosexample,Figure8showsthattheconsequencesofimplementing
measuresrequiredtoachievethedesiredsecurityassurancelevel.Theloopsontherighthandsideof

3
4

Figure8highlightsthestronginfluenceofthesecuritydepartmentsaction,thetrustintheiractions,and
bothmanagementandusersupportfortheirinitiative.

5
6
7

Aslongasmanagementandusersupportisstrong,increasingthesecurityassurancelevelimprovesthe
perceivedeffectivenessofthesemeasures.However,thereisanegativeinfluencethatmustbecarefully
monitoredthedisruptionofnormaloperations!

IMPACTOFEXCESSIVESECURITY

9
10
11
12

Itishumannaturetoassumethatwhatseemstobeworkingwellshouldbeimprovedtomakeitwork
evenbetter.Securityassurancemechanismsneededtoprovidedefenseindepth(DiD)areveryprone
tosuchanexcessiveexpansion.Theexampleofcomplexpasswordstoraisetheperceivedsecurity
assurancelevelwasdescribedearlierandisagoodillustrationofthispoint.

13
14
15

Asstatedearlier,maintainingsecurityisacontinuingprocessrequiringbothmanagementanduser
support.MartinezMoyanoaddressedthefactorsthattendtodegradethissupport.Shownasared
overlayofFigure8,Figure9explainstheimpactofimplementingexcessivesecuritymeasures.

16
17
18

OntherighthandsideofFigure9theperceivedneedandwillingnesstoengageinexcessivesecurity
measuresisjustifiedbythesecuritydepartmentsobjectivetomaintainorincreasethesecurity
assurancelevel.Thenegativeconsequenceofaddingorincreasingthecomplexityofthesesecurity

SP99Part4Draft1Edit0320080310Word972003format.doc

Page138

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2

measuresisadegradationinthetrustofthesecuritydepartmentsactions.Thisofcoursereinforcesthe
perceptionthattheadditionalsecuritymeasuresareexcessive.

3
4

Torestrainthezealtoincreasesecurityassurance,ISA99.00.04proposestousetheindependently
derivedtargetsecuritylevel(
asanupperboundseeSecurityassurance.Thesumofthe

5
6

weightedsecuritylevelcomponents,someofwhichmaybeconsideredexcessive,iscappedbyproperly
assigningtheappropriateweightingfactor,wi.

7
8

ThebehaviordescribedinFigure9illustratestheneedformanagementoversightthatincludes
membersofallorganizationsthatcouldbeimpactedbyimplementingsecuritymeasures.

10

FIGURE9IMPACTOFEXCESSSECURITY

11

12

PRIVACYISSUES

13
14
15

AlthoughJamesB.Pick(Pick2007)wasmostinterestedinGEOBusinessandsecurityissuesrelatedto
GeographicalInformationSystems(GIS),hischapteronethical,legalandsecurityissuescanberelated
directlytotheimpactofexcessivesecuritymeasuresmodeledbyMartinezMoyano.

16
17
18

Forexample,strongaccessandusecontrolsecuritywiththeabilitytoretrieveauditlogsisa
cornerstoneofISA99sapproachtodefenseindepth.UsingaSmartCard(Figure10)hasseveral
advantages:
SP99Part4Draft1Edit0320080310Word972003format.doc

Page139

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

Itcreatesacomprehensiveinterfacebetweenallentitiesthathaveaccesstomissioncriticalsystem
hardware,softwareanddata.

3
4
5

Itprovidesaconsistentidentityestablishmentprocessthattheassetownercanenforcewithits
partners,suppliersandallinternalorganizationalunits,andwithregulatorsandothergovernment
oversightorganizations.

FIGURE10SMARTCARDFORDID 11

8
9
10

Pickshowedthatwhatwecallexcessivesecuritymeasures,justifiedbytheneedforahightarget
securityassurancelevel,iscounterbalancedbyseriousethicalandlegalconsiderations.

11

FACTORFICTIONTHENEEDFORVALIDATION

12
13
14
15
16
17

Intheelectricitysector,theFederalEnergyRegulatoryCommission(FERC)approvedonJanuary17,
2008theeightmandatorycriticalinfrastructureprotection(CIP)reliabilitystandardstoprotectthe
nationsbulkpowersystemagainstpotentialdisruptionsfromcybersecuritybreaches.Enforcementof
therulebytheNorthAmericanElectricReliabilityCorporation(NERC),whichFERChasdesignatedasthe
electricreliabilityorganization(ERO),takeseffect60daysfromthelaterofeitherthedateCongress
receivestheagencynoticeoftheruleorthedatetheruleispublishedintheFederalRegister.

11

SmartCardgraphicprovidedbyTecSec,Inc.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page140

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3

ThedilemmaISAnowfacesishowbesttovalidatethemodelsdefiningsecurityassurancelevelsandthe
applicationofthesemodelstoaddressrealsituations.Asstatedearlier,theproblemischaracterizedby
thelowprobabilityofextremeeventsandthetotallackofempiricaldataneededforevaluation.

4
5
6
7
8

Weknowfromoursearchoftheopenliteratureanddiscussionsinvariousvenuesthatthetendencyof
manyexpertsistohypethecybersecurityissueswithrhetoricaldramatizationandalarmistwarnings.
Tosummarizetheopenliteraturedebate:duetotoomanyuncertaintiesconcerningthescopeofthe
threat,expertsareunabletoconcludewhethercyberattackonourelectricpowergridreliabilityisfact
orfiction.

9
10
11
12
13
14
15
16

Inthiscontext,thefirstvalidationtaskistoidentify,sufficientlydescribe,andapplyrealcyberattack
scenariostovalidatethemodeldefiningsecurityassurancelevelssuchasthenotionalmodelshownin
Figure5.OnesuggestionistouseObjectOrientedModeling(OOM)forthispurpose.Theadvantageof
OOMisitsstrongrepresentation(viatheUnifiedModelingLanguageUML)ofrealworldentities,their
interrelationshipsinthescenario,andtheabilitytogeneratetransactionsequencesthatcapturetime
andeventconditions.Thereisalargebodyofoperationsresearchthathasbeenreportedinseveral
HICSSconferencesthataddresstheuseofOOMforcybersecurityapplications.Thechallengeistouse
thesetechniquestovalidatethesecurityassurancelevelmodel.

17
18
19

Clearly,thenumberofscenariosneededtocomprehensivelyaddressallcombinationofzonesand
conduitsatthecomponent,subsystemandsystemslevelsisnotfeasible,norisitneeded.Thechallenge
istoconstructselectedscenariostoprotectmissioncriticalassets.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page141

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ANNEXD:GUIDANCEFORUSINGISA99.00.04

3
4

ISA99.00.04isdesignedtoservefourusers:assetowners,systemintegrators,manufacturersof
industrialautomationandcontrolsystems,subsystemsandcomponents,andsecurityserviceproviders.

5
6
7
8
9
10

ISAenvisionsthattheassetownerwillusetheserequirementstoguidethespecificationofsecurity
requirementsneededtomitigateselectedrisksdiscoveredthroughtheirvulnerabilityassessmentand
evaluation.Systemarchitectureandoperatingproceduresmustbecompliantwiththeassetowners
securitypolicy.Procurementofsystemsandservicesshouldincludecompliancestatementforeachof
thesecurityrequirements,orgroupofrequirements,neededtoachievethedesiredlevelofsecurity
assurance.

11
12
13
14
15
16
17

Systemintegratorswillusethesesecurityrequirementstodesign,commission,deployandmaintaina
secureindustrialautomationandcontrolsystem.Thiswillprobablyrequiresometailoringofthe
requirementsetstobeharmonizedwiththeassetownersvisionofthetargetlevelofsecurity
assurance,accountingfortheoperatingprocedureconstraintsoftheenterprise,andthephasesof
implementationanddeployment.Suchtailoringofsecurityrequirementsneedsclearlyarticulatedinthe
systemintegratorscompliancedocuments,systemtestplanandproceduresandconfiguration
managementschemes.

18
19
20
21

Manufacturersandserviceproviderswillusethesesecurityrequirementstoguideproductdesignsand
servicestoincludesecurityaspartoftheirmarketingstrategy.Securitysolutionsmaybeofferedas
optionstoenhancethefunctionalcapabilityoftheproductsorservices,orwhererequiredbylocal
regulationsandlawsamandatorycapability.

22
23

Table25providesaviewofthosesecurityrequirementsapplicabletoeachuserofISA99.00.04.The
requirementsaregroupedbysecuritytopicforthereadersconvenience.
TAB L E25APPLICABLE REQU IREMENTS OFIS A99.00.04FOR USERS

24
SecurityTopic

AssetOwners

SystemIntegrator

Manufacturer

ServiceProvider

Foundational
Requirements

FR1,FR2,FR3,
FR4,FR5,FR6,
FR7

FR1,FR2,FR3,
FR4,FR5,FR6,
FR7

FR1,FR2,FR3,
FR4,FR5,FR6,
FR7

FR1,FR2,FR3,
FR4,FR5,FR6,
FR7

ProtectionofData
atRest

Securityof
Network
Components

SP99Part4Draft1Edit0320080310Word972003format.doc

Page142

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

SecurityTopic

AssetOwners

SystemIntegrator

Manufacturer

ServiceProvider

Securityof
TerminalDevices

AutomationCell
Interconnection

ACI4,ACI5,ACI6,
ACI7,ACI10,
ACI11,ACI12,
ACI13

ACI1,ACI2,ACI3, ACI1,ACI2,ACI3,
ACI4,ACI5,ACI6, ACI4,ACI8
ACI8,ACI9,
ACI10

Interactive
RemoteAccess

IRA12,IRA13,
IRA14,IRA15,
IRA26,IRA27,
IRA34,IRA35,
IRA36,IRA37,
IRA38,IRA39,
IRA40,IRA44,
IRA45,IRA46,
IRA47,IRA48,
IRA49,IRA50,
IRA51,IRA52,
IRA53,IRA54,
IRA55,IRA57,
IRA58,IRA59,
IRA60,IRA61

IRA1,IRA2,IRA3, IRA41
IRA4,IRA5,IRA6,
IRA7,IRA8,IRA9,
IRA10,IRA11,
IRA16,IRA17,
IRA18,IRA19,
IRA20,IRA21,
IRA22,IRA23,
IRA24,IRA25,
IRA26,IRA27,
IRA28,IRA29,
IRA30,IRA31,
IRA32,IRA33,
IRA34,IRA38,
IRA39,IRA40,
IRA41,IRA42,
IRA43,IRA45,
IRA46,IRA47,
IRA48,IRA49,
IRA56,IRA57

TBD

ControlNetwork
Interconnection

ECI2,ECI3,ECI4,
ECI5,ECI18,
ECI31,ECI35,
ECI36,ECI37,
ECI38,ECI46,
ECI47

ECI2,ECI23,
ECI24,ECI25,
ECI26,ECI27,
ECI28,ECI29,
ECI30,ECI31,
ECI32,ECI33,
ECI34,ECI38,
ECI39,ECI40,
ECI41,ECI42,
ECI43,ECI44,
ECI45,ECI46

ECI19,ECI20,
ECI25,ECI35,
ECI38,ECI39,
ECI40

SP99Part4Draft1Edit0320080310Word972003format.doc

Page143

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
SecurityTopic

AssetOwners

SystemIntegrator

Manufacturer

ServiceProvider

InterControl
Center

ICC7,ICC8,
ICC9,ICC10,
ICC11,ICC12,
ICC13,ICC14,
ICC15,ICC16,
ICC17,ICC18,
ICC19

ICC1,ICC2,
ICC3,ICC4,
ICC5,ICC6,
ICC7,ICC8,
ICC11

ICC1,ICC2,
ICC3

SP99Part4Draft1Edit0320080310Word972003format.doc

Page144

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

ANNEXE:FIELDCOMMUNICATIONANDDEVICES

1
2
3
4

Analysisofthepatternsofintendeduseofinterdeviceindustrialcommunicationsresultedina
partitioningofthatcommunicationsintosixclasses.Theseclassesaredescribedaresummarizedin
Table26.
TABLE 26FIELDCOMMUNICATIONSANDDE VICEUSAGECLASSES

5
Safety

Class0:Emergencyaction(alwayscritical)

Control

Class1:Closedloopregulatorycontrol(oftencritical)

NOTEBatchlevels*3&4couldbeclass2,class1orevenclass0,dependingon
function

*BatchlevelsasdefinedbyISAS88;whereL3="unit"andL4="processcell"
Monitoring

Class4:AlertingShorttermoperationalconsequence

(e.g.,eventbasedmaintenance)
Class5:Logginganddownloading/uploading

timelinessincreases

Class3:Openloopcontrol(humanintheloop)

Importanceofmessage

Class2:Closedloopsupervisorycontrol(usuallynoncritical)

Noimmediateoperationalconsequence(e.g.,historycollection,sequenceof
events,preventivemaintenance)
6

Alarmscanbeofanyclass;theymayrequireeitherhumanoranautomatedresponse.

8
9

Assetownersaregenerallycostadverse.Table27describessomeconsiderationsthatinfluencelife
cyclecost.
TABLE27COSTCONSIDERATIONS

10
Capitalexpense

Costtoaddadeviceroughlyequaltoaddingunsecuredversionofasimilar
devicethatusesdigitalcommunications

Operationalexpense

Maintenancecostofinstrumentsimilartounsecureddevice

Easyinstallation
andmaintenance

Efforttoaddadeviceroughlyequaltoaddingunsecuredversionofasimilar
devicethatusesdigitalcommunications

Powermanagement

Thepowerrequiredtooperateafielddeviceshouldberoughtlyequaltothat
fortheunsecuredversionofasimilardevicethatusesdigitalcommunications

SP99Part4Draft1Edit0320080310Word972003format.doc

Page145

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4

Plantoperationmanagersareconcernedwithavailabilityandperformance.Table28liststhose
considerationsthatneedtobeaddressedwhenaddingsecuritytothefieldcommunicationsand
devices.

TABLE28AVAILABILITY ANDPERFORMANCECONSIDERATIONS
Environmental

Worksinharshindustrialenvironments

Adequate
reportingrates

Bestperformanceissimilartounsecuredigitalcommunications

Suitablefor
closedloopcontrol

Supportofmulticasttoalimitedsmallsetofprimaryreceiversthatneedtimely
messageauthenticity,andalargersetforwhomtheauthenticitycanbe
deferred

Supportfor
peertopeer
messagingand
controlinthefield

MessagingwithagatewaytoaDCSorsimilarcontrolroomsystem
Concurrentmessagingwithotherfielddevicesforinfieldloops

6
7
8
9

Plantoperationmanagersarealsoconcernedwithcompatibilityandscalability.Table29liststhose
considerationsthatneedtobeaddressedwhenaddingsecuritytothefieldcommunicationsand
devices.

10

TABLE29CO MPATIBILITYANDSCALABILITYCONSID ERATIONS


Compatibility

CanbelayeredontopofexistingCOTScommunicationstechnology

Worldwideusability

Devicesmustbeuseablearoundtheworld,althoughcryptographicalgorithm
suitemaybenationallydefined

Capacityand
scalability

Upto30,000fielddevicespercontrolcenter
Predictableperformancewhenrequiredbyapplication

11
12
13
14

Qualityofservice(QoS)needsspecialattentionwhensecurityisadded.Table30liststhemost
importanttimeliness,deliveryorderingandrecoveryactionconsiderations,andassociatesthosewith
theclassesdescribedinTable26.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page146

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

TABLE30QUALITYOFSERVICECONSIDERATIONS
1. Immediate(e.g.,class0emergencymessages,highpriority
alarms)
2. Scheduleddelivery(e.g.,classes12amongclosedloopperiodic
controlblocks)
3. Timeavailable(e.g.,classes35monitoring,lowpriorityalarms)
4. Highthroughput(e.g.,historyupload,configurationdatabase
download,codedownload)
Deliveryordering

timelinessincreases

Timeliness

Importanceofmessage

1. Intervalstamped(e.g.,classes12amongclosedloopperiodiccontrolblocks)
2. Timestamped(e.g.,classes0,35monitoring,lowpriorityalarms)
3. Sequenced(e.g.,filetransfer)

Recoveryaction

1. Noretry
2. Retryuntilmorecurrentdatasetavailable
3. Retryuntiltransferacknowledged

2
3
4

Table 31 lists the network security, messaging security and device security needed to address
the afor ementioned considerations.

TABLE31SECURITYCONSIDERATIONS
Network
security

Networkisprotectedagainstdeliberateattackorhumanerrorby:
1. Provabledeviceidentity
2. Authorizationofcommunicationsrelationships,usuallybyautomatic
derivationfromconfigurationdatabase
3. Automatickeymanagement
4. Inference,logging&reportingofpossibleattack

SP99Part4Draft1Edit0320080310Word972003format.doc

Page147

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
Messaging
security

Communicationsareprotectedagainstdeliberateattackormessagingsystemerror
bycheckingthatthemessageis:
1. fromtheclaimedsource
2. intact&unmodified
3. unduplicated
4. meetsrequirementsofapplicableDeliveryorderQoSclass
5. timelyrelativetoapplicationneed
Communicationsareprotectedagainsteavesdroppingwhereappropriateand
legallypermitted,byencryptingthemessagepayloadtolooklikerandomdata

Device
security

Deviceisprotectedagainstundetectedcompromisebyattackersofmoderateskill
by:
1. Singlechipcryptographicmoduleconstruction
2. Nodebuggingmodeaccesstocryptomodule(e.g.,disabledJTAG)
3. Unpredictableremoteverificationofknowndevicecodeandstate

1
2
3

MONITORINGANDCONTROLPARADIGMSFORAUTOMATIONSYSTEM S
Allautomationsystemmonitoringandcontrolactivitiesfallintooneofthreebroadcategories:

4
5
6
7
8
9
10

Phasetriggered(PT)activitiesarethosewhichoccurcyclicallywithinsomepredeterminedphase
windowofanaperiodicrepetitiveprocess,suchasthevalveopeningorclosingorfuelinjectionorfuel
ignitionthatoccursinaninternalcombustionengineasafunctionoftimingcamphase,largely
independentofenginespeed.Theseactivitiesarefoundinsystemsbasedonmechanicalaction,
typicallycontrolledbyprogrammablelogiccontrollers(PLCs);insupervisorycontrolanddataacquisition
(SCADA)systems,typicallyusedinpowergridandpipelinecontrol;andinbatchandmultistage
processes.

11
12
13
14
15
16

ThismodeofaccessistypicalofpointsusedinPLCbasedcontrolsystems,whichcyclicallyexecutea
variabledurationsequenceofprogrammedactionsatthemaximumpossiblerate.Suchsequenceswere
initiallymodeledon"ladders"ofconnectedrelays,butnowfrequentlyusealternateprogramming
methodologiessuchassequentialfunctioncharts.Executionofasequencerestartscyclicallyon
completionofthepriorexecution,butduetothenonconstantexecutiontimeofeachinstance,the
resultingcomputationsareaperiodic.

17
18
19

Phasetriggeringmayalsobeusedforaccesstoprocessmeasurementsthatarebeingsampledfortrend
reports,providedthatboththeprocessmeasurementandthesamplingtimearereportedtopermit
interpolationfromunequallyspacedsamples.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page148

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4

Timetriggered(TT)activitiesarethosewhichoccurwithinsomepredeterminedtimewindowofa
periodicprocess,suchasthesamplingofrealworldprocessstateortheresultingchangetoaprocess
actuatorthatoccursduringexecutionofaPID(proportionalintegralderivative)controlloop.These
activitiesformthecoreofmost(DCS)distributedcontrolsystems.

5
6
7
8
9
10

Thepermittedamountofjitterintimetriggeredphysicalprocessinteractionsisdependentonthe
natureofthecontrolorusageofthedata:forcontrolloopssuchasPIDorPDthatincludeasignificant
nonzeroderivativeterm,thepermittedjitteristypicallylessthan4%oftheloopperiod;forother
controlloopsbasedonfinitedifferencearithmetic,thepermittedjitteristypicallysmall;fortrendsand
otherformsofhistorizing,amoderatedegreeofjitterispermissible;othermonitoringactivitiesmay
placenoconstraintsonjitter.

11
12
13
14
15

Eventtriggered(ET)activitiesarethosewhichoccurinresponsetosomehumandemandorplant
initiatedevent,suchasacommandedactionoralimitswitchtriggeredalarm.Manyeventtriggered
activities,suchasoperatordisplaycallupsordetectedgasleakalarms,aresomewhatasynchronousto
theprocess;otherssuchaslimitalarmsariseasoccasionalconsequencesofphasetriggeredortime
triggeredactivities.

16
17
18
19

Thismodeofaccesscanbeappliedtopointsthatarebeingusedformonitoring,butnotforcontrolor
trendrecording.Communicationsrelatedtosuchpointsmaybelocallytriggered,asfordevicesthat
reportonlywhenqueriedorthat"reportbyexception"whenconditionsorsampledvalueschange.
Accessalsomayberequestedbyhumanoperatorsorotherpartsoftheautomationsystem.

20
21

Whilephasetriggeredandtimetriggeredactivitiesareinaverygeneralsenseeventtriggered,itis
usefultodistinguishthemasseparatecategoriesduetotheircyclicorperiodic(respectively)nature.

22
23
24
25

Allbutthesimplestautomationsystemsincludeeventtriggeredactivities.Mostdiscretepart
manufacturingsystemsalsoincludephasetriggeredactivities,whilemostcontinuousprocesssystems
includetimetriggeredactivities.Complexmanufacturingsystemssuchasthoseforpharmaceuticalsor
inaplantproducingpreparedfoodordrinksincludeallthreetypesofactivities.

26

NEEDSFORINDUSTRIALDEVICETODEVICEFIELDCOMMUNICATIONS

27
28
29
30

Differentusesofdevicetodevicefieldcommunicationswithinanindustrialplanthavebeenidentified.
Someoftheseusesplaceminimalrequirementsonthefieldnetworks;othersdemandnetworksecurity
orspecificqualitiesofservice.Multiusesystemsneedtoconsideralloftheseaspectssothatsomeuses
donotcompromiseothers.

31

AUTOMATEDMONITORINGOFINDUSTRIALEQUIPMENT

SP99Part4Draft1Edit0320080310Word972003format.doc

Page149

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4
5
6
7
8
9
10
11

Automatedmonitoring 12 withoutimmediateconsequentialactionisawidelydesireduseofindustrial
fieldcommunications.Itislikelythatalargepercentageofthemeasurementpointsinaplantfallinto
thiscategory.Suchmonitoringcanbeeventtrigger,phasetriggeredortimetriggered.
Sincetherearenoimmediatelyconsequentialactionstothelossofsuchmonitoringmessages,
individualcommunicationsneednotbereliablethoughoverallcommunicationneedstosucceed
frequentlyenoughtosatisfytheunderlyingapplicationrequirements.Perhapsthemostdemanding
applicationofsuchmonitoringissequenceofeventsreporting,whereindividualmessagessending
timestampedeventlogscanbelostprovidedthatareliabletransmissionprotocolensuresthatlogsof
sequentiallynumberedeventsarecommunicatedandacknowledgedbeforethesource'slogbuffers
overflowandeventrecordsarelost.(Stateddifferently,theretransmissionneednotbeidenticaltothe
originallosttransmission;itcanincludemoreevents.)

AUTOMATEDALARMINGBYINDUSTRIALEQUIPMENT

12
13
14
15
16

Almostallautomationequipmentinaplanthasthepotentialcapabilityofdetectingundesiredor
anomalousevents.Inmostsuchcases,theequipmentneedstoreporttheeventtoacentralcollection
point,eitherfornotificationofoperationspersonnel,orforanautomatedremedialresponsetothe
event,orboth.

17
18
19
20
21
22

Allalarmingisinherentlyaneventtriggeredactivity,inthattheoccurrenceofthealarmisanacyclic
eventthatisitselfnotexactlypredictable.However,thealarmmayariseasanaturalconsequenceof
someotherautomationsystemactionsuchasaprocessmeasurementorcommandedactuatoraction.
Insuchcasesthealarmcanbeconsideredtobetosomedegreephasetriggeredortimetriggeredwhen
theunderlyingdetectingactionisphaseortimetriggeredorthestateoftheconditionbeingmonitored
isitselfquasiperiodic.

23

AUTOMATEDCONTROLOFINDUSTRIALEQUIPMENT

24
25
26
27

Someclosedloopcontrolisacyclicandeventtriggered,suchastheautomaticinvocationofsafety
measuresshouldasafetyinterlockbeactuated.However,mostclosedloopcontrolinautomation
systemsiseithercyclicorperiodic,dependingonwhethertheunderlyingprocessisinherentlya
periodicandthusphasetriggeredorinherentlyperiodicandthustimetriggered.

28
29
30

Somecontrolloopsare"closedloop"whereanautomatedprocessdrivesactuatorsbasedonvarious
sensormeasurementsanddesiredbehavior.Lossofthecommunicationswithinsuchcontrolloops
frequentlyhassignificanteconomicconsequences.

HUMANINTERVENTIONANDACTION

31
32
33

Manycontrolloopsare"openloop",whereahumanoperatorintervenesbetweeninterpretingsensor
measurementsandoperatingactuators.Thisincludesoperatoractivatedmotor,pump,valveandgate

12

AutomatedmonitoringwithimmediateconsequentialactionisaddressedinAutomatedalertingby
industrialequipment,whereitiscalledalerting.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page150

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems

1
2
3
4

operation.Sometimesthesecontrolloopsare"open"(humanintheloop)becausetheyoccurwithsuch
lowfrequencythattheirautomationcannotbejustified.Inothercases,theinterpretationofsystem
stateandbalancingofcompetingfactorsthatisneededtodeterminetherequiredactionisnotreadily
programmed,soamoreadaptive"humancomputer"isusedinstead.

5
6

Inmostcasesofhumanintervention,thehumancaninitiatebackupproceduresforprolonged
communicationsoutages.

AUTOMATEDALERTINGBYINDUSTRIALEQUIPMENT

8
9
10
11
12
13

Thereisacategoryofautomatedmonitoring,knowninthisdocumentasalerting,inwhichahuman
operatortypicallyschedulesaneartermmaintenanceactionsometimeafteramonitoredeventor
trendisrecognized.Thisalertingrequiresamoretimelyandimmediatelyconsequentialresponsethan
thatforsimple"monitoring",whereneededresponsetimemightbemeasuredinweeks,butlesssoand
lessimportantthanthatofanautomaticorhumandrivencontrollooporanalarm,whosemean
responsetimeistypicallyseconds.

14
15
16

Thecharacteristicsofalertingcommunicationsfallsomewherebetweenthoseofmonitoringandof
otherhumaninitiatedcontrolactions.Assuchitispartofacontinuum,butoccurssufficiently
frequentlytodeserveitsowncategory.

17
18
19
20
21
22
23
24
25
26
27
28
29

PATTERNSOFINDUSTRIALFIELDCOMMUNICATIONSUSE
Thefollowingcommunicationspatternswillexistinmostplants.Standardsforsecurecommunications
shouldsupportalloftheconsiderationsdiscussedinthisclause.

FIELDDEVICESWHEREAVAILABLEENERGYREQUIRESLOWCOMMUNICATIONSBURDEN
Somefielddeviceswillbeoperatedfromlocalfixedenergysourcessuchasfuelcellsorbatteries;the
lattermaybutneednothaveanintermittentexternalsourceofreplenishment.Suchdevicesgenerally
mustbeinaverylowenergyusemodeforthemajorityoftheirtimewhileoperating,precluding
continuousreceptionexceptinrelativelyinfrequentspecialsituations.

FIELDDEVICESCAPABLEOFCONTINUOUSCOMMUNICATIONS
Manyfielddevices,includingalmostallwithhighdatarateorhighinteractionratecommunications
requirements,willhaveanalwaysavailableexternalenergysource.Suchdevicescanbepreparedto
communicateatanytime,butmuststillscheduletheirtransmissionstoleaveanyshared
communicationschannelclearforreceptionofmessagesfromotherdevices.

30

PURPOSEBUILTROUTERS

31
32
33

Theseconsiderationsapplytopurposebuiltrouters.Additionally,routersmayservetointerconnect
lowdataratesubnetworkswithhigherdatarateones,eitherwiredorwireless(orboth).Fielddevices
capableofcontinuouscommunicationsmayalsoserveasrouters.
SP99Part4Draft1Edit0320080310Word972003format.doc

Page151

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3
4
5
6

Itisalsopossibletouseasroutersdevicesthatdonothaveadequatepowertofunctioncontinuously.
Suchdevicesusuallywillreducethechannelcapacityoftheirsubnetworktothatoftheirdutycycle
(e.g.,arouterthatisoperating10%ofthetimewilllimititssubnetworkto10%ofthepotentialcapacity
ofthatsubnetwork).Suchusagemaybedesirableduringemergenciesandsystemcommissioning,but
isprobablynotjustifiableduringnormaloperationexceptinverysmallmeshsubnetworksorwithvery
slowprocesses.

GATEWAYSTOAMONITORINGORCONTROLSYSTEM

8
9
10
11
12
13
14

Gatewaysmaybeneededtoconnectsecurednetworkstolegacywiredmonitoringorcontrolsystems.
Thesegatewayscanmapexpectedlegacyqualityofservicecharacteristicsandhigherlevelprotocols
intothoseavailablewithinthesecurednetworks.Thegatewaysarealsoresponsibleformappingthe
network'ssenseoftimetothatoftheconnectedmonitoringorcontrolsysteminthecasewherethe
twodiffer,asislikelywhenmultiplesuchsystemsconnecttothesamesecurednetworkorwherea
dedicatedcentralsecurityauthorityprovidesthatnetworktimeinsupportofrequiredsecurityrelated
forensics,withhigherassurancethanisavailablefrommultifunctioncontrolcomputers.

15
16

Newmonitoringorcontrolsystemsmaybeabletoconnectdirectly,withoutgateways,tosecured
networksandconnectedsecuredfielddevices.

17

DIRECTCOMMUNICATIONS

18
19
20
21
22
23
24

Fielddeviceswhicharecontinuouslypoweredfromanexternalsourceandwhichsharea
communicationschannel(e.g.,amultidroplineoracommonwirelesssubnetwork)maybeableto
messageeachotherdirectly.Suchcommunicationsmightbeusedbetweenacontinuouslypowered
actuatorwithanintegralcontrolloopanditsassociatedsensors(whichgenerallyneednotbe
continuouslypowered).Becausesuchcommunicationspatternsproviderobustcontrolinthepresence
ofrouterorcentralcontrolroomoutage,theycanbeexpectedtobecomemorecommon.Theyarenot
neededtoemulatethecapabilitiesofcentralizedwiredmonitoringorcontrolsystems.

25

RELAYEDCOMMUNICATIONS

26
27
28
29
30
31
32
33
34

Fielddeviceswhichrequirelowcommunicationsdutycyclesmaybeabletocommunicatewitheach
otherthroughthestoreandforwardrelayingcapabilitiesofintermediaryrouters.Aswiththedirect
communications,suchcommunicationspatternsarelikelytobecomemorecommonasstandardsfor
wirelessfieldcommunicationsemerge.Theyarenotneededtoemulatethecapabilitiesofcentralized
wiredmonitoringorcontrolsystems.

BETWEENHUMANSANDEQUIPMENT
Humansinacentralizedcontrolroomhaveaneedtointeroperatewiththecontrolsystem.Thatuseis
beyondthescopeofsecuredfielddeviceandfielddevicecommunicationsstandards.Interoperation
throughthecontrolsystemwithfielddevicesiswithinthatscope.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page152

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3

Humansinthefield,suchasrovingoperators,planttechniciansandvendorsupportpersonnel,may
haveaneedtointeroperatewiththecontrolsystem.Securedfieldcommunicationscouldbeusedto
supportthatinteroperation.

4
5
6
7
8
9

Humansinthefieldmayalsohaveaneedtoaccessfielddeviceswithouttheinterventionofacentral
monitoringorcontrolsystem.Suchaccessislikelyduringinitialplantcommissioning,whenthecontrol
systemisnotyetoperationalorthesecuredrouterbackbonenetworkisnotyetcompletelyemplaced.
Suchaccessmayalsobeneededduringtimesofmajorplantrestructuring,duringsignificantplant
startupandshutdownactivities,andduringtimesofemergencywhennormalcommunicationspaths
aredisrupted.

10
11
12
13
14

Humanaccesstodevicesthatareconcurrentlybeingaccessedbyacentralmonitoringorcontrolsystem
needtohavethathumanaccessmanagedbythecentralsystemtoavoidinconsistenciesbetweenactual
deviceparametersandvariablesandthecopiesofthatinformationthatiscachedbythecentralsystem.
Typicalchannelcapacity,particularlyforwirelesschannels,doesnotpermitcentralsystemoperation
withoutsuchcaching.

15

AMONGHUMANS

16
17
18
19

Humansinthefield,whethertechniciansorrovingoperators,arelikelytoneedvoicecommunication
withoperatorsinacentralizedmonitoringorcontrolroom.Insomecases,particularlyduringtimesof
emergencyormajorplantrestructuring,theyarelikelytoneedvoicecommunicationwithothersinthe
field.

20

USAGECLASSESOFINDUSTRIALDEVICETODEVICEFIELDCOMMUNICATIONS

21

Thisinformativeclauseprovidesanexplanationoftheusageclassesearlier.

22
23
24
25

Althoughtherearemanywaysofpartitioningthevarioususesofindustraldevicetodevicefield
communicationswithinanautomationsystem,themostrelevantclassificationseemstobeapartition
basedonurgencyofcommunicationandcriticalityofuse.Thisclassificationcloselymatchesthe
differingneedsforindustraldevicetodevicefieldcommunications.

26

CLASS0:[SAFETY]EMERGENCYACTION

27
28
29
30
31

Safetyrelatedactionsarealwayscriticaltobothpersonnelandplant.Mostsafetyfunctionsare,andwill
be,performedthroughdedicatedwirednetworkstolimitbothfailuremodesandsusceptibilityto
externaleventsorattack.Sharedorwirelesscommunicationcanserveasabackupcommunications
path,orastheprimarypathwhendedicatedwiredconnectionsareinfeasible(e.g.,acrossariveror
majorhighway).

32

Examplefunctions:safetyinterlock,emergencyshutdown,firecontrol

33
34

Examplealarms:leakdetectionforradiationoratoxicgasthattriggersanautomatedcontainment
response

SP99Part4Draft1Edit0320080310Word972003format.doc

Page153

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3

Communicationscharacteristics:usuallyeventtriggered,butcouldbephaseortimetriggered.Urgent
butveryinfrequentactivation.Couldrequirefrequentminimalphaseortimetriggeredmessagingto
reportnonfailure.

CLASS1:[CONTROL]CLOSEDLOOPREGULATORYCONTROL

Primaryregulatorycontrolloopsareoftencriticaltotheoperationandeconomicsofaplant.

Examplefunctions:directcontrolofprimaryactuators,highfrequencycascadecontrolloops

7
8

Examplealarms:highimpactprocessconditionsthattriggeranautomatedresponse(e.g.,shutdownof
areaction)

9
10
11

Communicationscharacteristics:ForPLClikecontrolsystems,thisusuallyinvolvesphasetriggered
cyclictransmissionatoneormorepointsinthePLC'svariabledurationcycle.Lostmessagesgenerally
requirecontemporaneousretransmission.

12
13
14
15
16

Forprocesscontrolsystems,thisofteninvolvestimetriggeredperiodictransmissionwithina
predeterminedfractionalportionoftheunderlyingcontrolloopcycle.Lossofmessagingduringoneor
twoconsecutivecycleshasonlysmalleconomicconsequence,butlossofmessagingfora
predeterminednumberofconsecutivecyclestriggersfailovertoabackupcontrolmodewithpotentially
significanteconomicimpact.

17
18
19
20
21

Thetimeintervalfromthemomentthataphysicalprocessissampleduntilaphysicalcorrectiveactionis
appliedtotheprocessisknownasthedeadtimeofthecontrolloop.(E.g.,withthecyclemeasuredfrom
themomentofprocesssensing,transmissionofsensedstateoccurringbetween15%and35%ofthe
cycle,transmissionofacomputedcontroloutputbetween60%and72%ofthecycle,andwiththe
outputappliedtothephysicalprocesspreciselyat75%ofthecycle,theloop'sdeadtimeis0.75cycles.)

22
23
24
25
26
27
28
29
30

Typicallydeadtimecanbeuptotwicetheperiodofaloop,thoughproportionallylargedeadtimesdo
reducetheresponsivenessofcontrol.Aloopdeadtimeofnearlyonecycle,orgreater,permits
clusteringcommunicationsofbothcontrolinputsandcontroloutputsintoacommontransmission
window,whichmaybettermatchtheschedulingconstraintsofavailablewirelessnetworks.(E.g.,with
respecttothepriorexample,ifthetransmissionofthecomputedcontroloutputoccurredbetween
110%and130%ofthecycle(whichis10%to30%ofthenextcycle),andwiththeoutputapplied
preciselyat35%ofthatsecondcycle,thentheinputtransmissionofonecyclewouldberoughly
concurrentwiththeoutputtransmissionforthepriorcycleandtheloop'sdeadtimewouldbe1.35
cycles.)

31

CLASS2:[CONTROL]CLOSEDLOOPSUPERVISORYCONTROL

32
33

Secondaryregulatorycontrolloopsareusuallynoncritical,withminorimpactonproductqualityand
theeconomicsofplantoperation.

34
35

Examplefunctions:lowfrequencycascadecontrolloops,multivariablecontrolloops,complex
optimizers

SP99Part4Draft1Edit0320080310Word972003format.doc

Page154

ISA99Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2

Examplealarms:lowimpactprocessconditionsthattriggeranautomatedresponse(e.g.,flow
diversion)

3
4

Communicationscharacteristics:SimilartothoseofClass1,butwithlesseconomicimpactoffailure
andproportionatelylesscriticaltimingconstraints

CLASS3:[CONTROL]OPENLOOPCONTROL

6
7
8

Openloopcontrolalwaysinvolvesahumanintheloop.Assuchitmaybecriticaltoplantoperation,or
not,butthetimeconstantsofsuchcontrolarethoseofanoccasionallyinattentivehuman,notofan
evervigilantmachine.

9
10
11

Examplefunctions:anoperatormanuallyinitiatesaflareandwatchestheflare;aguardcommunicates
withavehicledriverthroughanintercom,verifiesthroughavideoimageandremotelyopensasecurity
gate;anoperatormanuallycontrolsapumporvalve

12
13

Examplealarms:aprocessconditionwithamanuallydeterminedresponse(e.g.,anoperatordeciding
towhichparallelreactortodivertaflow)

14
15

Communicationscharacteristics:infrequent,withdelaysunder1swherepossibletominimizeoperator
irritation

16

CLASS4:[MONITORING]ALERTING

17
18

Alertingnotifiesthesystemoroperatorofaconditionthathasashorttermoperationalconsequence.It
istypicallyusedforeventbasedortrendbasedmaintenance.

19
20

Examplefunctions/alarms:anequipmentconditionrequiringnearfuturemaintenanceresultingina
technicianbeingsenttothefield

21
22

Communicationscharacteristics:infrequent,usuallyeventtriggeredbutsometimesphaseortime
triggered,typicallyreflectingperiodicsampling

23

CLASS5:[MONITORING]MONITORING,LOGGINGANDDOWNLOADING/UPLOADING

24
25

Monitoringtransferslocallysensedprocessstateinformationtothesystem.Suchtransfersusuallyare
repetitiveatsomeratedeterminedbythelikelihoodandexpectedfrequencyofsignificantchange.

26
27
28

Loggingtransferslocallyaccumulatedinformationfromadevicetothesystem,andacknowledgesthe
transfersothattheloggingdevicecandeletethetransferredinformationfromitslimitedsizelog.Log
transfersshouldbefrequentenoughthatdevicelogbuffersgenerallydonotoverflow.

29
30
31
32

Downloadingtypicallytransferslargeamountsofconfigurationdataordevicecode.Uploadingtypically
transferssmalleramountsofconfigurationdata.Bothoperationsaretypicallyperformedasnetwork
backgroundactivity.Multicastdownloadshouldbesupportedtominimizethetimetoinitializeor
upgradetheautomationsystem'sdevices.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page155

ISA99 Part4:TechnicalSecurityRequirementsforanIndustrialAutomationandControlSystems
1
2
3

Thedistinguishingpropertyofthisclassofcommunicationsisthatthesuccessoffailureofindividual
messaginginstanceshasnoimmediateoperationalconsequence.Itisonlyintheaggregatethatsuch
messagingmustsucceed,

4
5

Examplefunctions:historycollection;preventivemaintenancerounds;sequenceofevents(SOE)logsof
timestampedevents;incrementaldeviceconfigurationdownloadorupload;devicecodedownload

6
7

Examplealarms:anequipmentconditionwithalongtimescalemaintenanceaction(e.g.,orderspare
parts)

8
9
10
11
12
13

Communicationscharacteristics:Monitoringisusuallyphaseortimetriggered;loggingisusuallyevent
triggered.Logging,downloadinganduploadingtypicallyrequirereliabletransferprotocols;monitoring
typicallydoesnot,thoughthehigherlevelsystemusuallynotesaprolongedperiodofsuccessive
messageloss.Downloadcapabilitiesofhighdataratenetworksshouldincludeamulticastprotocolwith
sparseincrementaldemandretransmission(e.g.,likeIEEE802.1D)topermitconcurrentdownloadof
commoncodeordatatomanydevices.Uploadistypicallypointtopointandinfrequent.

SP99Part4Draft1Edit0320080310Word972003format.doc

Page156

You might also like