Secure by Design has produced a great design, but not great security

 

Chris Hughes produced a great post this week, which I hope will wake a lot of people up. The post was inspired by an article by former CISA Director Jen Easterly; by some good luck, the post is still available on CISA’s website.

The post makes a point that Ms. Easterly has been making for at least a few years: that software developers aren’t doing enough to build security into their products. As a result, the public (and government) is still paying a huge price for the damage caused by attackers exploiting security bugs in software. Last May, CISA launched their Secure by Design pledge, which over 250 companies have taken. Ms. Easterly states, “Each new signer commits to prioritizing security at every stage of software development, creating a ripple effect that raises the standard across the industry.”

She concludes by saying, “The Secure by Design pledge, the resulting progress pledge signers are making, and the bipartisan support for cybersecurity all signal that there is a groundswell of support mounting behind this movement…I see individuals and organizations across the entire ecosystem—open source communities, universities, insurers, Venture Capital firms, researchers, and regulators—playing their part to prioritize and incentivize security. Best of all, I see our nation embracing this movement to make secure, resilient software, creating a safer digital world for everyone.”

Ms. Easterly continually analogizes to the automobile industry: Cars used to be built without any concern for safety, but a combination of public pressure and strong federal regulation (along with California’s pioneering regulations) turned that situation around quickly. She thinks this shows Secure by Design should work for the software industry as well.

However, Chris points out that, while there are only about 12-15 major car manufacturers and fewer than 1,000 manufacturers in total worldwide, there are easily hundreds of thousands of software developers, including a lot of one-person shops. So, just getting a relatively small number of huge developers to sign the pledge isn’t going to do much to secure software in general.

Moreover, Chris isn’t optimistic that signing a pledge will make a difference for most commercial software developers. After all, they’re in business to make money. He points to two big developers that constantly tout their focus on security, which both have reported large breaches in recent years. It isn’t that these companies are hypocrites; rather, it’s that revenue and speed to market will always take precedence over security for commercial products. We shouldn’t expect that to change quickly, if ever.

Even more importantly, there’s the fact that at least 70% (I’ve heard 90%) of the code in any modern software product consists of open source components. Chris says, “The number of open source components in products has tripled in the last four years alone.” Of course, since open source development communities have constant turnover, it’s hard to identify who could even make a Secure by Design pledge, or what it would mean if they made one.

Having made his point that it’s naïve to expect Secure by Design to have much effect on its own on the rapid growth in software vulnerabilities, Chris says in effect that we need to accept the fact that there will always be software vulnerabilities; moreover, it’s likely they will continue to increase at an increasing rate (i.e., the second derivative is positive).

Therefore (and here I’m going beyond what Chris said in his post), the software security community needs to give up the idea that vulnerabilities can be prevented at the source. Instead, we should focus on managing vulnerabilities at scale. Only by doing that can we be sure that whatever resources we have for that purpose are used to produce the greatest possible “bang for the buck” – i.e., mitigate as much vulnerability risk as possible.

What do we need to accomplish that goal? There’s one thing that’s absolutely required, if software vulnerability management is even going to be possible: When a user wants to learn about recently-identified vulnerabilities in a software product they use, or in the components of the product they have learned about through an SBOM, they should be able to search the National Vulnerability Database (NVD) or another vulnerability database and immediately be shown all recent CVEs that affect the product.

Moreover, before they make that search, the user should not need to conduct another search to find the identifier for the product; the identifier should be self-evident to them, based on information they already have. The identifier that enables this to happen is purl, which stands for “package URL”.

The purl identifier needs to be implemented in the CVE ecosystem, so that CVE Numbering Authorities[i] (CNAs) can utilize a purl to identify an open source software component that is affected by a CVE they report. Of course, currently CPE is the only software identifier supported by the CVE[ii] Program; that doesn’t have to go away. But purl has a lot of advantages over CPE for use in open source vulnerability databases that support CVE, such as OSS Index (which is based entirely on purl, not CPE).

There will be a workshop on incorporating purl into the CVE Program during the VulnCon conference in early April. The goal of the workshop will be to describe the benefits of allowing purls to be included in CVE Records and to determine whether there is support in the vulnerability management community to move forward with a proof of concept for this. If you will be at VulnCon, you should try to attend this workshop.

However, even after purl is incorporated into the CVE program and software users can look up open source components or products in CVE-based vulnerability databases by searching with a purl, one problem will remain: Purl’s biggest limitation is that it primarily supports open source software found in package managers, leaving CPE as the only identifier for commercial software products.

But CPE has multiple problems, the most important of which is the fact that today more than half of the new CVEs that were identified in 2024 don’t include a CPE identifier for the affected product. This means that a search in the NVD for the product using a CPE name won’t find any vulnerabilities for it. Thus, no search of the NVD – or any other vulnerability database - for a commercial software product will identify most recent CVEs that apply to that product.

The OWASP SBOM Forum has developed a high-level concept to extend purl to cover proprietary software; it is described in this document. We wish to make it more than just a concept, but a reality. Please let me know if you would like to discuss this further.

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.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.

---

[i] For an introduction to CVE.org and the CVE Program, which includes the CNAs, see this post. 

[ii] If you are confused by discussion of CPE vs. CVE, remember this: they’re both identifiers, but CPE is an identifier for software products used by the NVD (and other databases derived from it), while CVE is an identifier for vulnerabilities themselves. CVE is by far the most widely used vulnerability identifier.

NERC CIP in the cloud: Is there a difference between SaaS and BCS?

In the meetings of the informal NERC Cloud Technical Advisory Group (CTAG), we’re starting to discuss some of the fundamental questions that will arise when the CIP standards are revised to accommodate use of the cloud.

One important question we’ve discussed is, “What is the difference between SaaS and a BES Cyber System in the cloud?” The reason that’s an important question is that currently, because the compliance reporting requirements for medium and high impact BES Cyber Systems require tracking individual physical and virtual devices used in the cloud, platform CSPs can’t provide compliance evidence for BCS in the cloud. Therefore, those systems are effectively “banned” from the cloud today. If a SaaS application had to be treated as if it were a BCS in the cloud, that could prevent use of SaaS in high and medium impact CIP environments today.

Let’s rephrase the question above in a way that might help us find an answer. Suppose a SaaS product performs a function that a BES Cyber System might normally perform. Since systems that perform one or more of the BES Reliability Operating Services (BROS) are definitely BCS, let’s choose one of those services, say “Inter‐Entity Real‐Time Coordination and Communication” (for a list of the BROS, see pages 17-22 of CIP-002-5.1).

CIP-002-5.1 (page 22) states that this BROS “..includes activities, actions, and conditions established by policy, directive, or standard operating procedure…” Note that, while a SaaS product can certainly take the current situation into account and recommend a particular action, it can’t take that action itself, e.g., calling an adjacent Control Center and requesting they make some adjustment. That action needs to be taken by someone (or some system) located in the Control Center. The person or system may be supported by information they receive from a SaaS product, but the SaaS product itself can’t take the action.

The same consideration applies to the other BROS: They require a person or a system to perform some particular action, meaning the person or system needs to be in a Control Center, control room, transmission substation, or some other physical location where those actions are normally performed. A Control Center employee can’t perform those actions while sitting in front of their home computer in their bedroom at night. If they were doing that, their bedroom would need to be declared a Control Center and would need to comply with all the CIP requirements for physical and cyber security that apply to Control Centers. Therefore, since SaaS can’t fulfill a BROS, it can’t be a BES Cyber System.

On the other hand, SaaS products that perform services like configuration management or remote access authorization may need to utilize BES Cyber System Information (BCSI). If the SaaS were compromised and the BCSI were obtained by a malicious party, the information might be used to harm the Bulk Electric System (BES). Does that make the SaaS a BCS?

No, it doesn’t. In fact, if a NERC entity uses SaaS that requires BCSI access today, the entity needs to provide evidence that the SaaS provider followed the CIP requirements that refer to BCSI: CIP-004-7 R6, CIP-011-3 R1 and CIP-011-3 R2. However, the entity doesn’t need to provide evidence for the 100+ CIP Requirements and Requirement Parts that would be in scope if the SaaS were in fact a BCS. Only if a system in the cloud could directly perform actions like causing a circuit breaker to open a line (which could be the case if the right wiring were in place), would the cloud system be a BCS; otherwise, it is SaaS.

Of course, the current CIP standards don’t make any reference to SaaS, since the compliance burden for the three BCSI requirements falls entirely on the NERC entity (although the entity will need some minimal evidence that only the SaaS provider can make available to them). However, when the standards are revised to accommodate use of the cloud, it’s likely they will distinguish SaaS providers from Platform CSPs, who could potentially host entire BES Cyber Systems (along with the connections they require to the outside world). As they do today, the SaaS providers will need to provide evidence to their NERC entity customers that they are adequately protecting the BCSI they utilize, but they will not need to provide all the evidence that an operator of a medium or high impact BCS in the cloud would need to provide.

If you are involved with NERC CIP compliance and would like to discuss issues related to “cloud CIP”, please email me at tom@tomalrich.com.