Risk in CIP-013

When FERC ordered NERC to develop a new standard to address supply chain security in Order 829 in July 2016, they specifically required “a new or modified Reliability Standard that addresses supply chain risk management for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.”

Note that FERC ordered that the new standard address “supply chain risk management”. Contrast this with the other CIP standards. For example, the purpose of standard CIP-007-6 is “To manage system security by specifying select technical, operational, and procedural requirements in support of protecting BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES).”

Note that this says nothing about risk; the standard’s purpose is simply to “manage system security”. And how is this done? Through specifying “select technical, operation and procedural requirements”. In complying with and auditing these requirements, risk isn’t considered at all.

FERC could well have taken the same approach in ordering a supply chain standard. They might have simply provided a list of say 20 practices that contribute to supply chain security and told NERC to develop a requirement for each item on the list. In that case, CIP-013 would simply be a set of individual prescriptive requirements, like the CIP version 5 standards.

Fortunately, they didn't do this, which is why the CIP-013 standard just has three requirements. In essence, these are:

R1. Develop a supply chain cyber security risk management plan.

R2. Implement that plan.

R3. Review the plan annually.

Clearly, the risk management plan forms the heart of CIP-013 compliance. What is a risk management plan? It is a plan that

a)      Identifies all the current threats applicable to a particular subject area (in this case, supply chain cyber security);

b)      Classifies each threat according to the risk it poses; and

c)      Prioritizes remediation activities according to the degree of risk posed by each threat.

Why did FERC choose to take this approach? They state “In making this directive, the Commission does not require NERC to impose any specific controls, nor does the Commission require NERC to propose ‘one-size-fits-all’ requirements.” They also state “In particular, the flexibility inherent in our directive should account for, among other things, differences in the needs and characteristics of responsible entities and the diversity of BES Cyber System environments, technologies and risks. For example, the new or modified Reliability Standard may allow a responsible entity to meet the security objectives discussed below by having a plan to apply different controls based on the criticality of different assets.”

In other words, FERC is saying that, when it comes to supply chain security, all systems and vendors shouldn’t be treated the same in the new standard. Instead, the NERC entity’s supply chain cyber security risk management plan should take risk into account in determining what controls are appropriate for a particular vendor or system. By the same token, auditors shouldn’t require that an entity put in place the same controls for all of its vendors or systems; instead, the auditors should understand that the controls need to be appropriate to the level of risk in each case.

This should be understood as good news by NERC entities who have to comply with CIP-013. One of the common complaints about other CIP standards is that they don’t take risk into account; if a requirement mandates a particular control, it has to be applied in exactly the same way to every system in scope for that requirement, regardless of the risk posed by that system. This often results in a misallocation of resources to less-important activities vs. more-important ones (such as anti-phishing measures) that aren’t addressed in CIP at all.

For example, in CIP-007 R2 Patch Management, the entity is required to ascertain monthly, for every software application installed on a Medium or High impact BES Cyber System or Protected Cyber Asset, whether or not the vendor (or the designated patch source) has released a new security patch. There is no consideration of how important the software, or the system running it, is to the Bulk Electric System. There is also no consideration of whether the software vendor in question regularly releases security patches, or indeed whether they ever have released a security patch. Each vendor must be checked monthly.

Were CIP-007 R2 a risk-based requirement, the entity would be able to take a number of steps that would significantly reduce their compliance burden, without meaningfully impacting their security posture. For example, the entity could tier their software applications by the risk that the misoperation or failure of each application poses to the BES. For the lower-risk applications, the entity might not feel obliged to check for new patches every month. This step alone (and it is just one of a number that might be taken, were CIP-007 R2 a risk-based requirement) would noticeably reduce the compliance burden of this requirement.

Since many NERC entities are now beginning to plan for compliance with CIP-013, what does the fact that the standard is risk-based mean for their compliance plans? CIP-013 compliance will be very different from compliance with previous CIP standards, and a full discussion of how to comply is beyond the scope of this white paper. However, the risk-based nature of CIP-013 dictates the following:

1.      The entity needs to understand that the “risk” applicable to CIP-013 compliance is very different from the “risk” applicable to other cyber security standards, such as NIST 800-53. In the latter standard, systems are tiered by risk to the organization. For example, if the loss of a particular system could have a significant impact on the organization’s finances, it will be considered high risk. In CIP-013 (as well as other CIP standards or requirements that consider risk, including CIP-014 and CIP-007 R3), “risk” means “risk to the Bulk Electric System”. So even though the loss of a system would have a significant financial impact on the organization, that consideration is completely irrelevant in CIP-013. Conversely, the loss of a particular control system could have a large BES impact, but it might not even be noticed by personnel not part of Operations. Yet it would almost surely need to be classified as high risk for CIP-013 compliance purposes.

2.      CIP-013 only applies to Medium and High impact BES Cyber Systems. Should the entity simply assign a medium CIP-013 risk level to all Medium impact BCS, and a high risk level to all High impact BCS? While this is certainly permissible, it would probably be a mistake. This is because the Medium and High impact ratings are based solely on the asset (substation, Control Center, etc) at which the BCS is located, not on any inherent characteristics of the BCS itself. For example, most NERC entities would probably agree that the Energy Management System in a High impact Control Center would be high risk, since its loss would almost inevitably have a huge impact on the BES and on the area it manages. But how about the GPS clock? Maybe it should be classified as medium or even low risk, since its loss would cause much less impact on the BES than the loss of the EMS. Whatever the final classification, the entity now has the flexibility to assign different controls to the GPS clock than to the EMS. Especially for large entities with potentially thousands of BCS and hundreds of vendors in scope for CIP-013, this flexibility can mean a huge savings in compliance costs.

3.      There is nothing magic about having three risk levels. There will always be a tradeoff between the increased flexibility in controls afforded by having more levels and the increased risk of confusion and complication. The entity needs to decide early on how many levels are appropriate in its case; the more systems and vendors in scope at the entity, the more risk levels might be appropriate.

4.      Once “risk” is properly understood in the context of CIP-013 compliance, the entity needs to develop criteria for classifying both vendors and systems in scope by the risk they pose to the BES. This step isn’t explicitly required by CIP-013, but in a future audit the entity will most likely be asked to show their risk criteria to the auditor. If vendors and/or systems aren’t classified by any particular criteria but are simply assigned to their risk category according to somebody’s “gut feel”, the auditor is likely to be concerned; it will lead to the suspicion that the entity might be hiding the fact that they have chosen to give a lower risk rating than warranted to some vendors and/or systems – simply to make their compliance burden easier.

5.      When the risk criteria are identified, the entity should classify its vendors and systems (those in scope for CIP-013) by risk. At that point, the entity needs to determine the types of controls appropriate for each risk level.