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.
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 2
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 3
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 4
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 5
6. Step 1 – Defining the System
Under Consideration
Network Segmentation
Device 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 6
7. Step 1 – Defining the System
Under Consideration
Network Segmentation
Device 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
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 8
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 9
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 10
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 11
12. Step 2a – Develop Use Cases
June 3-5, 2014 ICSJWG Spring 2014 12
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 13
14. Step 2a – Develop Use Cases
June 3-5, 2014 ICSJWG Spring 2014 14
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 15
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 16
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 17
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 18
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 19
Good Morning.
My name is Jim Gilsinn, and I work for Kenexis Consulting.
We recently conducted an evaluation of a customers products to assess how well they met the capability requirements described in ANSI/ISA-62443-3-3.
I’m here today to talk to you all about the methodology that Kenexis used to conduct this assessment.
First, a little bit about myself.
I joined Kenexis Consulting as a Senior Investigator for Cybersecurity in late 2012.
We specialize in taking a system-wide approach to assessing, designing, and validating ICS networks and security.
I am also the current Co-Chair of the ISA99 committee, the Co-Chair of the working group developing the 62443-2-1 standard on an ICS security program, and the liaison to the ISO/IEC committee developing the 2700x series of standards.
Previously, I spent 20 years in the Engineering Laboratory at NIST working on a variety of projects from ICS network performance tests and tools, wireless sensors, embedded sensor design, software design, robotics, and controls.
This is an overview of my talk today.
I’ll start by giving you a little bit of information about our project.
I’ll then go over a brief description of how the 62443-3-3 standard is organized, for those that aren’t familiar with it.
Then, I’ll move on to describing the steps in our methodology.
Step 1 – The first step in the project was to determine what constituted the System under Consideration
Step 2 – The next step was to determine the requirements that were applicable to the system. As part of this step, some basic use cases were developed to help determine which requirements should be excluded.
Step 3 – The third major step was to actually conduct the assessment. After the primary assessment was complete, the use cases were updated to reflect any additional information gained while conducting the assessment. As a final part to this step, it may be necessary to reassess some of the requirements if new information becomes available.
Step 4 – The final step in the process is reporting the results.
I should have time for questions at the end of my talk.
A vendor of network segmentation products approached Kenexis to conduct an assessment of one of their devices against 62443-3-3.
After some discussion, we reached the conclusion that it would be better to evaluate a series of products including the hardware device itself, some of the related software products, and an accompanying web-based database instead of just the hardware device itself.
This system actually matched up better to how their customers were purchasing and implementing their products.
They wanted to assess their system of products against the ANSI/ISA-62443-3-3 standard.
It describes capability requirements that need to be implemented in industrial control systems.
The method we used to collect data for the project is similar to many other consulting projects, we conducted interviews with staff members from the customer, we reviewed the product manuals, and we observed and interacted with the system in a lab environment.
I’m not going to go deeply into the ANSI/ISA-62443-3-3 standard or the other documents in the 62443 series.
I just wanted to explain how the requirements are broken down to those not familiar with it and explain how that affected our process.
The first clause with requirements in the standard are what are called “Common Control System Constraints”
These generally deal with issues that cross over all the different Foundational Requirements.
The Common Constraints are also generally associated with security not affecting safety or other essential functions for the control system.
The majority of the requirements in the requirements in -3-3 are contained within each of the Foundational Requirements sections.
Each of these sections represents a different aspect of cybersecurity.
It goes above and beyond the normal CIA since there are more aspects to ICS cybersecurity that don’t relate to the normal IT categories.
Also, aspects like Identification and Authentication and Use Control are extremely important with a large number of requirements, but arguably have no direct correlation to CIA aspects.
Within each of the FRs, there are individual System Requirements consisting of a base requirement and zero or more requirement enhancements.
The REs allow the standard to expand its required capabilities depending on the level of capability the system is built to attain.
Now, getting into the actual steps we took to conduct the assessment.
The first step was to decide what components actually constituted the system under consideration for the -3-3 assessment.
The vendor gave us a list of 6 different products that they sell.
A hardware network segmentation device
A software module to securely transfer files across the zone boundary
A web-based database for audit logging and monitoring
And 3 application-specific file and network traffic transfer software packages
Inside the hardware component there were some additional components that were base components for the network segmentation
A secure Linux-based operating system
A network data transfer system
A basic file transfer system
And a virus and malware checking system
The core features that were considered part of the system related to the capability to:
Control access to the different components
Transfer network traffic and files in a controlled manner across the network zone boundary
Prevent malicious network traffic and files from spreading across the zone boundary
Provide some measure of audit logging and monitoring
Features like moving specific types of network traffic or files were not relevant to the cyber security aspect of the system, so they were removed from the assessment.
These were kept as good use cases for consideration as part of the project.
But, they didn’t represent a core feature that would affect the overall cyber security aspects of the capability requirements.
One thing to realize is that this was strictly a cyber security feature capability assessment.
Kenexis was not asked to do a code review or detailed vulnerability assessment of the system.
Those get into the actual implementation of the hardware and software components and were outside the scope of a functional capability assessment.
Out of the 110 requirements and requirement enhancements contained within -3-3, some will not apply to the system under consideration for various reasons.
Many of the requirements in -3-3 were written with an end-user implementation focus.
In this case, we were evaluating a vendor’s system of components.
Some of the reasons that requirements were eliminated from consideration were:
They had to do with end-user implementation of the product and were not something that the system would be capable of implementing
They applied to technology that was not implemented at all within the system
It related to technology that was outside the control of the system under consideration
Were out of scope based upon specific user documentation recommending against using the system in that way.
I understand that people always take things and implement them in ways that the vendor probably didn’t anticipate, but when the vendor expressly tells the user not to implement their products in a certain way, then the user is assuming the risk for any associated weaknesses they introduce into the system.
I’ll explain a little bit more about the implementation and outside control with some examples, which may make it easier to understand.