Secure-by-Design and -Default

A roadmap for developing and releasing secure software

Blog Secure-by-Design and -Default

| 4 min read

Contact us

The Cybersecurity and Infrastructure Security Agency (CISA) made an important publication on April 13. Together with the National Security Agency (NSA), Federal Bureau of Investigation (FBI) and the cybersecurity authorities of New Zealand, Netherlands, Germany, United Kingdom, Canada and Australia, it created and released the guide "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default," aimed especially at IT manufacturers. This guide includes technical recommendations and core principles to orient organizations toward incorporating security from the early stages of the software development lifecycle (SDLC) in order to build and deliver more secure products to customers.

If the governments of developed countries submit proposals such as this one, encouraging or urging manufacturers to secure their products, it's because they see their intervention as necessary. What is happening is that a good many technology providers are still lagging behind in securing the products they develop and market. They deliver their products to their customers, who are usually in charge of monitoring their security and reducing and responding to cyber risks. As time goes by, more and more vulnerabilities appear in the technology provided to customers, who must keep an eye on patch updates and their installation. Unfortunately, multiple vendors still have security below functionality and time-to-market in priority levels. This is what government agencies and companies like ours intend to help transform.

In short, within the proposal referenced here, "the authoring agencies urge manufacturers to revamp their design and development programs to permit only Secure-by-Design and -Default products to be shipped to customers." These products would have the security of customers as a fundamental objective and, at the time of use, would not require configuration changes or additional payments for features in favor of security. More of the burden or commitment to security in preventing misconfigurations and weaknesses should fall on the manufacturers than on the customers. Today, security should be seen by everyone as a quality requirement. A company will not stand out just by how appealing its products are in terms of functionality but also of security.

Get started with Fluid Attacks' Secure Code Review solution right now

Secure-by-Design

The authoring agencies encourage manufacturers to recognize the cyber threats facing their products and implement good development practices and defenses against them. This requires making security a business priority and investing resources in core features and mechanisms that put customer protection first. While this certainly increases costs in the initial phases of the SDLC for manufacturers, long-term maintenance costs are reduced. Although vulnerabilities may inevitably continue to emerge in their products, ideally, lots of security issues, many of which are "due to a relatively small subset of root causes," could be prevented.

For the Secure-by-Design objective, the authoring agencies promote using NIST Special Publication 800-218, "Secure Software Development Framework" (SSDF). Applying this set of best practices for secure software development enables companies to identify, remove and prevent security vulnerabilities and mitigate the risks they pose. Based primarily on the SSDF, the agencies suggest, for example:

  • Employ memory-safe programming languages (e.g., C#, Java, Ruby), which automatically manage memory and don't require the developer to add code for memory protection.

  • Use new architectural features, such as those of the CHERI research project, which allow "fine-grained memory protection and highly scalable software compartmentalization" to limit the impact of vulnerability exploitation.

  • Design infrastructure that allows the whole system to be unaffected when a security control is compromised.

  • Acquire and maintain secure third-party software components (commercial or open-source).

  • Generate a Software Bill of Materials (SBOM) or detailed inventory of components or resources used in the software and their dependencies.

  • Require peer review of the code by other developers.

  • Apply static and dynamic application security testing (SAST and DAST) to assess source code and software behavior, respectively, and detect misconfigurations and vulnerabilities to be remediated.

  • Establish vulnerability disclosure programs oriented to researchers that can identify security issues and ensure that published CVEs contain the root cause or common weakness enumeration (CWE).

  • Comply with basic cybersecurity practices such as those outlined in CISA's Cybersecurity Performance Goals.

Practices such as these, especially for companies just getting started with cybersecurity, can be implemented gradually, first addressing, for instance, critical infrastructure and products and new software.

Secure-by-Default

The authoring agencies urge manufacturers to deliver products that the end users do not have to struggle to protect against known and prevalent risks. These products, by default, should come with sufficiently secure configurations. Responsibility for security should fall first and foremost on the product deliverer's shoulders, and security controls should not represent an additional cost to customers. As the agencies say, manufacturers should incorporate such controls "in the base product like seatbelts are included in all new cars. Security is not a luxury option but is closer to the standard every customer should expect without negotiating or paying more."

In addition to Secure-by-Design practices, the authoring agencies suggest manufacturers prioritize Secure-by-Default configurations for their software and provide them recommendations such as the following:

  • Offer products that require establishing solid passwords during installation and configuration, as well as multi-factor authentication (MFA) for privileged users.

  • Implement single sign-on (SSO) technology so that users can enter their login credentials only once to gain access to all the services they are allowed to use.

  • Provide high-quality audit logging. (In this process, activities or incidents within the software are documented with details such as time of occurrence, responsible parties and impacts).

  • Deliver recommendations on role-based access controls or authorizations, as well as warnings in cases of non-compliance.

  • Do not include backward-compatible legacy features in the products.

  • Significantly reduce the size of the "hardening guides" (expectations of secure configuration and handling of the product to be achieved by customers) by integrating many of their components into the product's default configuration.

Some of these latter practices require customers' input, so it is also suggested to manage with them significant incentives (e.g., listing potential risks) in favor of adopting improved security standards.

Final recommendations

The document referenced here concludes with recommendations for software manufacturers' customers. Perhaps the most relevant advice is encapsulated in the following sentence: "[The] authoring agencies recommend that organizational executives prioritize the importance of purchasing Secure-by-Design and Secure-by-Default products."

A growing number of organizations will tie up their success with the security of their products and systems. If your company, whether a software developer and/or supplier, is considering committing to Secure-by-Design and -Default practices, Fluid Attacks offers you a comprehensive security testing service: Continuous Hacking. Using manual and automated techniques such as SAST, DAST, SCA and CSPM, we contribute to making your products free of vulnerabilities from the earliest stages of the SDLC.

If you want more details on the proposal from CISA and the other agencies, check out their full PDF here. To read about issues related to the security of your code, visit our series of posts on secure code review.

Subscribe to our blog

Sign up for Fluid Attacks' weekly newsletter.

Recommended blog posts

You might be interested in the following related posts.

Photo by James Lee on Unsplash

A lesson of this global IT crash is to shift left

Photo by CardMapr on Unsplash

Users put their trust in you; they must be protected

Photo by Wilhelm Gunkel on Unsplash

Transparency for fewer supply chain attacks

Photo by Sarah Kilian on Unsplash

Develop bank applications that resist DDoS attacks

Photo by Towfiqu barbhuiya on Unsplash

Ensuring compliance and security in the banking sector

Photo by Andre Taissin on Unsplash

With great convenience comes increased risk

Photo by FlyD on Unsplash

Software supply chain management in financial services

Start your 21-day free trial

Discover the benefits of our Continuous Hacking solution, which hundreds of organizations are already enjoying.

Start your 21-day free trial
Fluid Logo Footer

Hacking software for over 20 years

Fluid Attacks tests applications and other systems, covering all software development stages. Our team assists clients in quickly identifying and managing vulnerabilities to reduce the risk of incidents and deploy secure technology.

Copyright © 0 Fluid Attacks. We hack your software. All rights reserved.