Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

1 112 vues

Publié le

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.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

×