Secure-by-Design (and Demand)

A look at the new CISA Secure-by-Design publication

In a previous article we covered the original CISA Secure-by-Design/Default publication.

In October 2023, CISA has now released an updated version of the publication, continuing their push to evangelize an ecosystem of Secure-by-Design software and systems, and looking to shift the onus onto software suppliers rather than the current paradigm where the consequences of vulnerable systems and software overwhelmingly fall on customers and consumers.

As part of this push to shift the market dynamics, and address the fact that many consider cybersecurity to be a market failure, CISA is encouraging software suppliers to adopt the principles laid out in the document and public document the actions they take, to demonstrate their commitment to secure design philosophies.

While I remain skeptic that suppliers will voluntarily make these investments, given their primary motive is profit and security has a cost in terms of research, development, implementation and maintenance, it could run counterintuitive to their primary motives, which are the maximization of profit.

That said, it is worth emphasizing that insecurity also has a cost, in the forms of regulatory consequences, recovery costs, compensating controls, loss of customer trust and ramifications on revenue.

For example, we’ve seen recently organizations such as the SEC passing rules driving publicly traded companies to report security incidents that are deemed “material”. For insight into how big material cybersecurity incidents can be, Sounil Yu recently shared a resource from the FAIR Institute dubbed “How Material is That Hack”, which is a website covering recent incidents such as MGM Resort International, Clorox and Caesars Entertainment, which impacts ranging from tens to hundreds of millions of U.S. dollars.

While it remains unlikely that suppliers will make the required security investments and efforts without associated demand, the CISA guidance emphasizes just that, stating that:

“Just as we seek to create a pervasive Secure-by-Design philosophy within software manufacturers, we need to create a “Secure-by-Demand” culture with their customers“

In other words, to help try and correct the market failure of cybersecurity which won’t voluntarily resolve itself on the supplier side, increased demand for secure products and software from customers and consumers can influence suppliers behaviors, because then it is directly tied to customer demand and spending, which impacts revenue/profits, the suppliers primary concern.

Secure-by-Design

Let’s start with a little primer on what Secure-by-Design even means, at least from the perspective of CISA. In the publication they define it as:

“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”

Simple, right?

Well, not quite.

The word “reasonable” will mean something different to the industry of cyber practitioners as well as business peers and of course consumers, but it is a term that is used in other industry lexicons and likely will have precedent established as litigation around insecure products and services continue to unfold, such as the class action lawsuits being filed against Progress Software, the manufacture of MOVEit, which saw widespread impacts across hundreds of organizations and potentially millions of users due to exploitable vulnerabilities in their product and claims of negligence.

Nonetheless, CISA goes on to discuss how vendors should be performing risk assessments to identify and enumerate threats, including protections in their products to account for the threats, implementing best practices such as defense-in-depth and utilizing tailored threat models during product development and deployment. There are also calls for vendors to collaborate among their business and technical staff to ensure cybersecurity throughout the entire SDLC/product lifecycle, including not just design and development but deployment and maintenance for customers as well.

Secure-by-Default

The guidance also emphasizes another concept, which is Secure-by-Default, and is defined as :

“Products are resilient against prevalent exploitation techniques out of the box, without added charge, without end users having to take additional steps to secure, and make customers acutely aware when they deviate from safe defaults”

The primary point in this section is that products come with a baseline level of security by default and don’t need significant effort by customers to “harden” the products and software against exploitation, which is typically the case now.

The guidance also states that “the complexity of security configuration should not be a customer problem” and that customers aren’t charged extra for implementing added security configurations (like we saw with the debacle over Microsoft E5 licensing and incidents that limited victims ability to use logs to understand the potential impacts to them).

Again, there is and will be a grey area where debates occur over what is a sufficient level of default security and what features and functionality are reasonable to charge for. Given the different incentives at play for suppliers and customers (e.g. profit and value), the two will have a different view of what should be done by default and what should be charged for.

Software Product Security Principles

The guidance lays out three primary software product security principles which it encourages suppliers to adopt and prioritize. Let’s take a look at each of them below.

• Take ownership of customer security outcomes

• Embrace radical transparency and accountability

• Build organizational structure and leadership to achieve these goals

Principle 1: Take Ownership of Customer Security Outcomes

This core principle focuses on ensuring the burden of security doesn’t fall solely on the customer, which is often the case in the modern paradigm of software and technology.

CISA also makes the case that by building security in throughout the SDLC rather than having cybersecurity be an afterthought or “bolted on”, that not only do they increase the customers’ security but they also increase their products quality, since product security and resiliency are subsets of overall product quality.

This principle emphasizes security efforts such as application hardening, application features and application default settings. Application hardening can raise the cost for malicious actors and bolster products against attacks. Specific security-related features are called out such as supporting TLS, MFA, RBAC/ABAC and SSO and for them to be configured securely out-of-the-box, rather than needing to be specifically configured and tinkered with by customers upon product deployment/provisioning.

Much like we’ve discussed in our previous article “The Elusive Built-in Not Bolted On”, there’s an emphasis on placing the burden for security on suppliers/vendors rather than downstream customers, a theme that was prevalent in the recent National Cybersecurity Strategy (NCS). The CISA publication states:

“Manufacturers should take ownership of their customers’ security outcomes rather than measuring themselves solely on their efforts and investments . The responsibility should be placed upstream, with the manufacturers, where it has the greatest likelihood of reducing the chances of compromise.”

It’s pointed out that vendors commonly patch a single vulnerability only to see similar vulnerabilities continue to emerge for a specific product/software, since the symptom was addressed, rather than the root cause.

Another key point made is the need for secure application default settings. There’s an acknowledgement that typically vendors focus on making applications as easy to use and as functional as possible by default for customers, but this can come at the expense of increased attack surface or more vulnerable applications and software as well. CISA says that security controls shouldn’t be toggled off by default and vendors should use threat modeling to determine which features should be on by default or instead hardened upon delivery to customers to mitigate risks.

While maximizing functionality can be compelling from a product perspective, if the default configurations are insecure, exploitable or make it easy for a customer to make a risky mistake, it also presents risk that is now distributed across all of the customers.

CISA calls out one of the longstanding aspects of the software industry, which are the release of hardening guides, either by the vendor directly, or often by third parties (e.g. CIS Benchmarks, DISA STIG’s et. al). The challenges cited with the longstanding practice include hardening guides being difficult to find, not being well supported, complex to implement or even requiring additional development effort. There’s also challenges on the customer/consumer side with regard to a lack of sufficient expertise in some cases to even go about implementing the hardening guides.

“Millions of customers are taking on the responsibility to harden multiple instances of software or systems, often in resource-constrained environments.

Relying on hardening guides simply doesn’t scale.”

There’s parallels drawn to other industries, to bring risks and insecure configurations to the attention of the user, such as vehicles notifying the driver that a door is open or seatbelt isn’t buckled. Examples provided include MFA not being configured for administrator accounts or insecure protocols being used.

CISA lays out the reality that as an industry we continue to see organizations needing to adopt more and more security tools to monitor their systems and software posture, all of which must be researched, funded, purchased, staffed, deployed and monitored, often in resource and expertise constrained environments. This is far less scalable than software suppliers bolstering product security from the onset of development through customer delivery and maintenance.

There’s obviously several challenges to this mantra, such as the fact like we discussed that software manufacturers are incentivized to maximize profit, which security can potentially impact (as can insecurity), and that there is an entire thriving ecosystem of cybersecurity companies, including several unicorn’s with billion dollar valuations incentivized to continue to treat the symptoms of insecure software and products (we also must acknowledge that security vendors aren’t in a position to force software manufacturers to properly address security in their own products).

The CISA publication goes on to enumerate various steps vendors should take to demonstrate a commitment to this initial principle of taking ownership for customer security outcomes and organizes the practices into three groups, which are listed below:

Secure-by-Default Practices

• Eliminate default passwords

• Conduct field tests

• Reduce hardening guide size

• Actively discourage use of unsafe legacy features

• Implement attention grabbing alerts

Secure Product Development Practices

• Document conformance to a secure SDLC framework (such as NIST SSDF, which they list as an example)

• Document Cybersecurity Performance Goals (CPG) or equivalent performance

• Vulnerability management

• Responsibly use open source software (OSS)

• Provide secure defaults for developers

• Foster a software developer workforce that understands security

• Test security incident event management (SIEM and security orchestration, automation, and response (SOAR) integration

• Align with a Zero Trust Architecture (ZTA)

Pro-Security Business Practices

• Provide logging at no additional charge

• Eliminate hidden taxes

• Embrace open standards

• Provide upgrade tooling

Principle 2: Embrace Radical Transparency and Accountability

The second principle CISA recommends software suppliers embrace is one of radical transparency and accountability. CISA states there should be a pride vendors associate themselves with when it comes to delivering safe and secure products and using that as a competitive differentiator among their peers and with customers and consumers.

Refreshingly, CISA shoots down the tired trope of transparency providing a roadmap for attackers, or as it is often called “security through obscurity”. The reality, as they point out is that hackers are already achieving their objectives despite the obscurity, and transparency actually aids defenders who are trailing adversaries and can use transparency to help bolster their defensive measures. It also helps the industry as CISA states, establish what “good” looks like, so vendors demonstrating security proficiency can be help up as an example for others to emulate and it fosters trust among customers and consumers as well.

”Transparency builds accountability into the product”

CISA makes the case that while embracing radical transparency around product development and security may be uncomfortable for the current state of the industry it will help propel us forward. Its stated that radical transparency will empower defenders more than adversaries, who already by most metrics succeeding wildly.

The transparency can inform peers about practices and foster collaboration and a comprehensive rising of tide across the software ecosystem while also informing both prospective customers and investors regarding the security posture of their purchases or investments.

CISA advocates for what we have seen some technology leaders embrace, which is radical transparency of security incidents, publicly detailing what occurred, what the impact was, and what improvements and lessons learned the vendor is integrating to mitigate similar threats in the future.

Much like the previous principle of ownership, CISA enumerates how suppliers can demonstrate a commitment to transparency, which includes:

Secure-by-Default Practices

• Publish aggregate security relevant statistics and trends

• Publish patching statistics

• Publish data on unused privileges

Secure Product Development Practices

• Establish internal security controls

• Publish high-level threat models

• Publish detailed secure SDLC self-attestations (e.g. SSDF)

• Embrace vulnerability transparency

• Publish Software Bills of Materials (SBOM)’s

• Publish a vulnerability disclosure policy

Pro-Security Best Practices

• Publicly name a secure by design senior executive sponsor

• Publish a secure by design roadmap

• Publish a memory safety roadmap

• Publish results

Principle 3: Lead from the Top

This principle emphasizes the reality that no matter the desire from folks on the ground, building products, the fostering of a security culture, driving the appropriate internal incentives and ensuring the required resources to deliver secure products all starts at the top.

“Only when senior leaders make security a business priority, creating internal incentives, and fostering an across-the-board culture to make security a design requirement will they achieve the best results “

As the publication points out, an organization vision, mission, values and culture all affect their products and all are derived at the top leadership level of an organization.

They cite quality experts such as J.M. Juran who are quoted as saying companies who demonstrated quality leadership all had the characteristic of upper manages personally guiding the initiatives. Given security is a subset of product quality, the concept applies here as well.

Parallels are drown to emerging corporate social responsibility programs and the publication calls for corporate cyber responsibility (CCR) as an emerging idea.

To demonstrate this principle, CISA lay out the following steps software suppliers should take:

• Include details of a secure by design program in corporate financial reports

• Provide regular reports to your board of directors

• Empower the secure by design executive

• Create meaningful internal incentives

• Create a secure by design council

• Create and evolve customer councils

Secure-by-Design Tactics

The next section of the Secure-by-Design publication is one where they begin to specifically cite tactical actions, and practices software suppliers can take to produce more secure software and aid in activities such as finding and removing vulnerabilities, mitigating potential impacts of exploitation of vulnerabilities and addressing root causes to prevent incidents to occurring again in the future.

It should come as no surprise that CISA heavily leans on the NIST Secure Software Development Framework (SSDF) here, as the Federal government is rallying around SSDF for secure software development and software supply chain requirements, including OMB Memos, such as 22-18 and 23-16, which require software suppliers selling to the Federal government to self attest to utilizing SSDF practices to produce the products they sell to the government. For those interested, I’ve done deep dives into the memos 22-18, 23-16 and the CISA Self-Attestation form, all of which can be found at the embedded links here.

CISA advocates for organizations developing a Secure-by-Design roadmap aligned with the practices discussed below, which they also cross-map to SSDF practice identifiers:

• Memory safe programming languages (SSDF PW.6.1)

• Secure Hardware Foundation

• Secure Software Components (SSDF PW 4.1)

• Web template frameworks (SSDF PW.5.1)

• Parameterized queries (SSDF PW 5.1)

• Static and dynamic application security testing (SAST/DAST) (SSDF PW.7.2)

• Code Review (SSDF PW.7.1, PW.7.2)

• SBOM (SSDF PS.3.2, PW.4.1)

• Vulnerability disclosure programs (SSDF RV.1.3)

• CVE completeness

• Defense-in-Depth

• Satisfy Cybersecurity Performance Goals (CPG’s)

The CISA publication provides more depth on each of these identifies tactics/practices and I strongly recommend reviewing the document if you need more details on what each of the above mean.

CISA also recognizes that these changes will take time, resources and effort and recommend organizations prioritize them based on tailored threat models as well as other factors such as criticality, complexity, and business impact. Organizations may initially target newly developed software and products before moving to implement these practices into legacy products and codebases as well.

Secure-by-Default Tactics

As has been discussed throughout this article, in addition to Secure-by-Design principles, CISA is recommending vendors begin to prioritize Secure-by-Default configurations in their software and products as well. The specific practices they cite are below:

• Eliminate default passwords

• Mandate MFA for privileged users

• Single Sign On (SSO)

• Secure Logging

• Software Authorization Profile

• Forward-looking security over backwards compatibility

• Track and reduce “hardening guide” size

• Consider the user experience consequences of security settings

Much like the Secure-by-Design principle tactics, I recommend diving deeper into the source publication if you need more details on each of the Secure-by-Default tactics and what they mean. CISA again also acknowledged the tradeoff businesses must consider between operational impacts and security considerations as well as concerns around customer experience. They also advocate for vendors to create incentives for customers to adopt secure configurations and settings, rather than leaving their implementation of the products in an insecure state.

Hardening vs. Loosening Guides

Another fundamental paradigm shift CISA advocates for in their Secure-by-Design publication is the shift from vendors publishing “Hardening Guides” to “Loosening Guides”.

What this ultimately means is moving from delivering products that are insecure out of the box by design/default based on configurations and instead delivering products with secure defaults in place and them empowering the customer/consumers to loosen the product configurations while clearly understanding the security ramifications and risks associated with doing so.

Delivering Secure-by-Default products can mitigate systemic risks and protect vulnerable customers not often familiar with the risks of insecure configurations or products and spread awareness.

Recommendations for Customers

Lastly, the publication closes out with a brief section on recommendations for customers. While this may come as a surprise to some to be such a short section, it shouldn’t as we have said several times here, the goal of CISA is to help drive an industry-wide shift of putting the burden on security more so on the vendor/supplier than the customer, with the opposite being the current reality.

There’s also the reality that there is a literal mountain of cybersecurity best practices, critical controls, hardening guides and other relevant materials out there for customers, consumers and enterprises using products and software. They have absolutely no shortage of materials.

That said, let’s take a look at the CISA specific verbiage on recommendations for customers.

CISA recommends customers/consumers hold their vendors and suppliers accountable for the security outcomes of their products. This means voting with your wallet and purchasing products and software that prioritizes Secure-by-Design/Default (SbDD) products and software. It also means ensuring products are properly vetted by internal security staff prior to procurement and utilizing angles such as contractual language and RFI/P’s etc. to help drive specific products and purchases.

CISA emphasizes that IT departments must have the executive support of the organization when enforcing these purchasing decisions. If insecure/risky products are purchased, those decisions and inherent risks should be formally documented and approved by the senior business executives. This sort of activity ensures the onus doesn’t inherently fall on security when in reality the business is driving the purchasing activity and risk acceptance - in other words, the business owns the risk, and documenting risks and having them formally signed off on can help change behavior.

There’s also calls for IT and Security leaders to collaborate with industry peers to rally around services and products that value and prioritize the Secure-by-Design/Default principles, and this collective consensus and spending decisions can help incentivize vendors to prioritize secure products, associated with actual customer demand.

As we have discussed in previous articles, many consider cybersecurity to be a market failure that will not voluntarily resolve itself until regulatory forces make it change, or market incentives shift to change behaviors. Consumers rallying around vendors and products that prioritize Secure-by-Design/Default products and services can function as that market signal that can drive systemic changes across the software supplier ecosystem.

That said, not much is likely to change until/if market dynamics shift and the regulatory consequences drive behavioral changes across the landscape.

As a society we’re at a crossroads where we must determine if we want to stick with the status quo. Endless data breaches, security incidents and increased safety concerns, especially with the continued convergence of cyber physical systems and emergence of cyber as a domain of modern geopolitical tensions and warfare.

Which path will we take?

Time will tell.