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. 

WARNING: SIGN-IN

You need to be a member of Energy Central to access some features and content. Please or register to continue.

Post

Inflection point: Software Labeling Standards for the Energy Industry

image credit: Author

Ask anyone with a food allergy and they will tell you how important it is for them to “read the label” before consuming a food product. The risks are high for someone with a violent reaction to certain foods, like peanuts, potentially resulting in death. It’s no wonder that people with this level of risk are very precautious about what food products they will consume; they read the label to determine if risk exists before they consume.

Which brings me to the question, why are so many companies becoming victims of ransomware and other malware, aren’t they reading the label of what’s in this software before they install it in a critical system? Would they install a software package if they knew it contained malware? I hope the answer is no. So, why aren’t people reading the label on a software package before installing it? The answer is simple, there is no labeling standard for software, like there is in food labeling, making it difficult for parties to know if there are any “risky ingredients” in a software package.   So, people learn “the hard way” after the damage is done when they find themselves a victim of malware. This is equivalent to having a person with a food allergy consume a product without knowing what’s in it, to see if there is a reaction, and hope for the best.

Fortunately, some very wise people at the National Telecommunications and Information Administration (NTIA) in the Department of Commerce have been working to rectify this “missing label” on software by creating a standard “Software Bill of Material” (SBOM). This work has been underway for almost two years and the group is close to having some SBOM standards ready. Some Energy industry leaders are beginning to see the value of having an SBOM “label” accompany each software object, so that a proper risk assessment can be performed, before any attempt at installation. The Edison Electric Institute (EEI) was one of the first to recognize the precautionary value of having an SBOM to see “what’s inside a software object”, by specifying this requirement in model supply chain procurement language. On June 18, the Federal Energy Regulatory Commission (FERC) posted a white paper asking for suggestions to enhance cybersecurity measures across the electric grid. Reliable Energy Analytics filed comments with FERC suggesting that a requirement for SBOM’s on software objects would enable more efficient and effective risk assessments, to detect harmful software, prior to installation.  On July 8, the Department of Energy issued a Request for Comment section A-3 (a) explicitly mentions the NTIA SBOM work as a possible security enhancement for the bulk power system. On 7/15 EEI hosted a very insightful Virtual Supply Chain Security Conference  where the need for SBOM’s was discussed along with other important topics.

It seems we have reached an inflection point with regard to “safe labeling standards” for software objects and more attention is being given to the very important topic of SBOM’s. Never trust software, always verify and report!

I hope you will join us on August, 12 as Energy Central hosts a special cybersecurity Powersession on best practices for software supply chain risk assessments, which will go into more detail about SBOM’s and their importance in driving risk assessments.

Richard Brooks's picture

Thank Richard 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.

Discussions

Matt Chester's picture
Matt Chester on Jul 17, 2020 4:17 pm GMT

What a fascinating idea-- seems almost too logical in that in frustrates you to realize it doesn't already exist.

Would the SBOM be a mandatory requirement, or would it start as a voluntary measure (at least at first)? Or is it too early in the process to even know that at this stage?

Richard Brooks's picture
Richard Brooks on Jul 17, 2020 5:56 pm GMT

Thanks, Matt. It's a bit early to tell where this is heading, but there is a lot of buzz in energy circles about SBOM's. I saw a demo today from LLNL on their SBOM work - it's very impressive and promising.

I'm confident that something good will come from all this SBOM chatter.

Roger Arnold's picture
Roger Arnold on Jul 21, 2020 12:55 am GMT

Hmmm. I was at one time a systems software engineer, deep into real time operating systems for embedded applications. This is the first I've ever heard of the concept of a "software bill of materials". Of course, it's been 15 years, and a lot may have changed. I'll have to do a little research to see if there's really anything substantive to the concept. Frankly, I'm skeptical. 

I can't see ever encountering a software product listing known malware on its SBOM. Software doesn't generally get delivered with malware pre-integrated. That's not how these things work. But software products are built from components. Many are custom coded for the application, but more come from standard libraries. Many of the capabilities that a product may call upon aren't actually part of the product itself. They reside within the operating system. In view of that, a "software bill of materials" isn't inherently an absurd idea, but making sense of it will likely prove, well, challenging

A comprehensive  SBOM would likely run to 1000s of components, and the particular way that a component is used is at least as important as its identity. It's common for a component to be perfectly robust in the use environment that its developers expected, only to break horribly when used (or misused) in a way that wasn't anticipated.

One thing I've always felt strongly about is the abuse of overly general operating systems to host embedded applications. The application typically has no need whatsoever for 99% of the capabilities that its host platform supports. And it's almost always through vulnerabilities within that 99% of extraneous capabilities that malware is able to enter. The problem is that to limit the application to the capabilities that it actually needs, the developer has to have a good understanding of the application itself. It takes a lot of time and effort to deliver something safe and concise, from which extraneous capabilities have been excised.

Richard Brooks's picture
Richard Brooks on Jul 21, 2020 4:37 pm GMT

Thank you Roger. I suggest you start your SBOM research with the NTIA SBOM initiative

Roger Arnold's picture
Roger Arnold on Jul 22, 2020 9:41 pm GMT

Thanks for that link. It's indeed a good starting point. But after reading more about it, I'm still not sure what I think about the whole initiative. It sounds fine, in principle. It's the practical utility that I'm unsure about.

The problems we're having with cyber security and software reliability are hardly new. But they stem more from economic and institutional issues than technical ones. Software engineers have always known how to develop secure software. And processor architects -- which I was for the last 15 years of my career before retiring -- have known how to design secure hardware. It's just that there's no real market for either. 

That's perhaps an exageration, and oversimplifies what's actually a very complex problem. But the root of the problem is that capitalism is not particularly conducive to quality software. That's a long discussion we don't want to get into, but it's a big issue.

I'll say this much: good analytical tools, such as those that could be built around the SBOM concept, are the right way to tackle the problem. If I weren't getting old and senile, I might be tempted to work on it.

Richard Brooks's picture
Richard Brooks on Jul 23, 2020 8:49 pm GMT

I like your sense of humor Roger. I'm also an old guy who's been developing software for a living for the past 40 years. I decided in December 2018, after an early retirement, to take the plunge and write a software supply chain risk assessment application, called SAG-PM™, that uses an SBOM to drive the process and is now commercially available: https://reliableenergyanalytics.com/products

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 »