Evaluating System-Level Cyber Security vs. ANSI/ISA-62443-3-3
-
Upload
jim-gilsinn -
Category
Technology
-
view
677 -
download
7
description
Transcript of Evaluating System-Level Cyber Security vs. ANSI/ISA-62443-3-3
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