Cybersecurity researchers have observed a surge in the exploitation of vulnerabilities in widely used software products by both financially-motivated cybercriminals and nation-state actors.
As well as being able to gain initial access multiple organizations in a single hit, this approach provides a basis for evading defenses and establishing persistent access in target networks.
Incidents like SolarWinds in 2020, Log4j in 2022 and MOVEit in 2023 significantly impacted government and critical sector organizations.
In response to this trend, the White House’s National Cybersecurity Strategy, unveiled in March 2023, aims to shift the security responsibility away from end users to those best placed to shoulder that burden, including software manufacturers.
The Cybersecurity and Infrastructure Security Agency (CISA) developed a Secure by Design initiative in April 2023 to explain how software manufacturers can ensure security is built into their products.
A Secure by Design Pledge was then announced in May 2024, encouraging manufacturers to commit to making progress across a range of secure by design principles.
Infosecurity Magazine recently spoke to Jack Cable, Senior Technical Advisor at CISA, to find out more about the Secure by Design initiative and pledge and their progress to date.
Infosecurity Magazine: What has been its progress of CISA’s Secure by Design initiative so far?
Jack Cable: The focus of our Secure by Design initiative is the technology manufacturers who make the products that underpin all the digital systems we use and our critical infrastructure.
We're incredibly reliant on these systems but we've seen time and again that there are relatively basic preventable classes of vulnerabilities in these products that can lead to harm.
The goal of our Secure by Design initiative is to work with technology manufacturers to help them build products that are secure from the start and are resilient to these common classes of vulnerabilities.
We've done that by putting out international guidance, the first of which we published with six international partners in April 2023, and followed that up with some updated guidance in October 2023.
We're up to 13 international partners who've signed this guidance, across North America, Europe and Asia.
That’s setting the scene for our ambitions and through actions like our Secure by Design Pledge, we're starting to help catalyze action in line with these principles.
IM: What are the upcoming milestones for the Security by Design initiative?
JC: We focused in 2023 on defining what it means to be secure by design and the approaches we want companies to take.
That included three secure by design principles that are geared towards business leaders recognizing its importance. We know technically how to build products that are more secure by design, but, from a business perspective not enough companies have made that decision to invest in these kinds of approaches.
We want to encourage the adoption of these principles and the Secure by Design pledge, which over 150 companies have now signed.
Companies are pledging within one year to publicly report on the progress they've made in meeting the goals set out in the pledge.
In the spirit of one of our secure by design principles of radical transparency, we want to make sure that it’s not just the companies who sign the pledge and take action who are benefitting, but everyone does.
This is achieved by having success stories of companies who have built products that are more secure by design. A lot of our focus is seeing how we can increase public dialogue around the sorts of practises and investments companies should be making.
IM: How will CISA track and measure the progress made by signatories of the Secure by Design pledge?
JC: Signatories cover a wide range of software products, including some of the largest software manufacturers in the world. We're excited to see the momentum behind it and the interest there’s been.
The next step is to make sure that that companies are following through on their pledge, and we see foundational improvements in how they are designing and developing their products. To that end, in the pledge there are seven concrete goals that that companies are committing to showing measurable progress towards within one year of taking the pledge.
These are:
- Increase the use of multi-factor authentication across the manufacturer’s products
- Demonstrate measurable progress towards reducing default passwords across the manufacturers’ products
- Reduce the prevalence of one or more vulnerability classes across the manufacturer’s products
- Increase the installation of security patches by customers
- Publish a vulnerability disclosure policy (VDP)
- Demonstrate transparency in vulnerability reporting
- Increase the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products
We intend to privately convene the companies who've taken the pledge so that they can learn from each other. We hope companies will begin to collaborate on these secure by design areas for the benefit of us all.
IM: The pledge goals focus on encouraging transparency, including publishing a VDP and increasing details included in every CVE record. How important will this aspect be in enhancing secure by design software?
JC: A large focus of the transparency aspect is the recognition that we as a software industry can only improve if we have solid data to inform our understanding of trends around the causes of vulnerabilities over time.
"We need to know what classes of vulnerabilities are posing the greatest threats over time and what approaches are or aren't working"
If you look at the common vulnerabilities and exposures (CVE) program today and try to understand the prevalence of memory safety and other types of vulnerabilities, the data isn't fully there.
This is because companies inconsistently report the common weakness enumeration (CWE), which represents the root cause of a vulnerability and helps us to understand over time how trends and vulnerabilities are changing.
In the pledge is a commitment by companies to include that root cause information in their vulnerability disclosures whenever they file a CVE.
The intent of this is two-fold, we want greater transparency around when individual companies should be filing vulnerabilities, so they meet a certain level of severity. That will allow their customers to understand if they've been affected by the vulnerability.
Additionally, we need to know what classes of vulnerabilities are posing the greatest threats over time and what approaches are or aren't working.
We see this aspect of transparency as fundamental to help start this secure by design shift.
IM: The US government has placed an emphasis on promoting memory safe programming languages, away from the current reliance on C. What are the practical challenges with making this shift and how can this be overcome?
JC: We know that a majority of vulnerabilities in code written in memory unsafe languages are memory safety vulnerabilities. One of the challenges is we don't know those exact numbers. We have reports from the likes of Microsoft, Mozilla and Google, in relation to their products, but we don't have much data about industry wide trends.
Read here: Decoding US Government Plans to Shift the Software Security Burden
We know that the vast majority of vulnerabilities are caused by known preventable classes of vulnerabilities. Not only have we known about the class of vulnerability for decades, but often we've known how to prevent them at scale.
This is one of the focuses of our Secure by Design alert series, where we issue tangible guidance to manufacturers around specific types of vulnerabilities. For example, we have a paper on memory safety vulnerabilities and we put out a Secure by Design alert around sequel injection.
Memory safety is an interesting area because of the level of harm caused by these vulnerabilities, which makes it the most dangerous class of vulnerabilities out there.
We know that one that the most promising approaches to root out memory safety vulnerabilities is to write code in memory safe programming languages, which are resilient to memory safety vulnerabilities.
We’re calling on manufacturers to urgently undertake an assessment to understand the most pressing and addressable classes of vulnerabilities in their products. In the case of memory safety vulnerabilities, start to develop a memory safety road map.
We recognize this is a decades-long problem, but companies need to be starting now in a prioritized manner.
IM: How is CISA and the US government encouraging security training for developers?
JC: One of the essential parts of the secure by design ecosystem is the software developer workforce. I wrote a blog for CISA in January 2024 about this point, arguing that when we talk about the cyber workforce gap, we need to view the software developer workforce as part of that.
"It's not going to be cybersecurity professionals alone who can solve these deep-rooted problems"
It's not going to be cybersecurity professionals alone who can solve these deep-rooted problems in cybersecurity, because we need to have fundamental improvements in how we develop software.
That will require having a workforce of software developers who understand the basics around security. They don't need to be experts, but they should have enough awareness to know that writing in C or C ++, a memory unsafe language, is dangerous and whenever possible, they shouldn't do it.
They should also know that when they're writing database queries, they should do it in a way where the input isn't commingled with the contents of the query itself. At the very least, they should go to a security professional at their organization and get a second opinion. One of the things we've been calling for at CISA is for colleges and universities to make security a core part of computer science curricula.
One of the fundamental changes is understanding that real harm can be caused by writing code and that those developing it need to have a basic understanding of how to prevent those harms.
IM: What initiatives are CISA and the US government taking to improve the security of open source software?
JC: We've been very active around open source software security and view this as a core part of our Secure by Design initiative.
I think people have started to recognize issues that the open-source community has known for years, whether it's deep rooted vulnerabilities like Log4j or the more recent Xe utils compromise..
We know that open source software, like any other type of software, has vulnerabilities and is a target for attack.
We also know that open-source software provides immense value and underpins virtually everything we rely upon today, including our critical infrastructure, our personal devices and our federal government.
Read here: Three Strategies to Boost Open-Source Security
A recent Harvard study that found that the total cost to produce the world's open source software was $4.15bn, and the demand side value is far larger, at $8.8trn. There's an immense economy of scale at play.
As open source software is a public good, which we are all dependent upon, we view it as the responsibility of all the software manufacturers who are incorporating open source software to help sustain and contribute back to this ecosystem, whether that's through financial contributions or their employees time.
We know that, as with many public goods, we are only going to get the necessary security improvements if everyone who's taking advantage of it contributes back. We're trying to do our part as the US government.
For instance, we've been doing some work with package repositories, so the entities who distribute open source software to software developers across the world and have defined a set of security principles that many of these package repositories are now working towards.