Rahul Bhojani ISA SP99 WG4 Meeting in Scottsdale, AZ June 26, 2007

1. Using Models Introduced in ISA-d99.00.01 Standard: Security of Industrial Automation and Control Systems (IACS) Rahul Bhojani ISA SP99 WG4 Meeting in Scottsdale, AZ June 26, 2007

2. Example Approach to IACS Security using Models Introduced in ISA-d99.00.01 • Identify IACS components and develop architecture drawing • Group IACS components into Zones and Conduits • Conduct risk assessment and assign target Security Level to Zones and Conduits • Identify technical and administrative countermeasures to achieve the target Security Level • Implement technical and administrative countermeasures to achieve the target Security Level • Maintain effectiveness of implemented technical and administrative countermeasures

3. Identify IACS Components and Develop Architecture Drawing MES Applications Analysis Tools Data Historian App. Stn Engr. Stn HMI HMI Engr. Stn App. Stn Controller + I/O Controller + I/O Fieldbus Fieldbus Plant B Plant A Example architecture of a site with multiple plants

4. Group IACS components into Zones and Conduits • Zone is a grouping of logical or physical assets that share common security requirements • Conduit is a logical grouping of communication assets that protects the security of the channels it contains in the same way that a physical Conduit protects cables from physical damage • Channel is a specific communication link established within a communication conduit

5. Example Zones and Conduit for a Site with Multiple Plants

6. Example of Multiple Zones within a Single Plant

7. Granularity of Zones and Conduits The level of granularity used to identify Zones and Conduits will depend on various factors which include: • Size of IACS • Location of IACS components • Company policy and organization • Type of assets associated with IACS • Criticality of assets associated with IACS

8. Security Levels • The Security Level model proposed in the standard provides the ability to categorize risk associated with a Zone or Conduit • Security Level corresponds to the required effectiveness of technical or administrative countermeasures and inherent security properties of IACS components within a Zone or Conduit • Security capabilities of IACS components and implemented technical and administrative countermeasures must function with each other to achieve a desired Security Level • A minimum of three Security Levels have been proposed in the ISA-99 standard. Each organization should establish a definition of what each SL represents

9. Target Security Level for Zone or Conduit • SL(Target) – Target SL is assigned to a Zone or Conduit during risk assessment • Factors that influence determination of SL(Target) for a Zone are: • Network architecture with defined zone boundaries and conduits • SL(Target) of the zones with which the zone under consideration will communicate with • SL(Target) of conduit, if assigned, used for communication by the zone • Physical access to devices and systems within the zone

10. Conduct Risk Assessment and Assign Target Security Level to Zone or Conduit • Qualitative approach - Example using a Risk Matrix • Quantitative approach using risk measures based on consequence and incident frequency estimation • In both cases, target SL determines the required effectiveness of technical and administrative security countermeasures that will reduce the incident frequency and thereby the risk to an acceptable level

11. Identify Incident Scenarios for each Zone or Conduit • Take into consideration all possible scenarios, considering all internal and external threats, that can lead to an incident • Internal threats: Untrained or disgruntled employees • External threats: Connection to the Internet or allowing partner companies to access IACS components Typical DCS Connections

12. Identify countermeasures to Achieve Target Security Level for Zone or Conduit • Qualitative approach – Selection from a combination of prescriptive technical and/or administrative counter-measures corresponding to each SL • Quantitative approach – Conduct an analysis taking into consideration event frequencies and probability of failure of countermeasures Example quantitative analysis for an Windows based HMI

13. Security Level Achieved for Zone or Conduit • SL(Achieved) depends several factors: • SL(Capability) of countermeasures associated with zone or conduit and inherent security properties of devices and systems within the zone or conduit • SL (Achieved) by the zones with which communication is to be established • Type of conduits and security properties associated with the conduits used to communicate with other zones (zones only) • Effectiveness of countermeasures • Audit and testing interval • Attacker expertise and resources available to attacker • Degradation of countermeasures and inherent security properties of devices and systems over time • Available response time on intrusion detection

14. Security Level Capability of Devices, Systems, and Countermeasures • SL(Capability) is a measure of the effectiveness of the countermeasure, device, or system for the security property that they address • Example security properties: • proving peer entity authenticity • preserving authenticity and integrity of messages • preserving confidentiality of messages/information/communication • ensuring accountability • enforcing access control policies • preventing denial-of-service attacks • maintaining platform trustworthiness • detecting tampering • monitoring security status

15. Security Level Capability of Devices, Systems, and Countermeasures … • SL(Capability) – Qualitative measure until sufficient quantitative data on probability of failure is available • An evaluation of the effectiveness of technical countermeasures shall take into consideration: • Development process – Availability of written procedures, quality management plan etc, which help reduce systematic errors such as software bugs, memory leaks etc. that may impact security • Testing – Level of testing for each security property addressed by the countermeasures, device or system. Test data may also be inferred from previously assessed systems. • Data Collection – Number of times a zone or conduit was compromised due to a flaw in a similar countermeasure, device or system. Rate and criticality of vulnerabilities discovered for the countermeasure, device or system • Administrative countermeasures shall be used when technical countermeasures are not feasible

16. Maintain Effectiveness of Technical and Administrative Countermeasures • Countermeasures and inherent security properties of devices and systems will degrade over time due to • discovery of new vulnerabilities • improved attackers skills • attacker familiarity with existing countermeasures, • availability of better resources to attackers • The effectiveness of countermeasures and inherent security properties of devices and systems shall be audited and/or tested at regular intervals and whenever new vulnerabilities are discovered based on procedures that will audit and/or test at least the security properties relevant to the zone. • Countermeasure shall be updated and upgraded based on audit and testing results to maintain SL(Achieved) equal to or better than SL(Target)

17. Security Level Lifecycle Model

18. Questions?