evaluating system-level cyber security vs. ansi/isa-62443-3-3
DESCRIPTION
With the recent publication of ANSI/ISA-62443-3-3-2013, it is possible for end-users, system integrators, and vendors to qualify the capabilities of their systems from an ICS cyber security perspective. This process is not as simple as it may seem, though. In many cases, the capabilities of individual components of a system can be determined from specifications and manuals. The capabilities of the system also needs to be evaluated as a whole to determine how those individual components work together. Component-level and System-level certifications are common practice in the safety environment, and will eventually become common in the ICS cyber security environment as well. Certification bodies, like the ISA Security Compliance Institute (ISCI), have begun the process to develop certification efforts around ISA-62443-3-3. Until many more groups of components and systems have been officially certified, third-party assessments and evaluations will be common. This presentation will discuss an example of how Kenexis Consulting has evaluated a particular vendor’s components and systems to determine compliance with ISA-62443-3-3. The presentation will go through the evaluation methodology used and describe how Kenexis used the evaluation to develop a series of real-world use-cases of the components and system in the ICS environment.TRANSCRIPT
ICSJWG Spring 2014 1
Evaluating System-Level Cyber Security vs.
ANSI/ISA-62443-3-3
Jim GilsinnKenexis Consulting
June 3-5, 2014
ICSJWG Spring 2014 2
Jim Gilsinn
• Senior Investigator, Cybersecurity @ Kenexis Consulting
• International Society of Automation (ISA)• Co-Chair, ISA99 Committee• Co-Chair, ISA99 WG2, IACS Security Program• Liaison to ISO/IEC JTC1/SC27 WG1 & WG3
• Previously Electrical Engineer @ NIST
June 3-5, 2014
ICSJWG Spring 2014 3
Overview
• Project Description
• ANSI/ISA-62443-3-3 Organization
• Step 1 – Defining the System Under Consideration
• Step 2 – Determining Applicable Requirements• Step 2a – Develop Use Cases
• Step 3 – Assess Requirements• Step 3a – Update Use Cases• Step 3b – Reassess Requirements
• Step 4 – Report Results
• Questions
June 3-5, 2014
ICSJWG Spring 2014 4
Project Description
• Network segmentation vendor assembled system from various components
• Hardware• Software• Web-Based Database
• Wanted an assessment relative to ANSI/ISA-62443-3-3• System-level cyber security• Capability requirements
• Kenexis:• Conducted interviews• Reviewed manuals• Viewed system in lab environment
June 3-5, 2014
ICSJWG Spring 2014 5
ANSI/ISA-62443-3-3 Organization
• Common Control System Constraints
• Foundational Requirements (FRs)• Identification & Authentication Control (IAC)• Use Control (UC)• System Integrity (SI)• Data Confidentiality (DC)• Restricted Data Flow (RDF)• Timely Response to Events (TRE)• Resource Availability (RA)
• System Requirements (SRs)• Base Requirement• Requirement Enhancements (REs)
June 3-5, 2014
ICSJWG Spring 2014 6
Step 1 – Defining the System Under Consideration
Network SegmentationDevice Web-Accessible
Audit Logging
Operating System
Basic File Transfer System
Basic Network Transfer System
Application-Specific Network Transfer
Application-Specific File Transfer
Virus & Malware File Checking
June 3-5, 2014
ICSJWG Spring 2014 7
Step 1 – Defining the System Under Consideration
Network SegmentationDevice Web-Accessible
Audit Logging
Operating System
Basic File Transfer System
Basic Network Transfer System
Application-Specific Network Transfer
Application-Specific File Transfer
Virus & Malware File Checking
June 3-5, 2014
ICSJWG Spring 2014 8
Step 2 – Determining Applicable Requirements
• Not every requirement will apply for every system
• Requirements in 62443-3-3 generally written from end-user perspective
• For vendor product systems, some requirements…• Depend on end-user implementation• Apply to technology not implemented in or outside control of the SuC
• Depends on way it is not implemented or outside control
• Are out-of-scope per vendor documentation
June 3-5, 2014
ICSJWG Spring 2014 9
Step 2 – Determining Applicable Requirements
• Example #1 (Not Applicable) – Wireless• System has no wireless interfaces itself• Same capabilities for network segmentation of wired and wireless
devices connected through system
• Example #2 (Applicable) – Multi-Factor Authentication• System provides a management interface with IAC and UC• System inherently has capability in operating system• Vendor has not been asked to implement by customers
• Example #3 (Applicable) – Unified Account Management• System provides a management interface with IAC and UC• System inherently has capability in operating system• Vendor has not been asked to implement by customers
June 3-5, 2014
ICSJWG Spring 2014 10
Step 2 – Determining Applicable Requirements
• Example #4 (Not Applicable) – Protection of Time Source Integrity
• System can utilize an existing time source on network• System has no time source capability itself (can’t act as stratum clock)• Network traffic from time source treated no differently
• Example #5 (Not Applicable) – PKI and Certificates• System doesn’t use PKI or certificate authorities
• Example #6 (Not Applicable) – Session Integrity• No TCP session information is transmitted through device• Device specifically designed to act as protocol break• Strips header information and rebuilds packets on other side
June 3-5, 2014
ICSJWG Spring 2014 11
Step 2a – Develop Use Cases
• Use cases are a useful tool when conducting assessments• Describe how different components in system interact• Help to determine when requirements apply
• Use cases should represent realistic situations• Adaptations of real cases are the best• Generalizations are necessary
• ANSI/ISA-62443-3-3 has two as a starting point• Chlorine truck loading station• Manufacturing assembly line
June 3-5, 2014
ICSJWG Spring 2014 12
Step 2a – Develop Use Cases
June 3-5, 2014
ICSJWG Spring 2014 13
Step 2a – Develop Use Cases
• Elements adapted from ANSI/ISA-62443-3-3• Business Network• Control Center• Control System• Safety System
• Modifications from ANSI/ISA-62443-3-3 use cases• Vendor System Replaces DMZ• Added Production Server Network• Expansion of Business Server Network
June 3-5, 2014
ICSJWG Spring 2014 14
Step 2a – Develop Use Cases
June 3-5, 2014
ICSJWG Spring 2014 15
Step 2a – Develop Use Cases
• Elements adapted from ANSI/ISA-62443-3-3• Business Network• Robot Cells
• Modifications from ANSI/ISA-62443-3-3 use cases• Vendor System Replaces DMZ• Added Production Server and Device Networks• Expansion of Business Server Network• Added Inspection Station
June 3-5, 2014
ICSJWG Spring 2014 16
Step 3 – Assess Requirements
• Is the requirement met by any single component in the system?
• If multiple components are needed to fulfill the requirement, do they act in a way that violates that requirement?
• In order for the component(s) to meet the requirement, do they violate other requirements?
• Are their optional configurations that allow the requirements to be met?
June 3-5, 2014
ICSJWG Spring 2014 17
Step 3a – Revise Use Cases
• It is probable that the use cases will need to be revised
• During the requirements assessment, component features or configurations may be uncovered that change the use cases in some way
• Final use cases should follow as closely as possible real system configurations
June 3-5, 2014
ICSJWG Spring 2014 18
Step 3b – Reassess Requirements
• It is possible that the system developer may have changed/added features during the assessment
• The system developer may want some of the requirements reassessed given the most recent features and/or configuration
June 3-5, 2014
ICSJWG Spring 2014 19
Step 4 – Report Results
• Reporting should include, at a minimum:• Requirement pass/fail values• Requirement pass/fail justification
• Other good things to add:• Use cases• Low-hanging fruit and longer-term changes• Potential issues that may be uncovered through use cases
June 3-5, 2014
ICSJWG Spring 2014 20
Questions
• Jim Gilsinn
• Senior Investigator, Cybersecurity
• Kenexis Consulting, http://www.Kenexis.com
• Phone: +1-614-323-2254
• Email: [email protected]
• Twitter: @JimGilsinn
• LinkedIn: http://www.linkedin.com/in/jimgilsinn/
• SlideShare: http://www.slideshare.net/gilsinnj
June 3-5, 2014