The Secure by Design initiative has been heavily promoted by government agencies — the U.S. Cybersecurity and Infrastructure Security Agency (CISA), for example, and the U.K. National Cyber Security Centre (NCSC) — and by tech giants including Google, Meta, and Netflix. However, much less attention has been paid to Secure by Design's cousin, Secure by Default.
Product security engineer Rami McCarthy pointed out in the TL;DR sec newsletter that the two initiatives share a fundamental approach to security: they should allow developers to work safely while adding guardrails against insecurity.
Here's what you need to know about Secure by Default — and how it can help harden your applications. Plus, experts explain some of the roadblocks to implementation, and general limitations of developer-centric AppSec.
[ Related read: Legacy AppSec holds back Secure by Design | Webinar: Secure by Design: Why Trust Matters ]
Secure by Default: What you need to know
McCarthy cited a number of key characteristics shared by both Secure by Default and Secure by Design:
- They are proactive, not reactive. They focus on prevention rather than correction. The goal is to funnel users to the secure approach, removing any potential gap in security and eliminating reactive "thrashing" responses when issues are detected.
- They are prescriptive yet flexible. These methods dictate safe practices while accommodating flexibility in approach.
- They are invisible. The ideal Secure by Default approach seamlessly integrates security into users’ regular operations.
- They are extensible. Secure defaults should be built to accommodate system changes and growth without compromising security. You should be able to add additional controls and extend controls to new systems.
- They need to consider migration paths. To encourage adoption, secure defaults need to consider the migration path and integration points with existing solutions.
Joe Nicastro, field CTO at Legit Security, said these controls should largely be transparent to developers. “They should be implemented in an automated way, and alerts of any deviation should be sent into tools developers already work in and are familiar with.”
Alex Vesey, a software engineer in the CERT division of the Software Engineering Institute at Carnegie Mellon University, said effective secure defaults should prioritize the security of the many over the needs of the few. “A secure default should be just that — default — and in most cases, should not even have a setting or option to turn it off.”
“This obviously needs to be weighed against customer needs. However, in cases where there is an industry standard or widely accepted best practice, omitting the insecure option will be most effective.”
—Alex Vesey
Making AppSec hardening less hard
Secure by Default is part of a larger push in the security industry — a push being evangelized most notably by the CISA — to encourage software suppliers to start to integrate more secure practices when developing their products.
Chris Hughes, CISO and co-founder of Aquia, said the need was there because otherwise customers bear the brunt of software risk. Historically, products were shipped with insecure configurations and a “hardening guide” that could make them more secure. Secure by Default is a push to have a product be secure from the start so the customer doesn't need to harden it.
“This push wants to switch that paradigm and have software suppliers take more responsibility for the security outcomes of their products.”
—Chris Hughes
Jon France, CISO of the cybersecurity training and certification organization ISC2, said vendors shouldn't expect consumers to know how to make something secure. He cited Apple as a company that’s wedded itself to the idea of secure out of the box. “Most of their products are relatively secure by default,” France said.
MJ Kaufmann, an author and instructor with O'Reilly Media, said Secure by Default helps organizations move security from being an afterthought to being a baked-in part of the process. “Security is done right from the outset, and any deviation takes effort."
“In application security, baking in security scanning, such as SAST, ensures that code is analyzed as part of the build pipeline rather than as an added step after. In infrastructure security, adding firewall rules and access control lists that deny all traffic by default reduces the risk of malicious inbound traffic. And for endpoint security, implementing automatic updates keeps machines safe with up-to-date patches without any user effort.”
—MJ Kaufmann
Aquia's Hughes said much work remains, however, for the industry to define what it means for a product to be secure by default and to drive adoption of it. “If a company can produce something without emphasizing security that's cheaper, that they can get to market faster than their competitors, and customers aren't demanding it, they're not going to go out of their way to do it, to make the investment in time and resources,” he said.
“If the demand doesn't come from customers, it's going to have to come in the form of regulation. I don't think anybody wants that."
—Chris Hughes
An intimate connection with Secure by Design
Secure by Default can be intimately connected to Secure by Design. Legit Security’s Nicastro explained that developers need to create and implement code as fast as possible, but that goal comes with risks, since developers aren’t security professionals.
“By creating secure defaults, organizations can adhere more closely to Secure by Design goals by nudging developers into doing the right things through the use of paved pathways, guardrails, and secure architectural patterns."
—Joe Nicastro
On the other hand, Secure by Design can also contribute to more secure defaults. CMU’s Vesey said that by setting Secure by Design goals — such as having a good relationship with a vulnerability disclosure platform or committing to fixing all pedantic compiler warnings — organizations can enable developers to better implement secure defaults.
“When security is thought of as a main business goal, Secure by Default elements of the product should manifest as requirements developers can prioritize and implement.”
—Alex Vesey
Jeff Williams, CTO and co-founder of Contrast Security, said problems can arise, however, because the threat model can be very different for each application in each client. “For example, one person might use Excel to figure out their intramural soccer league schedule,” Williams said. “Another might use it to analyze the organization's financial results. The question of what is the right defense for each use case is very different.”
Secure by Design is absolutely critical, Williams said. “There is no recourse if the right defenses to counter the expected threats simply aren’t present.”
“Secure defaults are also important, as even the world's best security defenses don't keep you safe if they're not properly configured. I'd argue that secure defaults are simply part of Secure by Design,” he added. “If the security defenses aren't designed and initially configured in a way that encourages secure use, then it's probably not a very good design.”
—Jeff Williams
The long road to ubiquity for Secure by Default
Secure by Default can also play an important role in platform engineering. “Because platform engineering is all about designing and supporting the underlying platforms that support applications and services, defaults are a core part of their mission,” O’Reilly’s Kaufmann said. “Platform engineering teams that design defaults into their operations will improve efficiency, security, and performance, creating environments that are easier for their organization to leverage.”
Secure by Defaults should be a focus of platform engineers and the platforms they provide, Vesey said. “Given the goal of platform engineering is to enable self-service for software engineers to access cloud resources and other tools, this decentralized approach to resource management would benefit from secure defaults,” he said. “This includes configuration of cloud resources, the tools to build and access them, as well as the test suite developers would use to ensure their product is also secure by default,” he continued.
Another interesting connection between the two initiatives is that secure defaults in developer platforms could further the platform engineering goal of reducing cognitive load on developers if they can trust the platform is making appropriate security decisions, Vesey said.
While progress is being made in the field of Secure by Defaults, McCarthy acknowledged that there's still a long way to go before they become ubiquitous across all technology sectors.
“Ideally, Secure by Default would be a feature of everything, not a bolt-on product category. We’re making progress, but I don’t think we’re all that close.”
—Rami McCarthy
Matt Rose, former Field CISO for ReversingLabs, said the concept of Secure by Design/Secure by Default sounds great, but there is a huge obstacle to overcome in many organizations.
"Modern enterprise software has been evolving for years with updates, patches, and new versions. It is in a perpetual state of improvement and change. Secure by Design/Secure by Default may work for brand new software packages, but is a challenge for existing software programs that have already been designed, developed, and deployed to production."
—Matt Rose
