The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 

Post

What is “critical software”?

Tom Alrich's picture
Supply chain Cybersecurity Risk Management and NERC CIP-013 consulting Tom Alrich LLC

Currently with Tom Alrich LLC, I provide strategy and compliance consulting to electric power industry clients and vendors to the power industry, focusing on the NERC CIP cybersecurity standards....

  • Member since 2018
  • 199 items added with 48,139 views
  • Jun 17, 2021 10:17 am GMT
  • 186 views

 

From my point of view (i.e. the only completely unbiased point of view I know of – and I can judge that point since I’m unbiased), the biggest question mark about the May 12 Executive Order is “What is critical software”? This is important, because the requirements for software suppliers in section (e) of Section 4 apply to critical software (although the EO is somewhat vague on whether or not only critical software is in scope).

The EO orders NIST to develop a definition of that term (paragraph (g) of Section 4, pages 15-16), but then very helpfully goes on to say what the definition should include: “definition shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” And not only that, but the EO had already defined critical software as “software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources).”

Your access to Member Features is limited.

Poor NIST. The White House is saying “We give you complete freedom to define critical software, as long as you use one of these two definitions.” The two definitions more or less say the same thing: “Critical software is software whose exploit by a bad guy could cause a lot of bad things to happen, due to the nature of the software and how it’s installed and the privileged access it receives.” In other words, “We want to prevent another SolarWinds from happening, so we’re going to regulate the hell out of anything that looks or smells like SolarWinds.”

I can’t particularly blame the WH for taking that attitude: After all, it’s a military tradition to be ready to fight the last war, not the one you face now. But it did occur to me that this isn’t the way we usually think of critical assets (hardware and software), especially in the electric power industry. For example I would think of all of the following as critical software, even though I doubt any of it runs at high privilege levels:

  • The software that runs the SWIFT system for international money transfers
  • The software that controls the operation of a factory
  • The software that runs a nuclear power plant
  • The Energy Management System (EMS) software that balances power supply and load (demand) with microsecond accuracy in a particular region like a major city, running in the control centers of electric utilities
  • The software that runs the NY subway system

In other words, I think the function of a piece of software can make it just as critical as the privilege level it runs at.

But there’s another thing that was left out of the EO definition, which I pointed out in the post I wrote the day after the EO came out: intelligent devices. These have become more and more important in our lives and work, and they perform lots of critical functions now. Surely some of these should be included as “critical software” – but I couldn’t see how you could stretch the definition of “software” to cover devices.

But in this, I overlooked the close-to-unlimited ability of government to stretch the meanings of words through regulation! The FDA performed a valuable service to me and the cybersecurity world by pointing out, in their response to NIST on the EO, that the Food, Drug and Cosmetic Act (FDCA) says that some software is “software that meets the definition of device…”

In other words, devices are software because an Act of Congress made them so! Problem solved (although I must admit to not quite understanding what this means. Essentially, the FDA is saying “Not all software is soft. Some software is hard and made out of metal, chips, wires, etc.” This seems to me like saying “Not all dogs bark and wag their tails. Some dogs mew and use the litter box.” It seems to me that, just as it would be easier to say “Some household pets are dogs and some are cats”, it would be easier to say “Some software runs on general purpose devices like Intel-standard servers, and other software runs on dedicated, sealed devices like infusion pumps in hospitals.” As opposed to saying the devices themselves are software. But then, what do I know?).

In any case, the FDA goes on to say that ‘software is “critical software” generally (i) where it meets the definition of device and (ii) where the software is necessary for the safe and effective use of a device.’ In other words, the FDA wants to discard the EO definition of “critical software”, and just have the term apply to devices (of course, mainly medical devices, since only those are defined as software in the FDCA) and the software in those devices.

I don’t disagree with the FDA that devices and the software they run should be called critical software, although I would prefer expanding the term to “critical software and devices”. In that term, I would include:

  1. Software running at elevated privilege levels, as in the EO’s definition
  2. Devices performing critical functions and the software included in them. This covers more than just medical devices. For example, the electronic relays found in just about every electric substation worldwide are crucial to the safe and reliable operation of the power grid.
  3. Software that performs critical functions using general-purpose hardware, such as the five items I mentioned above.

See? Now everybody can be happy: the White House, the FDA, me. What more could you ask for?

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they shared by the National Technology and Information Administration’s Software Component Transparency Initiative, for which I volunteer. 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.

 

Tom Alrich's picture
Thank Tom for the Post!
Energy Central contributors share their experience and insights for the benefit of other Members (like you). Please show them your appreciation by leaving a comment, 'liking' this post, or following this Member.
More posts from this member
Discussions
Spell checking: Press the CTRL or COMMAND key then click on the underlined misspelled word.
Matt Chester's picture
Matt Chester on Jun 17, 2021

In other words, devices are software because an Act of Congress made them so! 

Reeks also of 'corporations are people.' Don't you love politicians and their effective and well-thought out solutions!

Richard Brooks's picture
Richard Brooks on Jun 17, 2021

Matt, I learned a hard lesson: "Software Engineers should never swim in waters where politicians are the dominant species". I no longer participate in capacity market design discussions where economists and politicians are deciding the solution for grid reliability, resiliency and resource adequacy. Truly a painful lesson, which I have learned from.

Get Published - Build a Following

The Energy Central Power Industry Network is based on one core idea - power industry professionals helping each other and advancing the industry by sharing and learning from each other.

If you have an experience or insight to share or have learned something from a conference or seminar, your peers and colleagues on Energy Central want to hear about it. It's also easy to share a link to an article you've liked or an industry resource that you think would be helpful.

                 Learn more about posting on Energy Central »