Secure-by-design as a requirement is coming. Developers should start preparing for it now.

The March 2023 National Cybersecurity Strategy (NCS) includes, “In setting cybersecurity regulations for critical infrastructure, regulators are encouraged to drive the adoption of secure-by-design principles…”

There are two important elements to this. The concept of secure-by-design is introduced but not defined; and it is implied that this undefined concept will be enforced on the critical infrastructure by regulations that are yet to be established. This is more than a little nebulous but is something that cannot be ignored.

At the end of February 2023, CISA’s director Jen Easterly had said that federal procurement power will be used to encourage secure-by-design. In April 2023, CISA published a set of principles to achieve ‘secure-by-design’. In September 2023, CISA announced that it had hired Pieter (Mudge) Zatko “to help us collaboratively shape a culture of security by design that is foundational to every security team…”

Secure-by-design is clearly important to the federal government, and there is a strong possibility that it will become a regulatory requirement for the critical industries enforced through an Executive Order. But what does secure-by-design mean, and how can it be measured for enforcement?

In August 2023, Lawfare announced a new project seeking to provide the answers – specifically, how do you define it, how do you measure it, how do you translate this into regulations, and how should you enforce those regulations?

Secure-by-design – the lack of a specification

All product developers describe their products as secure-by-design. However, the justification for this claim differs between different vendors. 

Kelly Bissell, CVP Microsoft Security, comments, “Our approach to secure design is to implement security and privacy considerations throughout all phases of the development process from ideation to support plus SbD within development environment tools and processes – no matter the product. It’s a principle that goes back to 2002’s Trustworthy Computing initiative.”

This may be true. But while Bill Gates’ 2002 internal memo stating, “Our responsiveness has been unmatched – but as an industry leader we can and must do better,” may have led to the Trustworthy Computing (TwC) unit and the development of the Microsoft Security Development Lifecycle (published in 2008), nowhere does it define ‘secure-by-design’ in general purpose terms. The TwC was effectively disbanded as a single unit in 2014.

Scott Gerlach, Co-Founder and CSO at StackHawk, similarly describes secure-by-design as a process, without defining the steps contained in that process. “Secure-by-design places accountability on product teams to ensure from product inception to delivery, security is not an afterthought,” he told SecurityWeek. “Any playbook designed to achieve ‘secure-by-design’ must prioritize security with the same level of importance as desired features.”

Cisco also describes its process as proof of security-by-design. “Over the years, Cisco has established a mature secure-by-design program,” claims Matt Fussa, trust officer at Cisco. “Cisco continues to build the program with a substantive software transparency program centered in SBOM, SSDF and Vulnerability Information Exchange (VEX), uplifting the build environment security to Salsa (SLSA) Level 3.”

Pieter Danhieux, co-founder and CEO at Secure Code Warrior, continues the same theme from the opposite direction: “I tend to think about the definition of secure-by-design in simple terms,” he said. “If security has not been made a priority from the very beginning of a product or software build, then chances are good that the product in question will not have security baked in.”

John Steven, CTO at ThreatModeler, summarizes the current situation. “’Secure-by-design’ has been diluted by vendors taking a piece of it as their description of perceived differentiation. But no vendor can own ‘secure-by-design’, it’s a capability that leverages multiple tools and techniques within an organization’s software delivery culture.”

In effect, secure-by-design is currently just a label that says, ‘Our product is secure-by-design because in our opinion our proprietary processes justify us saying it is.’ This is good for the seller, but bad for the buyer – and meaningless for the NCS’ intent to drive secure-by-design through regulations on the critical industries.

You cannot regulate what is not specified and cannot be measured.

Specifying secure-by-design

A definition for secure-by-design may lie in a universally applicable standardization of the approach currently taken by individual developers: the process. This would require a formalized process applicable to all product development. It would be a mammoth task more difficult for hardware than software, but possible. And it may be the path already chosen by CISA.

Gavin Ferris, CEO of LowRISC, comments, “the most relevant current definition of secure-by-design can be found in the guidance document published in April of this year by CISA, jointly developed with the FBI, NSA and the cybersecurity authorities of Australia, Canada, United Kingdom, Germany, Netherlands, and New Zealand.”

That definition states, “’Secure-by-Design’ means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data, and connected infrastructure. Software manufacturers should perform a risk assessment to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape.”

On its own, this is still a description of intent rather than an enforceable generalized process. However, the document goes one step further by providing a set of principles to be used by all developers: “a non-exhaustive list of illustrative roadmap best practices”. A secure-by-design specification would require this to be expanded into ‘a full list of required roadmap best practices’.

This will take time and may still be unenforceable. However, it is noticeable that CISA is not limiting secure-by-design to software but includes the concept of secure-by-design hardware – recommending a visit to the University of Cambridge’s CHERI webpage. CHERI (Capability Hardware Enhanced RISC Instructions) is a joint research project ‘to revisit fundamental design choices in hardware and software to dramatically improve system security.’

Cambridge is also home to the OpenTitan silicon-based root of trust (S-RoT) project guided by LowRISC. LowRISC’s OpenTitan project director, Dom Rizzo, comments, “Secure-by-design systems need to be anchored by a hardware root of trust — such as OpenTitan — or the laudable work being done at the software level can be undone. For example, SBOMs are an excellent idea, but in the absence of a silicon RoT, what ultimately guarantees that what’s in the SBOM is what’s actually running on your system? Or similarly, if your machine is attacked below the operating system level — and Microsoft has reported that 83% of businesses have been so attacked — a hardware RoT is vital both to detecting this, and to ensuring that the original firmware can be safely reinstated.”

If the NCS’s intent is to place the burden of security more on the product provider than on the product user, and secure-by-design is intended to make this possible, then secure-by-design hardware must be added to the mix. You cannot have secure software if it is running on insecure hardware. But a universally enforceable and measurable process for hardware is altogether more complex than one for software.

The ideal solution would be the development of standard processes – a secure-by-design specification – that can ultimately provide a playbook for product developers. CISA has a start point for software: the NIST SSDF. “Presently, the best organizations can do is largely governed by process or activity-based metrics,” says Steven. “The NIST SSDF (800-218) provides a guide. Organizations gauge how many activities from the SSDF’s design and defect discovery domains it employs.”

CISA agrees. “The Secure Software Development Framework (SSDF), also known as National Institute of Standards and Technology’s (NIST) SP 800-218, is a core set of high-level secure software development practices that can be integrated into each stage of the software development lifecycle (SDLC),” states its April document. 

‘Following these practices can help software producers become more effective at finding and removing vulnerabilities in released software, mitigate the potential impact of the exploitation of vulnerabilities, and address the root causes of vulnerabilities to prevent future recurrences.”

However, we should remember the purpose of the NCS’ drive toward secure-by-design is ‘to shift liability onto those entities that fail to take reasonable precautions to secure their software’, and ‘to leverage federal procurement to improve accountability’. The strategy is also strong on the concept of regulation.

The NCS is primarily about software, although it also mentions the need for secure IoT devices. Hardware more generally will likely be drawn into the mix because of the futility of secure software running on insecure hardware.

But this is still only the beginning. If we assume that it will eventually be possible to specify secure-by-design, procurement of secure-by-design products will depend upon visible proof of secure-by-design processes. This is best achieved through an enforceable secure-by-design specification.

Regulating secure-by-design

Regulation can be mandatory or voluntary. It can be a required ‘proof of compliance’ by regular audit, or an ongoing self-assessment assertion.

Regular imposed audits are expensive, time -consuming, and can be self-defeating. Passing an audit means a company is in compliance at the point of the audit. Companies can easily slip out of secure-by-design compliance when there is no real pressure to comply before the next audit – they are already in possession of a current secure-by-design certificate. The cost could also have a depressing effect on new startup innovation.

Self-assessment generally becomes a tick-box exercise against a list of requirements. This is not necessarily a bad thing if done adequately and visibly. Buyers can be presented with a list of areas met, and can compare different product assertions before making a choice.

Regulating self-assessment falls on the procurement side: federal buyers can be required to purchase only products complying with a minimum level of secure-by-design specifications. Enforcement of tick-box accuracy can be achieved by refusing to do further business with providers ever proven to have made false claims in their secure-by-design assertions; this is what is meant by ‘leverage federal procurement to improve accountability’.

Second-guessing detailed CISA intentions is a futile task, but it will be required to assist in the implementation of the National Cybersecurity Strategy — and it will have been a major contributor to that strategy. It knows what it is doing. Enforcing, or at least encouraging secure-by-design will require a specification of secure-by-design. The current focus is clearly on software, but for the process to be fully successful, it will inevitably expand into at least some areas of hardware.

Delivering secure-by-design is a mammoth and complex task. It will be a multi-year project for CISA — but we should never underestimate the softly-softly persistence of the agency. Secure-by-design as a requirement is coming, and developers could do worse than to start preparing for it now.

Confirming the ‘softly-softly persistence’ of the agency, CISA published updated secure by design principles on October 16, 2023. The project has now been joined by an additional eight international cybersecurity agencies: the Czech Republic, Israel, Singapore, Korea, Norway, OAS/CICTE CSIRTAmericas Network, and Japan (JPCERT/CC and NISC).

“This updated guidance,” notes CISA, “includes feedback received from hundreds of individuals, companies, and non-profits. It expands on the three principles defined in the initial guidance: Take Ownership of Customer Security Outcomes, Embrace Radical Transparency and Accountability, and Lead From the Top.”

Related: From Basecamp to Icefall: Secure by Design OT Makes Little Headway

Related: CISA Unveils Cybersecurity Strategic Plan for Next 3 Years

Related: CISA Unveils New HBOM Framework to Track Hardware Components

Related: Mirai Variant V3G4 Targets 13 Vulnerabilities to Infect IoT Devices