Welcome to Resilient Cyber!

If you’re interested in FREE content around AppSec, DevSecOps, Software Supply Chain and more, be sure to hit the “Subscribe” button below.

Join 5,000+ other readers ensuring a more secure digital ecosystem.

If you’re interested in Vulnerability Management, you can check out my book “Effective Vulnerability Management: Managing Risk in the Vulnerable Digital Ecosystem” on Amazon. It is focused on infusing efficiency into risk mitigation practices by optimizing resource use with the latest best practices in vulnerability management.

For those who have been following along, we have seen an increased push in the industry towards “Secure-by-Design”, being led by organizations such as CISA and emphasized in the latest National Cybersecurity Strategy (NCS).

For those who aren’t familiar you can find CISA’s Secure-by-Design publication here and my detailed analysis of the publication here. You can also navigate to the latest NCS and find the emphasis here as well.

At the time of this writing, it is RSA Conference 2024 and CISA has announced the voluntary commitment by 68 of the worlds leading software manufacturers to align with CISA’s Secure-by-Design Pledge, which we will be discussing in this article.

You can find CISA Director Jen Easterly’s announcement at the CISA SbD Pledge Launch Event which was previously live streamed here.

The CISA Secure-by-Design Pledge while promising on the surface represents a cybersecurity version of a “Scouts Honor” or a promise or oath that someone will tell the truth/and or stick with a commitment they are making. This makes it both hopeful but not legally binding, and therein lies the challenge we will discuss below.

The pledge is voluntary, meaning it isn’t legally binding and in a world where Zero Trust dominates the headlines, it requires trust in the signatories for the pledge to be meaningful.

Who signed?

First off, let’s take a look at who signed. To make it easy, here is a snapshot of the 68 companies who signed as part of the Secure-by-Design Pledge Announcement

For those interested, you can find individual statements from the organization and their representatives who signed here.

Now, there are some interesting observations to cite with the companies in the pledge.

Several of them are of course not traditionally considered “security” companies, those such as AWS, HPE, Cisco, GitHub, Microsoft and others. That said, there is the caveat that the biggest names in the list of signatories, companies such as AWS, Microsoft and Cisco do have significant security investments, have made substantial security acquisitions and also make billions of dollars in security revenue, such as in MSFT’s case.

Companies such as AWS, MSFT, Cisco and others on the list also represent some of the largest software suppliers on the planet, and are absolutely pervasive across the modern digital landscape, so their commitment to Secure-by-Design is paramount, because an incident impacting them/their products can have an outsized impact.

That aside, you’ll notice many of the companies signing, Apiiro, Bugcrowd, Chainguard, Huntress, Qualys and many others are security companies and products. This of course means they are incentivized to encourage the push towards Secure-by-Design because what will traditional software companies use to secure themselves? The signatories products of course.

This isn’t to say there is anything wrong with security companies supporting the pledge and that these aren’t amazing companies and products but I do think we need to try and garner broader adoption among the non-security software community for this paradigm change, to have the broad impact we’re hoping for. This means traditional software companies, as well as large enterprise businesses who aren’t “software companies” by nature but are using software to power their modern enterprise and business objectives.

Lastly, I will say there is something critical about software security companies taking the pledge, aside from them being incentivized to do so. Their products ultimately represent part of our attack surface too, and if a security product gets compromised, it exponentially diminishes their trust in the ecosystem can really impact their market share, growth and revenue, since their entire value proposition is reliant on trust.

There’s also the reality that these security products are pervasive in modern enterprises, with most organizations struggling with tool sprawl, cognitive overload and having tens of security tools they are trying to manage and utilize, all of which of course add to their attack surface in addition to potentially reducing it.

(Several of the signatories have had significant security incidents themselves, which have dominated the headlines and are easy to find, but I didn’t write this article to trash anyone - the reality is that cybersecurity is hard).

Goals of the Pledge

The pledge lays out 7 goals, which we will take a look at below, and then unpack a bit further.

Multi-Factor Authentication

Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.

What It says and means:

What it means and challenges: CISA’s comprehensive pledge points out that MFA is the most effective defense against password-based attacks.

To emphasize how relevant credential compromise is to modern data breaches, take a look at the latest Verizon Data Breach Investigation (DBIR) summary of findings, which points out again that credentials remain the most common attack vector for data breaches at nearly 40%, where it has reigned king for several years.

This again emphasizes the reality that hackers don’t hack in, they log in, and worse, they do it using your credentials.

The pledge stresses that while MFA is helpful, phishing-resistant MFA is key to mitigate attacks such as SIM swapping etc.

It lays out example approaches to achieve this goal, such as enabling MFA by default for users, nudging users to enable MFA and supporting SSO in the baseline versions of product (no doubt a swipe at companies who are up-charging for MFA and SSO, which you can find on a site called “The SSO Wall of Shame”, which shows vendors that treat SSO as a luxury feature and charge additionally for it).

The site, who’s URL is “sso.tax” emphasizes that companies who take security seriously should have SSO available as a part of the core product or reasonably priced at a minimum.

To measure progress on this goal, the guidance advocates for vendors to publish stats of MFA adoption over time, broken down by user type, publish content such as blog posts describing the progress and participate in the community to advance standards around MFA.

Default Passwords

Goal: Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.

What it says and means:

CISA’s defines default passwords as those that are universally-shared and present by default across products. We see this often with products such as home routers, hardware and even software products which shift with a default credential that is baked into the product. The risk here of course is that users and customers don’t change those credentials are attackers are able to compromise them by simply logging in (back to our prior goal we discussed).

CISA is advocating that at the end of the product set up, only the customer should know their credential. They provide example approaches such as random, instance-unique credentials per product, requiring the user to establish the credential during set-up and one-time use passwords that are disabled after a product is deployed.

Again, to demonstrate measurable progress they recommend publishing blog posts describing how a manufacturer is moving past default passwords, publishing metrics of products that have default passwords over time to demonstrate the declining number and also insights on the number of customers transitioning from default passwords to more secure options.

Reducing Entire Classes of Vulnerabilities

What it says and means:

Goal: Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.

What it says and means:

This one of course aligns with CISA’s push to drive down vulnerabilities and broader Secure-by-Design to eliminate entire classes of vulnerabilities. We’ve seen this with their push for Memory Safe Programming Languages, and calling on vendors to publish CWE’s for every CVE and look at recurring vulnerabilities and try and systemically eliminate them at the root/CWE.

The pledge points out vulnerabilities such as SQL injection, cross site scripting and memory safety. They suggest a vendor select one or more classes of vulnerabilities and try and reduce them over time entirely from a product or multiple product lines.

CISA has published Secure-by-Design Alerts aimed at this, such as “Eliminating SQL Injection Vulnerabilities in Software” and “Eliminating Directory Traversal Vulnerabilities in Software”.

The pledge cites example approaches such as enforcing the use of parameterized queries for SQL, adopting web template frameworks for cross-site scripting and developing a memory safe roadmap.

To demonstrate progress the pledge recommends manufacturers blog about their efforts to significantly reduce classes of vulnerabilities including an analysis of CWE’s of CVE’s over time.

Security Patches

Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.

What it says and means:

This one aligns with another aspect of the CISA SbD publication, which is software suppliers taking more ownership of security outcomes for their customers.

This is critical, as I have been writing about extensively, organizations are drowning in vulnerability backlogs, numbering in the hundreds of thousands to millions, as the rate of known vulnerabilities (CVE’s etc) continues to grow exponentially Year-over-Year.

To help customers be more effective at patch management, the pledge cites example approaches such as allowing automatic installation of patches and enabling that by default, clearly communicate end-of-life software timelines during sales, ease transition to new versions of products and utilizing cloud and SaaS, where the patching responsibility is done by the cloud service provider (CSP) and not the customer.

To demonstrate progress with this goal CISA recommends publishing aggregate metrics showing patch adoption by product over time (% of users using versions of each product) as well as publishing blog posts to demonstrate what the vendor is doing to foster more effective deployment of patches by users and/or reducing the patching of burden for users.

This goal is critical because as I have been talking about, telling customers “patch faster” when they are already drowning isn’t helpful. Of course we can mitigate the number of patches overall by having more secure products from the onset, as it the point of goals within this pledge, but no software is perfect or flawless and patches will always exist in some fashion, so striving to minimize the burden for customers and help them patch more effectively would be a big step forward for the industry.

Keeping up with patches is increasingly challenging, as their numbers keep growing. Security Researcher Jerry Gamblin has demonstrated that as of May 1st 2024 there have been 12,640 CVE’s published at an average about 104.46 per day with an average CVSS score of 6.74

All of this to say we’re seeing a 24.1% YoY growth of CVE’s in 2024 so far compared to 2023, at a time when organizations are already struggling to keep pace with vulnerabilities and vulnerability backlogs are growing exponentially, making organizations ripe for exploitation.

This of course aligns with other recent industry leading reports, such as Verizon DBIR, which found vulnerability exploits have went up 180% in 2023 compared to the previous DBIR report. Google Mandiant’s M-Trend report also showed a similar growth in vulnerability exploitation.

I covered Verizon DBIR’s vulnerability insights in a recent article titled “The DBIR is Entering its Vulnerability Era”. The image below from the DBIR demonstrates that organizations are struggling to remediate known exploited vulnerabilities (e.g. CISA KEV), let alone the entire vulnerability landscape.

Vulnerability Disclosure Policies

Goal: Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP) that authorizes testing by members of the public on products offered by the manufacturer, commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP, provides a clear channel to report vulnerabilities, and allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure best practices and international standards.

What it says and means:

The pledge points out that Vulnerability Disclosure Programs (VDP)’s benefit both the vendor and security researchers. It lets researchers more effectively report findings to a software vendor and helps vendors more effectively communicate vulnerabilities with their customers and the industry as whole.

They recommend resources such as CISA’s Vulnerability Disclosure Policy Template.

I also have written extensively about the role of Product Security Incident Response Teams (PSIRT)’s, which often interact with and help facilitate vulnerability disclosure and response for software vendors.

To demonstrate progress they recommend publishing a VDP publicly, and making it machine readable (such as a security.txt file) for easier use by researchers and also blogging about findings and lessons learned as part of the organizations VDP.

CVE’s

Goal: Within one year of signing the pledge, demonstrate transparency in vulnerability reporting by including accurate Common Weakness Enumeration (CWE) and Common Platform Enumeration (CPE) fields in every Common Vulnerabilities and Exposures (CVE) record for the manufacturer’s products. Additionally, issue CVEs in a timely manner for, at minimum, all critical or high impact vulnerabilities (whether discovered internally or by a third party) that either require actions by a customer to patch or have evidence of active exploitation.

What it says and means:

This goal of course is aimed at both proactively communicating vulnerabilities in the form of CVE’s with the community but also providing additional data such as CWE’s and CPE’s in the CVE records to help the industry understand the products a CVE impacts as well as the root CWE associated with the CVE.

You’ll see there’s an easy intersection with this goal and others, such as reducing entire classes of vulnerabilities, where a software vendor can see recurring CVE’s, see if there is a common theme of a CWE among them and then systematically try and drive out those classes of vulnerabilities in their products so they quit recurring.

There is of course some challenges with the vulnerability ecosystem currently, most notable the stalling and halting of CVE enrichment by the NIST National Vulnerability Database (NVD), which I cover in an article titled “Death Knell of the NVD?” as well as in an interview with security researchers Josh Bresser’s and Dan Lorenc that dives into the funding challenges of NVD, and other issues that led to NVD drastically reducing their CVE enrichment since around February 2024.

Security Researcher Jerry Gamblin has published great analysis, showing that as of early May 2024, 10,195 CVE’s that have been published this year have NOT been analyzed and enriched by the NVD, and NVD has only analyzed 340 CVE’s since February 15th 2024.

He points out that for NVD to empty this backlog, let alone analyze new inbound CVE’s would take 185 days.

Evidence of Intrusions

Goal: Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.

What it says and means:

This goal of course is focused on enabling and empowering customers to effectively conduct incident response and provide them with enhanced visibility and transparency into malicious activity impacting the vendors products.

The pledge emphasizes software manufacturers enabling customers through providing artifacts, capabilities and more to detect evidence of intrusions which aligns with the SbD theme of vendors taking more ownership of customer security outcomes.

Examples they provide include making logging available for baseline versions of products that includes configuration changes, identity and network flows and data access or creation insights.

In the context of SaaS it stresses CSP’s retaining logs for a defined period of time to facilitate incident response at no additional charge and if logging isn’t possible, providing customers with guidance on how they can effectively monitor and respond to incidents impacting the products.

To demonstrate progress, the pledge recommends documenting the vendors policies around providing logs and log retention as well as publishing a roadmap for adding and improving logging capabilities for products if they aren’t supported currently.

Conclusions and Challenges

As we wrap up, we can see that this is a promising effort by CISA and the broader community to align with and commit to Secure-by-Design software and products. Fundamental security activities and controls such as MFA, SSO, Logging, Vulnerability Management and more run throughout the pledge.

There of course some challenges here that I touch on throughout the article, such as the need to expand the commitments beyond security products or security-adjacent software vendors and to get buy-in from the broader software community.

Additionally, and most notable, is the reality that this represents a digital “scouts honor” as I have called it, essentially the companies giving their word in an entirely non-legally binding fashion to commit to these SbD goals and to be transparent about both their progress and lack thereof tied to these SbD principles and goals.

As the SbD Pledge publication points out in the opening line

Meaning this is entirely voluntary, commitments to the pledge are not legally binding and this isn’t the same as the push for Software Liability (or inversely Safe Harbor) that we see mentioned in the NCS.

So while we may want to hold the signatories and broader software community to the pledge and its associated goals, we’re merely going on their word, and they are in no way legally obligated to do any or all of the items laid out in the pledge.

That said, it isn’t nothing, and there is something to be said for reputational harm, trust and more in a community that can be slow to forget and unforgiving when an organization slips up.

For an example of this, look at the mixed response from the community from Microsoft’s recent Secure Futures Initiative (SFI) in response to the Cyber Safety Review Board (CSRB)’s damning report of a breach impacting Microsoft’s products.

All of that aside, on the surface, the SbD Pledge represents another positive step forward for the software community when it comes to at least speaking to the need for more Secure-by-Design products and software to mitigate the risks that now impact every aspect of our software-driven society from consumer goods to critical infrastructure and national security systems.

What remains to be seen, is who will not just talk the talk, but walk the walk.