Downloaded 197 times
Uploaded byJim Gilsinn
Evaluating System-Level Cyber Security vs. ANSI/ISA-62443-3-3
The document presents an evaluation of system-level cyber security in alignment with ANSI/ISA-62443-3-3 standards, detailing a project by Kenexis Consulting. It outlines a step-by-step approach to assessing a vendor-assembled system's security requirements, from defining the system to reporting results. Key steps include determining applicable requirements, developing use cases, and reassessing requirements based on system features and configurations.
More Related Content
Similar to Evaluating System-Level Cyber Security vs. ANSI/ISA-62443-3-3
Evaluating System-Level Cyber Security vs. ANSI/ISA-62443-3-3
- 1. Evaluating System-Level Cyber Securityvs. ANSI/ISA-62443-3-3 Jim Gilsinn Kenexis Consulting June 3-5, 2014 ICSJWG Spring 2014 1
- 2. Jim Gilsinn • SeniorInvestigator, 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 • Networksegmentation 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 • CommonControl 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
- 20. Questions • Jim Gilsinn •Senior Investigator, Cybersecurity • Kenexis Consulting, http://www.Kenexis.com • Phone: +1-614-323-2254 • Email: Jim.Gilsinn@Kenexis.com • Twitter: @JimGilsinn • LinkedIn: http://www.linkedin.com/in/jimgilsinn/ • SlideShare: http://www.slideshare.net/gilsinnj June 3-5, 2014 ICSJWG Spring 2014 20
Editor's Notes
- #2 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.
- #3 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.
- #4 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.
- #5 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.
- #6 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.
- #7 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
- #8 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.
- #9 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.