Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NERC CIP Version 5 and Beyond – Compliance and the Vendor’s Role

1,069 views

Published on

Presenter: Joseph Loomis, Southwest Research Institute (SwRI)

Asset Owners face challenges as they strive towards implementing the NERC-CIP V5 requirements. Meeting the requirements often require documentation and technical knowledge of how an asset operates that can only be provided by a Vendor. Vendors, likewise, may be unclear about how the NERC-CIP requirements affect them, and are unsure about how to meet the technical requirements. In this presentation we detail the lessons learned from a recent project where SwRI worked with a Vendor to determine how the requirements apply to them and what the Vendor needs to have to help support an Asset Owner in an audit.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

NERC CIP Version 5 and Beyond – Compliance and the Vendor’s Role

  1. 1. NERC-CIP V5 and Beyond Compliance and the Vendor’s Role Joe Loomis Group Leader Embedded Systems Security Group Intelligent Systems Department 9/25/2015 1
  2. 2. Outline • Changes in V5 • Vendors, Asset Owners, and Compliance • The Vendor’s Role • Case Study o Background o Compliance Roadmap Development Approach o Test Plan • Beyond Version 5 • Conclusion 9/25/2015 2
  3. 3. Audience Survey • Asset Owners? • Vendors? • Compliance and Auditing? 9/25/2015 3
  4. 4. Changes in Version 5 • Bright-line criteria for identify Critical Cyber Assets (CCA) • Risk Assessment Process • Terminology • Guidance and Technical Basis (GTB) 9/25/2015 4
  5. 5. Vendors, Asset Owners and Compliance • Standards apply to entity Facilities that are part of the Bulk Electric System (BES) • Compliance is sole responsibility of the Asset Owner of the Facility • Vendor’s product deployed in a Facility may be considered part of a BES Cyber System • Asset Owner responsible for demonstrating compliance of product… 9/25/2015 5
  6. 6. The Vendor’s Role • Asset Owners often rely on technical data from Vendor to demonstrate compliance • As a Vendor, you may want to provide technical data to the Asset Owner to support a compliance audit • Question: What requirements may the Vendor’s product be subject to? (to furnish technical data) 9/25/2015 6
  7. 7. Case Study Vendor of a Bulk Cyber System Technology 9/25/2015 7
  8. 8. Background • Vendor currently has a product which may be used within a BCS. • Asset Owners request that Vendor furnish technical data to prove that product can meet NERC-CIP V5 requirements • Vendor approached SwRI to help understand requirements and develop technical data • Product Details: Provides protocol level translation (e.g., DNP3, MODBus), analytics, and edge processing 9/25/2015 8
  9. 9. Outline of Approach • Compliance Roadmap o Determine requirements applicability o Assess current state of compliance o Develop guidance on what technical information may need to be generated; or what product updates may be needed • Test Plan o Based on requirements, develop test cases to verify compliance in-house and also through using a third-party 9/25/2015 9
  10. 10. Compliance Roadmap Development • Categorize System o Impact Criteria of BES Cyber System? Low, Medium, High o Determine what Cyber Asset category or categories the product fits in • Map to Requirements o Based directly on Impact and Cyber Asset category • Assess State of Compliance o Review product documentation, development documentation, software and conduct interviews with developers • Develop Guidance o Based on Requirement’s Guidance and Technical Basis (GTB) and professional experience 9/25/2015 10
  11. 11. Categorization • Categorization is of requirements affecting Product is based on the Facility where product is deployed (CIP- 002-5.1) and the type of system the Product is a part of: o Impact Criteria: High, Medium, and (Low) o Cyber Asset Category: “EACMS”, “PACS”, “PCA” • Since the Vendor does not know where their Product will be deployed, conservative assume High Impact criteria • Cyber Asset Category based on actual product function and usage. In this case Product is a protected cyber asset “PCA” 9/25/2015 11
  12. 12. Mapping • Each Requirement in the standard specifies the Impact Criteria and associated system 9/25/2015 12
  13. 13. Mapping Criteria • Based on Vendor’s product create a Matrix which maps to the Requirements • Determine applicability criteria and later assess state of compliance 9/25/2015 13
  14. 14. Mapping Matrix • Vendor solution column indicate which requirements apply. • Product column indicates state of compliance (redacted) 9/25/2015 14
  15. 15. Developing Guidance • Based on professional experience performing security assessments and Requirement Guidance and Technical Basis (GTB) sections o Note that GTB sections are not legally binding and is only one way of interpreting standards 9/25/2015 15
  16. 16. Test Plan • Provides tests for Product to determine if it meets requirements • Based on SwRI’s risk-based assessment methodology • May include tests for vulnerabilities that go beyond CIP requirements • Can be executed by the vendor during development or by a trusted Third Party 9/25/2015 16
  17. 17. Beyond Version 5 • Version 6 Filed and Pending Approval • Version 7 – Final Draft 02/02/15 – Not Yet Filed 9/25/2015 17
  18. 18. Version 6 Major Changes • Identifies, Assesses, and Corrects Removed • (New) CIP-006-6 – R1.10 – Physical Security for Cabling …. Or 9/25/2015 18
  19. 19. Version 7 Changes (1 of 2) • New Terms: LERC and LEAP 9/25/2015 19
  20. 20. Version 7 Changes (2 of 3) • Definition for Transient Cyber Asset • Definition for Removable Media 9/25/2015 20
  21. 21. Version 7 Changes (3 of 3) • CIP-010-3 – R4 – Transient Cyber Asset and Removable Media Plan o 1.1 – Transient Cyber Asset Management ... o 1.3 – Software Vulnerability Mitigation o 1.4 – Introduction of Malicious Code Mitigation o -- Similar to Section 2 o 2.1 – Software Vulnerabilities Mitigation o 2.2 – Introduction of Malicious Code Mitigation 9/25/2015 21
  22. 22. Final Thoughts 9/25/2015 22
  23. 23. Conclusion • For more information please contact o Joe Loomis o jloomis@swri.org o (210)-522-3367 Custom solutions that immediately improve security 239/25/2015

×