Two-Part Webinar Part One: MRO Socialization of 2016-02 CIP SDT - PowerPoint PPT Presentation

Two-Part Webinar Part One: MRO Socialization of 2016-02 CIP SDT Draft Virtualization Changes Part Two: Risk Considerations for BCSI in the Cloud Brian Kinstad, Sr. Risk Assessment and Mitigation Engineer MRO Jay Cribb and Matthew Hyatt, Project 2016-02 CIP Standard Drafting Team Co-Chairs December 12, 2019

2016-02 CIP SDT Virtualization Timeline 2016-02 CIP Standard Drafting Team nomination: March 2016 Unresolved issues (including virtualization) transitioned from CIPv5 Standard Drafting Team: July 2016 Virtualization became a dedicated effort in 2017 Early virtualization terms developed and socialized through comment request: November 2017 Drafts posted for informal comment: December 2018 Industry comments addressed through June 2019 CIP-005-7 draft + definitions informal posting: September 2019

WIFM-What’s in it for Me? (Us?) Properly configured VLANs get security credit above low impact Properly configured hypervisors (with policies and affinity rules) can span zones of different trust levels Super ESP architecture permitted • Contiguous logically isolated perimeter that spans disparate geographic locations

What’s in it for Me? Objective-based approaches extended into CIP-007 • Protections for logical ports on Shared Cyber Infrastructure (SCI–new term) elevated to the service level • System hardening and malicious code mitigation relief for Electronic Access Monitoring Systems (EAMS–new term) CIP-010 baseline administration simplified • Baseline and baseline tracking eliminated (shift to change detection). Change management retained. • Logical isolation elements added to change management

Control Center Today

Control Center of Tomorrow

Control Center Tomorrow Extended Post webinar clarification: Example is theoretically possible, but current hypervisor technology does not generally support pinning physical memory and physical CPU cores to specific virtual machines

Substation with Medium Impact BCS Today

Substation with Medium Impact BCS Tomorrow

2016-02 CIP SDT Project Update Jay Cribb Matthew Hyatt Project 2016-02 Co-Chairs

BCSI in the Cloud Risk Considerations

BCSI in the Cloud Risk Considerations Risk considerations from a BCSI in the Cloud perspective: • Service Level Agreements (SLAs) • Protection of data in use • Service models • Encryption • Certifications • Data sovereignty • Data transformation

Service Level Agreements (SLA) Governance for vendor access to entity data  Risk Neutral  Risk Increaser if absent Governance for evidence transmittal for vendor access  Risk Reducer Vendor program declaration for • Encryption or encryption key management processes  Risk Neutral  Risk Increaser if absent • Entity specific data sanitization and disposal methods  Risk Neutral  Risk Increaser if absent • Background verification of vendor personnel  Risk Reducer Containerization of entity content  Risk Neutral  Risk Increaser if absent General entity autonomy  Risk Reducer for full autonomy  Risk Increaser for none

Protection of Data in Use Three states of electronic data: At Rest, In Transit, In Use Electronic data in Use • Wikipedia: Active data which is stored in a non-persistent digital state… typically in RAM, CPU caches, or registers • MRO: Data that is processed in Real-time by a Cyber Asset, and is not at rest or in transit Data enters ‘in use’ state within vendor infrastructure  Risk Increaser Access controls for data in use by vendor  Risk Neutral Cloud hybrid solution on premise  Risk Reducer Encryption of data in use (homomorphic encryption – future technology)  Risk Reducer

Service Models SaaS (Software as a Service)  Risk Increaser PaaS (Platform as a Service)  Risk Increaser IaaS (Infrastructure as a Service)  Risk Increaser? If service model has tertiary cloud dependencies  Risk Increaser There is not much risk difference between the service models. All have potential vendor access to data

Encryption of Data at Rest or in Transit Cipher strength (RSA-xxx, SHA-xxx, AES-xxx) • If meeting or exceeding current NSA/NIST requirements  Risk Reducer • If public vulnerabilities for cipher are known  Risk Increaser Consider NSA sources and NIST requirements: • https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm • https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf Encryption typically required in cloud environment • CIP equivalent physical protections in place of encryption  Risk Neutral • Encryption absent and no physical protections  Risk Increaser

Certifications Most certifications or accreditations only offer risk considerations for the underlay Examples: • FedRAMP  Risk Neutral • SOC 1 Not applicable, attestational in nature • SOC 2 (Type 1, 2) ─ If the report describes program (Type 1) and performance (Type 2) adequacies under Security, Processing Integrity, and Confidentiality headings  Risk Neutral ─ If report identifies inadequacies  Risk Increaser • SOC 3  Risk Neutral with compliance seal,  Risk Increaser without • Other  Risk Neutral; draw comparisons with known certifications • Certification absent?  Risk Increaser

Data Sovereignty A consideration related to the potential geographic location of the data • Certification or agreement declaration of US Domestic Only  Risk Neutral • Certification or agreement declaration of US or Canada Domestic Only (Canadian entities)  Risk Neutral • International or undeclared  Risk Increaser

Data Transformation Encryption: A strong but reversible means to protect data  Risk Neutral Obfuscation: A reversible clear text replacement according to a key. Easy to reverse engineer.  Risk Increaser • Obfuscation in Real-time communication protocols where efficient data processing is required (typically not BCSI)  Risk Neutral • Lines between obfuscation and encryption can be blurred. When assessing risk, assess obfuscation qualities against encryption benchmarks. Redaction: Some electronic formats retain redacted content  Risk Neutral Sanitization – Permanent and irreversible transformation of data  Risk Reducer

Conclusion “BCSI in the Cloud” risk considerations overlap and should be considered collectively MRO will use professional judgement based on the BCSI in the Cloud risk considerations, and the “ ERO Enterprise CMEP Practice Guide ” to determine overall compliance risk

References ERO Enterprise CMEP Practice Guide • https://www.nerc.com/pa/comp/guidance/CMEPPracticeGuidesDL/ERO%20Enterprise%20CMEP%20Practice%20Gu ide%20_%20BCSI%20-%20v0.2%20CLEAN.pdf 2019-02 Project Page • https://www.nerc.com/pa/Stand/Pages/Project2019-02BCSIAccessManagement.aspx CIPC Security Guideline, Cloud Computing • https://www.nerc.com/comm/Pages/Reliability-and-Security-Guidelines.aspx Homomorphic encryption: • https://en.wikipedia.org/wiki/Homomorphic_encryption Data Sovereignty: • https://en.wikipedia.org/wiki/Data_sovereignty Obfuscation in software: • https://en.wikipedia.org/wiki/Obfuscation_(software) Sanitization: • https://en.wikipedia.org/wiki/Sanitization_(classified_information)

HEROS@mro.net 22