The Executive Order and CIP-013

Last Friday, Christian Vasquez published in E&E News a good perspective on how the recent Executive Order will impact the electric power industry. Christian quoted three people in the article: myself, Norma Krayem of Van Scoyoc Associates, and Patrick Miller, who shouldn’t need any introduction to the readers of this blog (but just in case you do, he’s U.S. coordinator for the Industrial Cybersecurity Center, although he has a long and distinguished bio).

What I found surprising was that both Norma and Patrick focused on compliance issues, while I – who used to be known as someone who couldn’t say five words without two of them being “NERC CIP” – never even thought of the EO as in any way contributing to the compliance burden for electric utilities.

In the article, I pointed out – and in retrospect I could have made my point clearer with a few additional words – that the EO puts some pretty strict requirements on software suppliers to the federal government. Since there are very few US-based software suppliers who don’t sell both to the government and the private sector, and since no supplier is going to build separate products using different security standards, this means those strict requirements will protect electric utilities, as well as every other public and private organization. A nice “side effect”, and one that was surely intended.

In fact, I suggested that utilities turn the requirements in the EO (specifically, in Section 4 of the EO) into questions to ask their software suppliers. For example, if the EO tells the suppliers “Do X”, you can ask your suppliers “Do you do X?”. And the reason this is important is that the EO is very much focused on risks that arise in the software development process (not surprising, of course, since the SolarWinds attack that led to planting the Sunburst malware in Orion updates took place entirely within the SolarWinds development environment – using an amazingly elaborate process I discussed in this post). 

Software development risks have been almost completely ignored in just about any supply chain cyber risk framework or regulation you look at: DoD’s CMMC, NIST 800-161, the North American Transmission Forum’s questionnaire and criteria, the NERC CIP-013 Implementation Guidance, etc. So it’s about time they came front and center. And IMO the best news about the EO is that it essentially extends software development security requirements to suppliers to private industry, without making enforcement of these requirements the private sector’s responsibility (which is the approach taken by NERC CIP-013, since neither NERC nor FERC has any jurisdiction over suppliers to the power industry). The federal government does all the heavy lifting, and the private sector reaps a lot of the benefits.

Of course, not everybody sees this the same way as I do. In particular, the article says this about Patrick (who I’ve been friends with for at least 12 years): “Miller said NERC's rules for utility supply chain cybersecurity are vague enough that an auditor could use the order to add unwritten requirements. ‘If you're a utility trying to do supply chain, this just adds more confusion and uncertainty into your supply chain efforts going forward,’ Miller said.”

I do want to point out that Patrick was hardly complaining bitterly about this, since he went on to say “It's all good stuff, but there's a bunch of confusion still.”

I don’t disagree with Patrick that there’s lots of confusion about the NERC CIP supply chain cybersecurity standard, CIP-013. But I think the EO will reduce that confusion, not contribute to it. Here’s why I say that:

1.      CIP-013 is the first true risk-based NERC standard (some people argue that CIP-014 is risk-based, and to some degree it is. But IMO there’s a big difference, which I won’t go into here. The new CIP-012 is also risk based, but CIP-013 got there first ). By “risk-based”, I mean that it’s up to the NERC entity to decide how to allocate the resources they have available for supply chain cybersecurity risk mitigation. They have to decide which are the most serious risks in their vendor’s environment, and focus their efforts on mitigating them. That way, they get the most bang for their buck.

2.      Of course, this is exactly what should happen, and I don’t have any problem with what’s written in CIP-013. However, I have a big problem with what’s not written there: CIP-013-1 R1.1 tells the NERC entity to “identify and assess” supply chain cybersecurity risks, but it gives no guidance at all on where to look for those risks. It doesn’t even provide a set of categories of risks that the entity should consider, including risks arising from the software development process.

3.      Of course, there are lots of third parties that have provided lists of risks (often in the form of questionnaires) – and the Implementation Guidance provided by the drafting team in 2017 listed a lot of risks for the entity to consider.

4.      However, the problem with all of these lists of risks is none of them are part of the CIP-013 standard, or even referred to in it. If they were, the entity would be able to put in place mitigations for these risks (and if some risks don’t apply to an entity, they could just document why that’s the case). Then they could sleep at night, knowing they were compliant with what CIP-013 asked for.

5.      But as CIP-013 stands now (and will undoubtedly stand for at least a few years), the only guidance on risks to be addressed is R1.2, which lists six mitigations that must be included in the entity’s supply chain cyber risk management plan (even though each of these is a mitigation, they can all easily be reworded as a risk). These were included in CIP-013 not because the drafting team thought they were the six most important risks to address, but because FERC had mentioned them at various random places in Order 829 in 2016 and required that they be included in the NERC entity’s supply chain cyber risk management plan. The drafting team just decided to group them together in one place.

6.      But we all know that there are many other categories of supply chain cybersecurity risk that you should at least consider in your plan. Clearly, software development risks are one category. Others are risks arising from insecure purchasing or installation practices on the entity’s part, improper identity management or patch management practices on the vendor’s part, improper controls on the vendor’s subcontractors, etc.

7.      If the standard provided a list of these risk categories, there wouldn’t be nearly the degree of uncertainty that Patrick points to. The NERC entity would just need to consider risks pertaining to each of these categories (ideally, there would also be a list of risks that pertain to each category, although it could never be exhaustive. These might be provided as part of the CIP-013 standard, or as a separate document).

8.      In each category, the NERC entity would identify risks that have a high likelihood of being realized in their environment. And if all the risks in a particular category have low likelihood (e.g. risks having to do with vendor remote access, for a utility that doesn’t allow remote access in the first place), they would just need to document this fact. At this point, the entity has identified supply chain cybersecurity risks to the Bulk Electric System.

9.      How about assessing those risks? The entity needs to document that they considered the risks for each category and assessed them as to their likelihood of being realized and their impact if realized, since the degree of risk is determined by the degrees of likelihood and impact (BTW, I don’t see any way likelihood and impact can be assessed to any higher degree of accuracy than just “high” or “low”. I think it’s a waste of time to try to assign risk scores of 1-5 or something like that). By combining likelihood and impact (either adding or multiplying them), you get the degree of risk.

10.   But there’s a further simplification: When it comes to BES Cyber Systems (which are of course what CIP-013 applies to), I think the impact of their being exploited always needs to be considered high. Of course, sometimes there would be little or no impact from exploitation – as in the case where a relay is attacked and opens a line, but the line itself was already open for maintenance. In other cases, there might be a huge impact, as in the case where a relay opens a key transmission line on a hot summer day, when it’s already heavily loaded. Given that there’s no way to know in advance what the impact will be, it needs to always be considered high – in other words, it should be the high water mark. And if impact is always high, it doesn’t need to be considered in risk assessments.

11.   This means that the only consideration for risk of supply chain attacks on BES Cyber Systems is likelihood. The question becomes: What is the likelihood that this risk will be realized in the supplier’s environment (or in the NERC entity’s environment, in the case of risks that apply to the entity itself)?

12.   For example, consider the risk that a service vendor might not conduct background checks on their new employees. As a result, they hire an employee who happens to be a card-carrying ISIS member. That employee gets remote access to a relay in your substation and opens an important line, causing an outage. The impact of this risk being realized could of course be catastrophic, but what’s the likelihood? That’s what your assessment tries to find out: You ask the service vendor about their policies for vetting the people they hire, including background checks. If they answer that they require all new hires to pass a background check, you assign them a low likelihood score for this risk, meaning the level of risk is also low. You don’t have to do anything more about this risk, with this vendor.

13.   But what if the vendor gives you the answers you want to hear, but you have some reason to suspect they may not be telling the truth? In that case – as well as the case where they honestly answer that they don’t do background checks – you need to give the vendor a high likelihood score for this risk.

14.   You’ll ultimately determine whether the vendor has a high or low likelihood of not doing background checks on their employees. If the answer is “low”, then you can stop worrying. However, if it’s “high”, you should take steps to mitigate this risk, probably by requiring that their employees be escorted at all times while onsite (since you can’t be sure they’ve had a background check). And you might stop using that supplier altogether.

Given this, why do I say the EO makes CIP-013 less confusing, not more? I have two reasons:

1.      As I’ve already said, the EO will make all commercially-available software more secure, not just software sold to the federal government.

2.      Given that SolarWinds (and other recent software supply chain attacks) has shown the importance of including the category of software development risks in your supply chain cyber risk assessments, you can “mine” Section 4 of the EO for questions to ask your software suppliers. For example, on page 13, item (e)(1)(A) requires the supplier to use “administratively separate build environments”. This means the supplier should maintain a software build environment separate from their IT network (just like your OT network – or ESP – is separate from your IT network, and for similar reasons). You can turn this into the question “Do you maintain an administratively separate software build environment?”

3.      Another example: On page 15, item (e)(vii) reads “providing a purchaser a Software Bill of Materials (SBOM) for each product…” You can turn this into “Will you provide an SBOM for each product that you provide to us?”

So I think the EO will make your CIP-013 compliance process easier, not harder. And it will make your organization more secure, as long as the organization uses software. And just about every organization on the planet uses software nowadays.

 

Is it time to review your CIP-013 R1 plan? Remember, you can change it at any time, as long as you document why you did that. If you would like me to give you suggestions on how the plan could be improved, please email me.

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.