In our last blog we looked at some of the reasons why threat actors have been able to breach the online services we use day to day. Vulnerabilities (software bugs or misconfigurations) are chief enablers for threat actors. In this blog we look at the concepts of Secure by Design and Default, how they translate into securing our software supply chain and how the Open Source community is responding to implementing these.

What does Secure by Design and Default mean?

The trusted global cybersecurity advisory organisations have provided us with the following descriptions.

Secure by Design

“Secure-by-Design is a proactive, security-focused approach to the development of digital products and services that necessitates a strategic alignment of an organisation’s cyber security goals. Secure-by-Design requires cyber threats to be considered from the outset to enable mitigations through thoughtful design, architecture and security measures. Its core value is to protect consumer privacy and data through designing, building, and delivering products with fewer vulnerabilities.”

ASD

Secure by Default

“Secure-by-Default is the process of ensuring products are secure to use ‘out of the box’, with little to no additional setup or configuration required.  All built-in security measures are included at no additional cost to the consumer, such as multi-factor authentication (MFA), and audit and security logging. Consumers and users are made acutely aware of the known risks that may be realised if any deviations from the default configuration is made and the increase in likelihood or impact of compromise unless additional mitigations are implemented.”

ASD

These definitions will strike most of us as obvious and raise the question, why do we need to state the obvious? In short, the organisations that develop the digital products and services we use everyday, have not applied these principles to their products and services. Their products have software bugs and/or their services require additional configuration to make them secure. In most cases they charge you to implement the security measures that should have been there out of the box. They know where the vulnerabilities are, but leave it to you to implement and charge you for it. As we saw in the previous blog, threat actors find these vulnerabilities and then exploit them to gain access to data.

How do we get there?

Fortunately, globally the trusted cybersecurity organisations such as ASD, ASCS, NIST, CISA, etc are putting frameworks in place to ensure organisations developing products and services adhere to these standards. As we saw in the case of SolarWinds, company executives are being held accountable.

These frameworks are great, but how do we know whether the organisations that develop the digital products are adhering to them? The Open Source community has responded in numerous projects. The Open Source Security Foundation has two projects, SLSA & Sigstore Also the Cloud Native Computing Foundation’s in-toto and sub projects, Witness and Archivista. These projects standout and are finding wide adoption in the Cloud Native ecosystem.

SLSA & Sigstore

Is a framework to allow any organisation to measure its secure development practices. These practices are outlined in the NIST Secure Software Development Framework. When one reviews these frameworks, you can see that these practices are nothing new, but with SLSA we can measure an organisation’s maturity in implementation of the practices.

In-toto

In-toto also provides attestation to guarantee the software supply chain integrity. It immutably records every step performed and by whom, in the software supply chain. This means that as the end user of the product you are able to verify any step that was performed and by whom. In this way you can determine whether the step was required and if so, was it performed by an authorised person/process.

Memory Safe Roadmaps

While SLSA and in-toto attest the software development lifecycle steps, software code needs to be secure in itself. There are many aspects to this, including developers training in secure coding and processes such as code scanning (fuzzing, SAST, DAST, etc). Another aspect is ensuring that memory safe programming languages are used. The C and C++ languages are examples of languages that do not have memory protection. Memory safety vulnerabilities are the most prevalent software vulnerability.

Conclusion

It is very encouraging to see the industry respond to Secure by Design and Default frameworks, as published by the trusted cybersecurity advisory organisations. As producers of software and digital services invest more into their implementations of these frameworks, we can expect to see a significant attack vector for threat actors diminishing. Another layer in the Defence in Depth security process is being hardened. 

Keen to learn more about Vault Cloud’s capabilities?

Kindly provide your contact details below, and we’ll be in touch.