Secure by Design and Secure by Default: You need both to boost AppSec

The relationship between the two software security initiatives promoted by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) can be misunderstood. Sometimes Secure by Design and Secure by Default are even pitted against each other. The reality is, though, that they are complementary approaches to security.

Secure by Design is a proactive approach that emphasizes incorporating security considerations throughout the software development lifecycle (SDLC). It is an overarching philosophy that guides the development process, ensuring that security is not an afterthought but an integral part of the system's DNA. It's about anticipating potential threats and vulnerabilities early on and making design choices that mitigate those risks. The approach involves using secure coding practices, conducting security reviews, and embedding security throughout the design process.

By contrast, Secure by Default focuses on ensuring that a system's out-of-the-box default settings are set to a secure mode, minimizing the need for users or administrators to take actions to secure the system. This approach aims to provide a baseline level of security for all users.

Saeed Abbasi, manager of vulnerability research at Qualys, said the two are dependent on each other.

Secure by Design means building a fortress, not a shack — strong foundations, reinforced walls, and airtight architecture from day one. Secure by Default means locking every door and window when construction is done. One without the other is like having steel walls but leaving the front door wide open.

Saeed Abbasi

Yaron Galant, chief product officer at Kiteworks, said that when organizations combine the two approaches, application security (AppSec) can be extended from the planning of a software application to its deployment by an end user. The two complement each other like a healthy diet and exercise, he said.

Secure by Default will be an uphill battle if a product is not Secure by Design. So Secure by Design is the foundation for Secure by Default. You need to have a good foundation.

Yaron Galant

Here's what you need to know about the relationship between Secure by Design and Secure by Default — and how to put them to work in your organization to improve software security.

See Webinar: Why Trust Matters for Software Risk Management

You need both for better software security

Sometimes the two approaches can appear to overlap, said Carol Smith, principal research scientist in the human-machine interaction AI division at the Carnegie Mellon University Software Engineering Institute.

Secure by Design is not just a backend aspect of design, but also what happens between the glass and the end user. If security results in a complicated or, worst case, unusable interaction, people will create workarounds, such as writing down passwords or not using the system. Secure by Design has to be usable by design as well.

Carol Smith

Michael J. Mehlberg, CEO of Dark Sky Technology, said that the two initiatives are opposing sides of the same coin. Secure by Design minimizes the risks during the design, architecture, and development stages. It’s a way to incorporate security-minded tools, techniques, and processes to ensure that whatever software is deployed is as secure as it can be, he said.

Secure by Default, on the other hand, is a way to deploy software so that users can start using it in a secure state, Mehlberg said.

These two strategies complement each other because, without Secure by Design, the software itself will be vulnerable to exploit regardless of how securely it is configured. Conversely, without Secure by Default, even the most securely designed and developed software can leave huge gaps that an attacker can exploit if not configured correctly.

Michael J. Mehlberg

Georgia Cooke, a digital security analyst with ABI Research, said there is little point in having even the best security feature if it is not switched on, not on the right setting, or misconfigured. “Users tend to stick with default configurations, and it is particularly jarring to disable a security feature rather than simply not activate it. It requires justification and encourages pause for thought,” she said.

A vast number of vulnerabilities result from misconfiguration. The provision of a robust default setting mitigates the potential to introduce attack vectors. Naturally, Secure by Default is only of any use if the activated security is well designed and well implemented, necessitating Secure by Design practices to ensure minimal opportunities for exploitation.

Georgia Cooke

Challenges to adoption persist

Both Secure by Design and Secure by Default face challenges to adoption, though they differ. For Secure by Design, resistance tends to come from the business and security teams, whereas for Secure by Default, users are the balky ones.

“Historically, security at the design stage has been a highly manual process mostly done through threat modeling and security design reviews,” said Michael Nov, co-founder and CEO of Prime Security. "As with any manual process, it comes at a cost to the business and security teams."

On the business side, adding one more manual review into the product development lifecycle can delay speed to market, requiring developers to invest significant effort in manual reviews and to build additional security functionality as a result of those reviews, Nov said.

On the security side, this manual process requires significant time and attention from already-stretched-thin security engineers and architects, who are supporting requests from 100 to 200 engineers each. Too many times, the reviews will be done too late and lack consistency, adding to the frustration of development teams, Nov said.

This combination of challenges makes the adoption of Secure by Design difficult for organizations, even one with significant resources and a high focus on security.

Michael Nov

With Secure by Default principles, customers can become frustrated with a product that they feel puts too much in their way, such as excessively regular authentication checks or overly aggressive default firewall rules that limit too much of their traffic. “A fine balance must be struck in defining how much security is really required,” ABI Research's Cooke said.

After that, she continued, the art of Secure by Default lies in the extremely careful design of the UI/UX of an application, making the secure default configurations as invisible as possible to the user, she said.

This is, unavoidably, an additional workload on the developers, particularly as these principles are first being integrated. However, over time, an organization will gain the experience and a backlog of solutions required to implement these principles with minimal overhead.

Georgia Cooke

Conquering challenges with AI code

Zack Glick, CTO of Zatik Security, said another challenge to Secure by Default adoption is vendor pricing. Companies are gating foundational security capabilities behind their high-end tiers and upcharging for things such as multifactor authentication support, he said. That's antithetical to the ideal of Secure by Default.

Imagine if you had to buy the LX model of a car to get seatbelts, brakes, and turn signals.

Zack Glick

Another challenge to Secure by Default adoption is that some organizations think the choice between security and innovation is binary, Glick said. These organizations frequently believe that security features are guaranteed to be barriers to customer adoption due to poor UX, leading to slower customer acquisition and revenue generation, he said.

But in organizations that invest in a proactive security culture, we see successful partnerships between product development teams, security engineers, and UX designers early in the design phase to identify graceful and low-friction security controls and features without compromising customer adoption growth or revenue goals.

Zack Glick

Some of the challenges to adopting Secure by Design and Secure by Default principles may be addressed with artificial intelligence. That's because AI significantly enhances Secure by Design by automating threat modeling, security testing, and predictive analysis, allowing systems to be built with a deeper understanding of potential risks, said James McQuiggan, a security awareness advocate with KnowBe4.

McQuiggan said that AI-powered code analysis can help developers identify and fix vulnerabilities early, ensuring that security is embedded from the ground up, as well as enabling more resilient designs that potentially mitigate risks before they become exploits.

Meanwhile, AI can strengthen Secure by Default by adjusting security settings based on real-time threat intelligence, ensuring optimal protection without user intervention.

AI-driven automation ensures security remains effective over time, preventing misconfigurations and enhancing overall system resilience.

James McQuiggan

Improving AppSec is a matter of knowledge and culture

Both Secure by Design and Secure by Default are founded on knowledge and culture, said Kiteworks' Galant. In order for those principles to work, a company needs to have insight into how attackers work.

Most companies don't have that. Attackers right now are using the same techniques and tactics as nation-states. These are professionals. They're using years and years of know-how, and most companies don't have that knowledge.

Yaron Galant

But it's also about culture, he said. And many companies don't have the right culture. "You need to get buy-in from top management. They need to understand that they need to fund it, budget it, budget time for it, and that productivity might go somewhat down. You need to get buy-in throughout the organization," Galant said.

Eventually, the CEO needs to be interested in it. It's as simple as that. The CEO needs to understand, needs to decide that part of the shareholder value that he or she is in charge of building is tied to producing a secure product and to protecting the security of their customers, not just giving them functionality and experience.

Yaron Galant