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.