This post is part of a coordinated series of blog posts examining the details of version 5 of the NERC Critical Infrastructure Protection (CIP) standards. These posts, written by various individuals having direct experience with these standards, will point out security gaps, ambiguities, and areas that could prove challenging to audit. The purpose of the posts is to highlight areas for future improvement, and to draw attention to issues for which entities may wish to apply greater diligence than is currently required by regulation.
Stacy Bresler, The Anfield Group
A bit of history (but not a history lesson)
The requirement to establish an Information Protection Program (or something similar) has existed in the CIP standards from the very beginning. When I say very beginning, I mean since FERC’s Standard Market Design (SMD) Notice of Proposed Rulemaking (NOPR) Appendix G (called the Cyber Security Standards for Electric Wholesale Market Operations Participants) where it had a single sentence that stated:
Critical electric facilities shall restrict the distribution of maps, floor plans and equipment layouts pertaining to those facilities, and restrict the use of signage indicating critical facility locations.
Since that NOPR failed, Urgent Action Standard 1200 was created in 2003 and had this to say about information protection (1210):
The entity performing the reliability authority, balancing authority, interchange authority, transmission service provider, transmission operator, generator, or load-serving entity function shall protect information associated with critical cyber assets and the policies and practices used to keep them secure.
This was further defined in the measures section:
The responsible entity shall maintain a document identifying the access limitations to sensitive information related to critical cyber assets. At a minimum, this document must address access to procedures, critical asset inventories, maps, floor plans, equipment layouts and configurations.
Jumping ahead to the currently enforceable CIP standards
CIP-003-3 R4, R5 and CIP-007-3a R7 make up the controls required to help prevent the undesired release of potential information associated with Critical Cyber Assets (CCA) and their associated Electronic Access and Monitoring Systems (EACMS) as required by CIP-005-3a R1.5 and Physical Access Control Systems (PACS) as required by CIP-006-3c R2.2. CIP-007-3a R7 also includes all cyber assets within the Electronic Security Perimeter.
Version 3 specifically states what kind of information, regardless of media, associated with this set of cyber assets that shall be (at a minimum) protected. Here is the list from CIP-003-3 R4:
- Operational procedures
- Lists as required in Standard CIP-002-3
- Network topology or similar diagrams
- Floor plans of computing centers that contain Critical Cyber Assets
- Equipment layouts of Critical Cyber Assets
- Disaster recovery plans
- Incident response plans
- Security configuration information
As you can see, this requirement has become more prescriptive. It certainly ended up being more clear and auditable over time.
The future of information protection in CIP version 5
Every security professional will tell you that an information protection program is a fundamental component of any basic cyber security program and, rightfully so, it is included within the CIP-011-1 standard (notice the dash 1).
Let’s take a look at what CIP-011-1 says about information that needs to be protected. First we have to look up the definition of BES Cyber System Information in the NERC Glossary of Terms:
Information about the BES Cyber System that could be used to gain unauthorized access or pose a security threat to the BES Cyber System. BES Cyber System Information does not include individual pieces of information that by themselves do not pose a threat or could not be used to allow unauthorized access to BES Cyber Systems, such as, but not limited to, device names, individual IP addresses without context, ESP names, or policy statements. Examples of BES Cyber System Information may include, but are not limited to, security procedures or security information about BES Cyber Systems, Physical Access Control Systems, and Electronic Access Control or Monitoring Systems that is not publicly available and could be used to allow unauthorized access or unauthorized distribution; collections of network addresses; and network topology of the BES Cyber System.
Audit alert: Previously in CIP Version 3 it was stated that, regardless of media, the information protection program “shall include, at a minimum…” specific types of information. This new definition states “Examples of BES Cyber System Information may include…”. Using “May instead of “Shall” could open up a can of worms in an audit. “Shall” was clear and prescriptive (relatively). “May” is unclear and subjective. And that isn’t event counting the first sentence which appears to be putting the Responsible Entity in a position of determining which “pieces” of information may or may not be useful to a malicious actor. I get where the SDT was going but I don’t think this is the correct definition to assure the right kind of information is being protected. Putting that aside for a moment…this definition tells me that an Information Protection Program better be incredibly detailed and specific. Vagueness leads auditors to use more of their professional judgement and that often leads to more potential violations. I understand that many utilities wanted more flexibility in the CIP standards but with that comes greater responsibility not to mention potentially a lot more work!
So…using the new definition of BES Cyber System Information, we have the following requirements for High and Medium BES Cyber systems and associated EACMS and PACS (no Protected Cyber Assets in this requirement):
R1 Each Responsible Entity shall implement, in a manner that identifies, assesses, and corrects deficiencies, one or more documented information protection program(s) that collectively includes each of the applicable requirement parts in CIP‐011‐1 Table R1.
R1.1 Method(s) to identify information that meets the definition of BES Cyber System Information.
R1.2 Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use.
That’s it. Not wrong just not very clear and prescriptive when based on a BES Cyber System Information definition that is far too “flexible” and onerous IMHO. Also, what is up with not including Protected Cyber Assets (PCA)? Is it not possible that information about this set of assets could lead to a potential compromise of a BES Cyber System? To be fair, those assets where included in previous versions of the CIP standards either.
I understand that you can’t write a requirement that will address every scenario. Writing standards is hard work – I applaud the dedication of those who volunteered their time to be part of the Standards Development Team (SDT). Still…I think we can all do better. “We” means the industry not a specific organization, team or person.
This definition/requirement combination is a tar pit for potential violations waiting to happen. I promise you that it will not be as easy as the CIP-003-3 R4/R5 requirement if you try to leverage the flexibilities afforded in CIP-011-1 R1. My advice, stick with your version 3 Information Protection Program with some slight modifications in language and don’t try to get fancy. Be detailed in your explanation of what is and is not BES Cyber System Information.
The move to move CIP-007-3a R7 to CIP-011-1
This is the good part of CIP-011-1. Moving the CIP-007-3a R7 requirements to align with the information protection requirements was a good move.
CIP-011-1 R2 addresses several of the challenges that utilities had with CIP-007-3a R7 which was the Redeployment and Disposal requirements. One of the primary issues was regarding what to do with a cyber asset that may need to be disconnected from an Electronic Security Perimeter (ESP) and removed from a Physical Security Perimeter (PSP) but isn’t being redeployed or disposed. This was a conundrum that resulted in several potential violations being written for utilities who removed a cyber asset from the Physical Security Perimeter without implementing its “data cleansing” procedures (CIP-007-3a R7).
With CIP-011-1 there are suggestions made by the SDT in the Guidance and Technical Basis portion of the standard that a custodianship process/procedure could be established that addresses this very issue:
If an applicable Cyber Asset is removed from the Physical Security Perimeter prior to action taken to prevent the unauthorized retrieval of BES Cyber System Information or destroying the data storage media, the responsible entity should maintain documentation that identifies the custodian for the data storage media while the data storage is outside of the Physical Security perimeter prior to actions taken by the entity as required in R2.
I like this idea a lot but there is not a specific requirement in the standard that clearly addresses this “option” and I believe that spells potential problems. It could be inferred in the CIP-011-1 R2.1 requirement and associated measures that a custodianship procedure would be acceptable but it isn’t clear and when something isn’t clear what do auditors do again? In addition to using their professional judgement, they may also lean on past approaches which in this case has commonly been that the asset is to be retained in the PSP until it has been cleansed per the responsible entity’s documented processes. Even the CIP-011-1 R2.1 measures state that an example of acceptable evidence could be “retaining in the Physical Security Perimeter” prior to an applicable cyber asset being reused. Of course, the requirement requires the entity to only take action to…
…prevent the unauthorized retrieval of BES Cyber System Information from the Cyber Asset data storage media.
I’m sure the custodianship statements by the SDT in Guidelines and Technical Basis section of CIP-011-1 is the right approach in the end. I’m a proponent of having more specific details when it comes to expected outcomes. If a custodianship process is that expected outcome then the requirements should provide some specifics about it.
My final thought
I feel compelled to remind everyone that the version 5 CIP standards (along with CIP-010-1 and CIP-011-1) are untested and suggested practices are guaranteed to be all over the place until which time we have had a year or two of “in-the-field” auditing behind us. Be wary of the advice you receive, be conservative in your compliance implementations and stay connected with your CIP Regional Entity auditors as much as you can. This is going to be a wild ride just like it was when CIP Version 1 audits began. Hopefully this time we are better prepared together.