The DoE RFI, Part I

DoE issued a Request for Information last week. It seems to function like an informal version of the Notice of Proposed Rulemaking that regulatory bodies like FERC issue: DoE is considering issuing rules to implement the May 1 Executive Order and wants comments to help them develop those rules. Here are my comments (I won’t submit every word below, though). Given how the new rule could easily turn out to require huge expenditures by industry with little or no benefit to anybody I can identify, it would be a good idea for as many industry players as possible to comment on it.

I liked the RFI. The DoE people who wrote it are obviously quite concerned about the possible costs of implementing the EO the way it was written. Moreover, it seems they’re not blindly going along with whoever wrote the EO (and I’m sure it wasn’t DoE! The White House drove the EO, but I imagine they had help from other parts of the government, and perhaps certain consultants). 

That is, DoE isn’t assuming at the outset – as the EO directly implies - that the big supply chain security problem facing the US grid is something that is being implanted in products made in China, which on some dark day in the future will be used to bring the US to its knees with a massive power failure. They seem genuinely interested - although I may be reading too much into this - in actually learning what the real problems are before they burden the industry with a hugely expensive non-solution to a non-problem.

There are definitely real supply chain real security risks to the US grid, which is why CIP-013-1 will come into effect on October 1. But I would put this Chinese supply chain attack idea at about number 1,000 on the list of supply chain security risks we need to be concerned about. It would be a huge shame if a large portion of the already limited utility resources available to address supply chain risks had to be diverted for this purpose. If you would like to know why I say this, here are two of the many posts I’ve written about this issue: one and two.

Christian Vasquez of Energywire wrote a good article on the RFI last Thursday. In it, he quoted me as follows:

DOE is also asking whether the energy sector participates in a "community for sharing supply chain risks." Grid security consultant Tom Alrich said the answer is "an emphatic no," but a centralized agency like DOE could help establish such a data-sharing hub rather than requiring utilities to identify risks on their own.

Alrich also said the list of equipment in DOE's notice "is so heavily weighted with almost completely 'dumb' boxes like transformers, when the real risks rest with computers and other programmable electronic devices like relays and programmable logic controllers, and just as importantly with their components." Alrich said that transformers aren't typically attached to a computer network and "act 100% according to the laws of physics," meaning a cyberattack doesn't pose as much of a threat as a physical attack.

The real risk, Alrich said, is in hardware, software, and firmware (components). It's difficult for any utility to complete a thorough investigation into the components that it uses on the grid, Alrich said, as few power providers have the resources to do so. "This is where DOE could add a lot of value — doing these investigations itself and sharing the results with the industry," Alrich said.

I appreciate that Christian didn’t just take one or two snippets of what I said in an email, but actually tried to get the whole thoughts. This week, I’ve gone back through the RFI. I’d like to give you my full thoughts on it now (although I have to break this post into two parts).

Are changes needed to the standards?

Question A-3 starts by asking “Are non-standard incentives or changes to established standard development organizations’ SCRM standards (including NIST 800 series, ISA/IEC 62443, NERC CIP, and other Cyber Risk Maturity Model evaluations/practices) necessary to build capacity to protect source code, establish a secure software and firmware development lifecycle, and maintain software integrity?”

My answer to this question is almost exactly what I intend to say when I finally do my post in response to FERC’s recent Notice of Inquiry on the CIP standards (this will hopefully be soon): All real cyber security threats (supply chain or otherwise) should be addressed in the CIP standards. However, they all need to be addressed in a non-prescriptive, risk-based manner like in CIP-013, not in the prescriptive zero-tolerance model of most of the other CIP standards and requirements.

In the ideal CIP compliance regime, the NERC entity would be free to consider all of the BES cybersecurity threats they face and allocate their available mitigation resources toward those that pose the highest degree of risk (as they can in the CIP-013 compliance process). But this in turn requires:

1. Rewriting all of the prescriptive requirements like CIP-007 R2 and CIP-010 R1. Complying with just these two requirements diverts a huge amount of resources from other cybersecurity threats like ransomware, APTs and phishing, that aren’t addressed at all in CIP now. All threats need to be treated equally in my new CIP regime.
2. Having an independent body that identifies important threats and publishes a list regularly (along with recommendations for mitigation measures). Each NERC entity with High or Medium impact assets would need to consider each of these threats as they decide how they’ll allocate their mitigation resources (say at the beginning of each year). They won’t be able to mitigate every threat, but they will need to show that any threats they didn't mitigate posed a lower level of risk – in their estimate – than the ones they mitigated.
3. Drastically revising the NERC auditing regime, so that NERC CIP auditors are required to take a cooperative approach with the entities they’re auditing, not a basically adversarial one. In fact, the auditors would help the entities decide which threats they will mitigate and help them identify the best ways to mitigate them. Of course, this makes them much more consultants than auditors. But any other approach makes less and less sense all the time (for example, having these changes in place is required if NERC entities will ever be allowed to put BES Cyber Systems in the cloud). And I’ll bet there’s hardly a single CIP auditor that wouldn’t be happy as a clam if they could cooperate with the entities, rather than have to respond to requests for compliance advice by answering those questions in a low voice and never writing down any advice they provide, since officially they’re not allowed to provide any sort of compliance advice at all.
4. Exorcising NERC of the idea of auditor independence, as far as the CIP standards go (the Operations and Planning standards are a different story altogether. Nothing I’m saying here necessarily applies to them). This is the reason why NERC is never allowed to provide true guidance on any CIP standard, even though there’s still lots of uncertainty about basic concepts like “programmable”, as well as about exactly how the prescriptive CIP requirements are to be applied. It’s also why NERC staff have been shot down every time they’ve tried to provide real guidance on CIP requirements, as in the late, lamented Guidance and Technical Basis additions to the CIP standards - which have now officially become Unpersons.

So let’s get back to question A-3. It continues on to ask how “benchmarks” are documented and tracked in several specific areas like software bill of materials (a mythical creature that on paper sounds like a great idea but in reality is very elusive – just like Bigfoot has so far eluded us). But just to answer the one-sentence question quoted above, CIP-013-1 already addresses protecting source code, establishing a secure software and firmware development lifecycle, and maintaining software integrity.

It does this in R1.1, where the NERC entity is required to survey the landscape of supply chain security risks, “identify” those that are most important, and “assess” each of those for the degree of risk they pose – so in theory they’ll consider the three risks just mentioned, along with all others. But in practice, my biggest problem with CIP-013 is it lacks a list of risks (actually “risk areas” like secure software development lifecycle) that the entity needs to consider – and the entity could be in violation if they can’t show they at least considered each one. Having this would give the entities some very helpful guidance, and it would also give the auditors something they can hang their hat on in audits.

In part II (coming soon to a blog near you. BTW, does anyone remember something called “movie theaters”? They all disappeared in about March, and I fear we’ll never see them again), I’ll give my answers to three more of the questions in the RFI. Try to contain your excitement.

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 hot at work – or should be – on getting ready for CIP-013-1 compliance on October 1? Here is my summary of what you need to do between now and then.