Can Secure by Design be saved?
We think so...
The technology landscape has undergone a pivotal shift toward making cybersecurity a foundational element of product design - through two leading efforts: DevSecOps and Secure by Design. Recently, leading organizations such as the Cybersecurity and Infrastructure Security Agency (CISA), Google, and Amazon Web Services (AWS) are attempting to re-invigorate and champion the "Secure by Design" approach with new-found gusto. While this mindset has been around for some time, there is an emphasis on integrating robust security measures directly into the development and deployment of technology products, fostering resilience in an interconnected world, rather than bolting on security at the end before a release, as what was happening in the initial onset of Secure by Design efforts..
Let’s take a look at the recent articles:
CISA's Initiative on "Secure by Design"
CISA, in collaboration with global cybersecurity agencies, has issued updated guidance advocating for a new security paradigm. This initiative focuses on three core principles:
1. Shifting Responsibility: Security is reframed as a shared duty among manufacturers, developers, and consumers, ensuring that safe technology is not a luxury but a baseline expectation.
2. Radical Transparency and Accountability: Technology providers are encouraged to openly demonstrate their commitment to secure practices, offering customers insights into security measures and updates.
3. Executive Leadership in Cybersecurity: Security is to be driven by top-down initiatives, with organizational leaders fostering a culture of proactive risk management.
Through global partnerships, CISA aims to create a universal framework, aligning regional cybersecurity strategies like Japan's Cybersecurity Strategy and Europe's Cyber Resilience Act to a unified vision.
Google's "Secure by Design" Pledge
Google's approach to security builds on its longstanding focus on data protection and product reliability. Their pledge highlights key actions:
Data Minimization: Google advocates for designing systems that reduce sensitive data exposure, ensuring minimal risk in the event of a breach.
Proactive Threat Modeling: By anticipating potential vulnerabilities, Google's development processes aim to mitigate risks before they become exploitable.
Transparent Ecosystem: Google underscores the need for industry-wide collaboration and education, empowering developers and customers to prioritize security.
This pledge represents a call to action for the technology sector to standardize secure design as an industry benchmark.
AWS's Commitment: Security by Default
Amazon Web Services' white paper delves into strategies for embedding security into the DNA of software development. AWS outlines:
1. Integrated Security Measures: Encouraging developers to use tools like encryption, identity management, and network monitoring as intrinsic elements of their platforms.
2. Education and Best Practices: Offering comprehensive training for developers and customers to understand and implement security principles effectively.
3. Resilient Architectures: AWS promotes building systems that are inherently robust, reducing downtime and vulnerabilities.
Defensible Systems’ “Secure by Design” - a Reality Check
The "Secure by Design" philosophy underscores a collective acknowledgment that cybersecurity can no longer be an afterthought. Instead, it must be foundational, ensuring that:
Technology providers take ownership of risks associated with their products.
Consumers demand transparency and accountability in their digital tools.
Governments and private sectors collaborate to set universal standards for cybersecurity.
But what does this actually mean for security practitioners and for developers or engineers outside of a security organization to do “Secure by Design”. Here is Defensible System’s take on the resurgence and fresh outlook of Secure by Design.
1. Security tooling must be embedded into a product lifecycle.
Tooling during the SDLC must make the lives of developers easier. It’s a topic as old as DevSecOps, but until security is no longer bolted on at the end we will continue to fail at “Secure by Design”. Towards this end, one of the areas often overlooked is secure development frameworks and APIs. Using secure frameworks and APIs simplifies security implementation for developers by providing pre-built functionalities like authentication, encryption, and data validation. This is even more helpful when it comes to building SBOMs and evaluating where a flaw/vulnerability is – think back to searching for “where is Log4j”? Not to mention, as asset inventories grow to include libraries it is even more valuable. Many organizations are beginning to plan for a post-quantum environment and one of the key areas is to know the libraries with potentially deprecated algorithms.
Embedding security in a DevSecOps pipeline ensures continuous integration of security checks, enabling real-time feedback for developers during coding. Multiple tools today can scan for vulnerabilities and alerts developers within pull requests – as once explained to a non-technical audience: “it’s like spell check!”.
2. Security teams need to be reimagined.
Unless it is operational security practitioners, such as those in the SOC, or threat intel or hunter teams, security architects and champions need to be embedded into projects. They should be at the forefront of a project to understand the business case, feature requirements and drive security requirements. An integrated technology team with solution and security architects is essential to moving fast and building security into a product lifecycle. The security architect should be responsible for threat modeling during the design phase to understand potential vulnerabilities and plan mitigations early. Individuals without security expertise should not be in a position to analyze security flaws and should not be in a position to make recommendations.
In addition, security oversight (e.g., GRC) functions need to grow technically to understand modern technology stacks. The oversight functions should be pulling data from the tools mentioned above as well as common tooling in the enterprise to evaluate an asset — rather than waiting for a release to evaluate an asset.
3. Secure by Design cannot be a toll gate to pass.
Design reviews in the early stages of a project coupled with (continuous) security testing is the approach the industry needs to adopt. By performing reviews after a solution is designed, developed and ready to deploy defeats the purpose of “secure by design” – it’s a compliance check.
4. Articulate the Business Value of Secure by Design.
In most cases, security still struggles to articulate the business value of their efforts – unless it is too late. By embedding security truly through design there are:
Time Savings: Automation tools reduce manual effort, letting developers focus on functionality.
Simplified Processes: Prebuilt security modules in frameworks eliminate the need for custom solutions.
Proactive Risk Management: Early detection reduces the cost of fixing vulnerabilities in later stages.
Enhanced Collaboration: Integrated feedback mechanisms improve coordination between developers and security teams.
This paradigm shift promises a future where technology is not just innovative but inherently safe, enabling a more secure and resilient digital world.
For a detailed exploration of these initiatives, visit CISA’s Secure by Design Initiative
https://www.cisa.gov/secure-design,
Google’s [pledge overview https://blog.google/technology/safety-security/google-secure-by-design-pledge/ , and
AWS’s white paper on secure development https://aws.amazon.com/blogs/security/new-whitepaper-available-building-security-from-the-ground-up-with-secure-by-design/.