Each new setting increases the cognitive burden on end users…instead, the most secure setting should be integrated into the product by default - The United States Cybersecurity and Infrastructure Security Agency
As we’ve covered extensively, security in the software development process is broken today. Broad adoption of DevSecOps has resulted in software engineers adding configuration and deployment of infrastructure to their day-to-day dev responsibilities. However, developers typically aren’t Terraform experts, lack security context, and don’t have security as their first priority. The results?
- Longer development and deployment times
- Lower dev productivity & velocity
- Rampant misconfiguration, resulting in incidents, breaches, and downtime
You can read more about how we got here in our Death of DevSecOps series (part 1, 2, 3).
The future of infrastructure configuration in software engineering is one where machines make security decisions, instead of humans. This secure-by-default future requires thoughtful changes to tools, processes, and how teams work together. In this blog, we’ll cover how modern companies are implementing secure defaults.
Building a secure-by-default culture
Implementing secure defaults requires three primary components:
- updated design thinking
- a new security team
- a modern, secure-by-default dev stack
Updated design thinking
Governments and leading technology companies are building secure design principles that help companies create secure defaults.
CISA’s secure design principles
The Cybersecurity and Infrastructure Security Agency (CISA) in collaboration with the NSA, FBI, and other federal governments recently released their Principles and Approaches for Secure-by-Design and -Default. In it, they make it clear that secure defaults should be the standard, and that complexity of security configuration should not be an end user problem.
This report makes it clear that secure defaults should be a priority for anyone building software, for internal or external usage.
Google’s Secure by Design
Google has recently released their Secure by Design principles, which focus on the idea that developers are users of software as well. In it, they focus on the consequences of misconfiguration:
It’s no wonder so many incidents start with an error when developing and deploying systems: failure to consider a security threat during the design of a system, introduction of a coding error during development that results in a vulnerability, or a configuration change that exposes a deployed system to attack
You can read more about Google’s Secure by Design principles here.
UK’s National Cyber Security Centre
Since 2019, the UK’s National Cyber Security Centre has published security system design principles. Understanding and adopting them is a great start to building a secure application. In summary:
- Establishing context before designing the system
- Make compromise difficult
- Make disruption difficult, plan for:
- Make compromise detection easier
- Reduce the impact of compromise
The role of the security team
As demonstrated by national agencies from a variety of countries and the world’s foremost tech companies, secure defaults are a necessity for the future. To help bring this philosophy to fruition, a new security team is needed.
The modal security team of the present is one of little political capital: a group “off in the corner” flagging security vulnerabilities and injecting unnecessary steps or action into the lives of software engineers. These teams are reactive, slowing developers down and catching problems only after-the-fact.
The security team of the future is a proactive guide: understanding, advocating for, and embedding secure defaults. They end result is a more secure development practices, resulting in fewer incidents, and a developer experience that is drastically improved by secure defaults.
Secure-by-default software stack
After taking into account secure design principles, it is important to use a software architecture that supports secure defaults. There are 3 levels of maturity when focusing on what software to use, when building a secure-by-default stack.
Basic: Utilizing secure-by-default libraries
Standardizing on libraries that automatically enable the above principles and other security best practices, is one of the easiest ways how to operationalize secure defaults. Over the past few years, significant work has been done by the cloud providers (Google, AWS, Microsoft) as well as other security leaders to make available libraries that are secure-by-default. These are by and large open source, free to use, and enforce secure best practices.
Some examples of libraries with secure defaults are:
- Netflix’s Lemur
- Google’s GoLang libraries
- Validator.js for string validation and sanitization
- Google’s Tink for secure encryption
See a full list here: https://github.com/tldrsec/awesome-secure-defaults
Companies just starting the journey to secure defaults are using these libraries across some projects, or within individual teams. In some cases these libraries are the standard for a subset of use cases within a company.
Advanced: Embedding tooling and best practices within developer workflows
Advanced companies that are continuing their secure-by-default journey are standardizing on secure-by-default libraries, and integrating other secure default practices through their engineering ecosystem.
One of the primary causes of slow developer velocity is that security teams have asked software engineers to work with external toolsets that they aren’t familiar with. This context-switching results in lower productivity and developers. Instead, advanced organizations are embedding secure defaults within tooling that they already use. Some examples include:
- Instead of listing security best practices in a wiki or obscure document, embed them into IDEs.
- Avoid click-ops and work in familiar tools (IDEs, Git, etc.)
- Embed context wherever configuration occurs
- Make recommendations where appropriate for some use cases
- Provide proactive feedback as part of the configuration experience, instead of after
- Partial environment separation
Expert: Automated security choices & executive buy-in
Fully developed secure default platforms feature complete automation of security choices. There is no single off-the-shelf product that can do this, and most companies looking to implement secure defaults have a platform or infrastructure team that are building an integrated developer platform with the following capabilities:
- Secure design principles are fully adopted and considered at every stage of the development process, from inception to deployment
- Embedded tooling as described in the Advanced section
- Opinionated recommendations for most scenarios
- Standardization of code and configuration patterns
- Full adoption of best practices with buy-in across various teams
- Extensive use of code and configuration generation, instead of manually writing code
- Version control highlighting exceptions to secure defaults
- CI tooling with security checks embedded
In companies with advanced secure defaults, security, infrastructure, and platform teams must work together to build opinionated combinations of cloud resources. They bake automatic configuration choices into existing tools, allowing developers to stay within the tooling ecosystem they love and are familiar with. This can only occur with executive buy-in across most involved functions: the product, engineering, platform, data, and more.
Conclusion
Building secure defaults is more important than ever, driving both a reduction of incidents and an improvement in developer productivity. National governments and leading technology companies agree that secure design and secure-by-default are needed to combat the continuous rise of cybercrime around the world.
The path to achieving secure-by-default lies in software and people. It won’t be an easy task, but it is one that is worth the investment. Security teams can help make the world more secure while empowering developers to focus on what they are good at: shipping software.
To build secure-by-default configuration into your stack, get started with Resourcely today!
