Do you have to mitigate risk in CIP-013?

Note from Tom: If you’re only looking for today’s pandemic post, please go to my new blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

Last week, I wrote two posts on the problem caused by the fact that CIP-013-1 R1.1 tells the NERC entity to “identify and assess” supply chain cyber security risks, but doesn’t say the entity has to do anything about those risks – i.e. mitigate them. This question came up in the NERC Supply Chain Working Group’s webinar on Monday, Sept. 4. The questioner believed that, since the word “mitigate” was left out, a NERC entity that only “identifies and assesses” supply chain cyber risks in their CIP-013 R1 plan but doesn’t mitigate them, could never be found non-compliant.

In my post that day, I said “Brian’s (Brian Allen, the NERC presenter) answer to this question was good: that the Purpose statement for CIP-013 reads ‘To mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.’ This is quite clear, although another questioner (perhaps the same one) then asked if the Purpose statement in a standard is auditable. In an email to me the next day, Lew Folkerth of the RF Region, strongly agreed with both me and Brian, which I posted on Sept. 5. I thought that would probably be the end of the discussion.”

However, the next day, a consultant I’ve known for many years emailed me to say he had asked both questions, and he was still not convinced by Brian’s and Lew’s (or my) arguments. I asked him to write out why he believes mitigation isn’t required for CIP-013 compliance. When I got his email, I forwarded it to Lew Folkerth and Kevin Perry to comment. Below are the consultant’s email (I took off part that I didn’t think was needed for his argument, since it made it quite long), as well as Lew’s and Kevin’s responses. I’ll give my own response, but I’ll wait for another day to do that.

Consultant’s email

I disagree with much of what Lew is saying.

He starts off with “The enforceable language (Requirement, Applicability, Effective Date, Glossary Terms, and Implementation Plan) does not require an entity to mitigate risk ….”  I agree with what he is saying to this point but he then adds “in every case, because mitigation is not the only option in addressing risk.".  Where is mitigation included in the enforceable language?  The answer is that it is not.

The word mitigate is include in the Purpose section of the standard and twice in the Rationale section for Requirement R1 (page 11).  The last use of mitigate in the Rationale section is this: “The security objective is to ensure entities consider cyber security risks to the BES from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s); and options for mitigating these risks when planning for BES Cyber Systems."

To me, this clearly states that I must consider options for mitigating risks identified (by using my new Supply Chain Risk Management plan) in the purchasing process.  There is no reference to the mitigation of the risks.  Here is my example of applying what is required by the R1.1:

I want to purchase Equipment X. The equipment would be installed by personnel in my company. My Supply Chain Risk Management program has me perform a number of risk assessments.

Supply Chain Risk Assessment on the equipment.  Here I would look at the possibility of using other equipment.  I would consider the I there are alternative devices with acceptable capabilities and then compare the risks associated with their manufacturing and support provided by the manufacturer.  In this section, I may include the responses to the six areas included in R1.2.   A device with a known manufacturing issues and/or poor support would have a higher risk.  I may be able to choose an alternative devices, with less risk but there is no way, that I know of, to mitigate these types of risks.  For this example – the result is the Equipment X is the only choice.

A second Risk Assessment would be done on the suppliers.  This may be the same as the manufacture in which case I might combine these two assessments into one. For this example my two available suppliers are the manufacturer and Ebay.   I am looking at risk associated with the supplier; Are they an authorized reseller?, Do they have a history of selling grey market or refurbished equipment?  How do they handle returns?  Do they ship when they say they will?  How do they ship? Do they offer additional support, beyond what the manufacture provides?  Again, if they are applicable, I may include the responses to the six areas included in R1.2.    (In this example, I am excluding risks associated with a third party supplier that will also install or otherwise support the product,)  During this assessment, it is determined that both suppliers considered, use shipper A but Ebay is willing to use Shipper B.  Once again, there is little I can do with regard to mitigating these risks. 

I may have already performed risk assessments on shipper A and other shippers that are commonly used to deliver equipment to me. I verify that the assessments are still accurate.  Shipper A has a history of losing packages and being late on delivery.  In addition, they have hired my brother-in-law as a driver which further shows their poor judgment.  Shipper B has better track record and, to my knowledge, not hired any of my in-laws.  Having Ebay use Shipper B would be a risk mitigation that I would consider, during the purchasing process.

I now consider all of these risks when, I probably decide to purchase from the manufacturer, even if it means I have to deal with my brother-in-law.

This standard deals with risks associated with “(i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s). (CIP-013-1 R1.1)  The example does not cover risk associated with installing the equipment since in this example, the installation will be done by my company.  

In my view, I have met the language of the R1 and have considered the options for mitigating the risks as stated in the CIP-013 Rational section.  In most cases, I would probably determine that there were no mitigation options to consider.  In the one case where mitigation was possible, I determined that other risks associated with the supplier outweighed the benefit of the mitigation available. 

This standard does not deal with risk associated with operating and maintaining the equipment. These risks are covered by the anti-malware, patch management, baseline, change management and vulnerability assessment required for medium and high impact BES Cyber Systems and associated Cyber Assets.

At the end of the SCWG call, there was a discussion concerning the change in ownership of a manufacturer or supplier after the purchase has been made.  In my view, this change in owner ship does not fall in the scope of CIP -013 until I go to purchase additional equipment.   Changes might be required in my vendor remote access controls, patch management sources and process and vulnerability assessment as required in other CIP standards but there is no requirement that I do a supply chain risk assessment at the time of the sale of the manufacture or supplier.  If I understood correctly, NERC was stating that the entity would need to consider risk mitigations and was not specific that these were only those risk addressed by CIP-005-6 and CIP-010-3. 

Lew’s reply

CIP-013-1 R1 requires the Responsible Entity to develop a “supply chain cyber security risk management plan.” For context as to what a “risk management plan” should contain, I refer to NIST SP800-39, “Managing Information Security Risk,” Chapter 3, “The Process – Applying Risk Management Concepts Across an Organization.” This chapter outlines a triad of Assess, Respond, and Monitor. No risk management plan is complete without a response to the identified and assessed risks.

I’ll also quote the SDT’s ERO-approved Implementation Guidance:

“First, in developing their supply chain cyber security risk management plan(s), Responsible entities should consider how to leverage the various components and phases of their processes (e.g. defined requirements, request for proposal, bid evaluation, external vendor assessment tools and data, third party certifications and audit reports, etc.) to help them meet the objective of Requirement R1 and give them flexibility to negotiate contracts with vendors to efficiently mitigate risks.” [emphasis added]

Kevin’s Reply

First of all, the auditor audits to the language of the Standard Requirement as approved by FERC.  That is the applicability and requirement statements in the Standard, along with NERC Glossary-defined terms and effective dates.  It does not include the purpose statement or suggested measures.  That said, the Requirement needs to be read with a bit of common sense.  That means both the auditor and the entity need to look at the context in which the Requirement is stated.  The context is established by the purpose statement as well as any approved guidance, whether the Guidelines and Technical Basis section of the Standard (e.g., the initial Standards in CIP V5) or stand-alone Guidance in Support of a Standard. 

The guidance serves to inform the entity and the auditor as to the intent of the Standard and its Requirements.  It should be obvious, but I will state it here, that the Standards Drafting Team should not be expected to write a requirement that is so explicit that it leaves no room for any possible latitude on the part of the entity.  I realize that sounds strange, but the Standard and its Requirements should establish the expectations without explicitly telling the entity exactly how it must be done in each and every instance. 

Cyber security Standards and their Requirements need to be somewhat forward looking and anticipatory, especially since it takes so long to make changes.  And, the Standards Drafting Team should be able to assume that the reader, with a modicum of appropriate and applicable technical knowledge, will be able to understand what the Requirement expects of them.  To put it bluntly, it makes no sense for CIP-013 to require the entity to identify and assess risks but to not do anything about them.  And to counter the consultant’s point, it makes no sense to only consider options for mitigating risks but to not do anything about them, simply because the Standard Requirement did not explicitly tell the entity to mitigate.

I think the consultant is taking too narrow a view of what constitutes procurement risk.  Yes, the reliability and viability of the vendor or supplier is a consideration.  Certainly a vendor with a history of financial or delivery problems may not be the best choice for procuring a certain widget.  But, there are more risks to consider.  What about post-delivery warranty and operational support?  The consultant dismisses that in his example because his staff will do the install, but warranty and operational support is often part of the procurement agreement. 

How will it be performed?  Does the vendor require on-site or remote electronic access during the warranty period as a condition of the sale (see the wind turbine manufacturers as a prime example)?  Does the vendor require all replaced parts be returned under a warranty replacement action?  Does the vendor expect to maintain a current set of EMS data models and software customizations at the factory?  Yes, there is a SCADA/EMS vendor that does that.  And then there are the risks inherent in the component parts that comprise the equipment or system being procured.  Have the risks of back door access in software or black box hardware been considered?  What about design flaws (or deliberate exploitable vulnerabilities) introduced during the manufacturing process?

FERC, NERC, and the SDT recognized that not all risks can possibly be known and verified to exist.  Who would ever have known a couple of years ago that a serious side-channel vulnerability existed in almost every processor used in servers and workstations, or that the problem cannot be totally fixed?  Who would have thought that as soon as a work-around was identified, another exploit path would appear?  How many zero-day exploits exist in commercially available off the shelf software that is used to build many of the software systems used in our industry?  How do you know that the server you bought from a US-based company but was built off shore does not have surreptitious vulnerabilities baked in, waiting for the time they are needed during a conflict?

The point I am making here is that the Standard and its Requirements cannot possibly foresee all of the possible risks and vulnerabilities, nor can it presume to prescribe one or more mitigation strategies to mitigate the risks.  But the purpose of the Standard is to “[M]itigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.”  That does not mean identify risks and ignore them.  That does not mean consider mitigation options and ignore them.  The entity is required to identify and assess risks. 

The logical expectation is that the entity will do something about the identified risks, in other word mitigate the risks, to the extent possible.  It does not mean that every single risk must be mitigated to the point of elimination.  There are risks that can never be fully mitigated, hence the concept of residual risk.  The cost to eliminate a risk may be so excessive that it cannot be done.  It may be technically impossible.  But what can you do to reduce the risk?  Can you isolate the network?  Can you restrict physical access?  Can you control, restrict, and monitor electronic access?  Can you patch the system?  Can you encrypt the data?  Can you install a data protection system that lets you reach out and terminate access when necessary, even for documents in the possession of others?  Should you ask the vendor to escrow the source code as a hedge against the vendor going out of business?  Or, should you note the risk and note that there was nothing you could do to adequately mitigate the risk to an acceptable level?  You have to do something.  You just cannot say “Hey, I identified all these potential or actual risks…what a great job I have done…Mission accomplished!”

The consultant suggests that FERC found CIP-005 and CIP-010 to be sufficient in mitigating risks as contemplated by the CIP Standards and thus there is nothing needed in CIP-013.  I disagree.  First of all, there are many risks that are mitigated by CIP-006, CIP-007, and CIP-009.  Second, there are risks for which there are no current technical or administrative controls defined in the CIP standards.  Setting that aside, once the entity has identified and assessed the risk under CIP-013, it is perfectly fine to note the applicable mitigations are the proper implementation of the (identified) controls found in the remaining CIP standards.  Don’t just say CIP has it covered.  The specific controls called out in the remaining CIP standards need to be identified as the mitigations for the instant identified and assessed risk.  And residual risk needs to be identified in some manner.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!