Secure-by-Design vs. Secure-by-Default: What's the Difference?
A look at the two concepts and key distinctions between the two
We’ve seen a lot of momentum around Secure-by-Design/Default, particularly due to recent pushes from the Cybersecurity and Infrastructure Security Agency (CISA).
But what exactly is the difference between the two, is one more important than the other, is more more likely to succeed and are they both needed?
That’s what we will be taking a look at in this article, so let’s dive in!
Thanks for reading Resilient Cyber Newsletter! Subscribe for FREE and join 7,000+ readers to receive weekly updates with the latest news across AppSec, Leadership, AI, Supply Chain and more for Cybersecurity.
Interested in sponsoring an issue of Resilient Cyber?
This includes reaching over 7,000 subscribers, ranging from Developers, Engineers, Architects, CISO’s/Security Leaders and Business Executives
Reach out below!
Level Setting
While the concept of Secure-by-Design is far from new, and reaches back over 50 years to sources such as The Ware Report, as I wrote in “Cybersecurity First Principles & Shouting Into the Void”, we’ve seen a recent resurgence, being led by CISA who have published several publications on the topic, as well as Secure-by-Design Alerts, and a voluntary Secure-by-Design pledge that companies have signed.
I have discussed these previous in pieces such as:
The overarching premise of CISA’s approach is that technology is inherently insecure by design due to vendors prioritizing competing interests such as speed to market, revenue, features, profit and more ahead of security, with the risks being passed downstream and externalized onto customers, consumers, citizens and society, creating systemic risks.
This is due to the fact that technology and software drives every aspect of society from consumer goods to critical infrastructure and national security.
This often leaves customers needing to patch, harden, configure and address inherent product weaknesses and vulnerabilities or risk falling victim to security incidents.
That said, there are key differences between Secure-by-Design and Secure-by-Default, both technically and as well as in the market and supply chain sense, which are worth discussing.
Secure-by-Design
First off, let’s take a look at how CISA defines each concept, starting with Secure-by-Design.
It is stated “Secure-by-Design means that technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data and connected infrastructure”.
In essence, SbD means the vendor has integrated secure development practices (e.g. NIST’s Secure Software Development Framework (SSDF)) into their system/software development lifecycle (SDLC) and are integrating activities such as Threat Modeling into throughout the SDLC, including deployment.
It is striving to avoid the age old “bolting on” of security rather than “building it in”.
However, as stressed by CISA in their publication, this requires significant investment and buy-in from executives and leadership so that SbD can be prioritized on par with other activities and incentives and be driven as a cultural transformation, as opposed to a verbal mantra.
Specific examples CISA provides include:
Memory safe programming languages
Secure Hardware Foundations and the use of Secure Software Components (e.g. libraries, modules etc)
SBOM’s
SAST/DAST (and arguably SCA, IaC scanning et. al - essentially integrating automated security testing into the SDLC, which is often facilitated via CI/CD pipelines)
These activities are aimed at eliminating entire classes of vulnerabilities, mitigating the inherent risk of a product by building with secure foundations and components, and identifying weaknesses and vulnerabilities earlier in the SDLC (e.g. DevSecOps/Shift-Left etc.) rather than passing them downstream to customers in products.
Secure-by-Design also is an opportunity to reduce specific types of attacks and weaknesses, outside of the control of the customer, unlike Secure-by-Default which we will discuss next, which involves configurations and can be manipulated by the customer and potentially introduce risk.
That said, even the more securely designed products can of course be used in ways that present risks despite their sound design.
Secure-by-Default
Shifting from Secure-by-Design, let’s take a look at Secure-by-Default.
CISA emphasizes the role of configurations when discussing Secure-by-Default, where they say Secure-by-Default includes examples such as:
MFA
Eliminating Default Passwords
SSO
Secure Logging
CISA even introduces a new concept they call “Loosening Guides”, where rather than “Hardening Guides” for products/services/software, organizations would receive an inherently secure and hardened product and then need to loosen the product by changing default configurations which were baked-in to prevent malicious activity or putting end users at risk of exploitation and incidents.
We all know the experience of having products and then needing to go apply CIS Benchmarks, DISA STIG’s, Vendor Guidance and so on to harden the product/software to ensure we reduce its attack surface.
This paradigm shift would pivot from that model and have products arrive in a hardened state and require customers to roll them back, or loosen the hardened configurations to tailor it to their needs. This of course would cause friction when it comes to user experience, where users feel the need to tailor a product to do exactly what the business needs or wants it to do, even if some of that functionality may not be in the best interest of security.
One of the most notable examples of Secure-by-Default that comes to mind for me when thinking about cloud for example is the AWS Simple Storage Service (S3). We saw several high profile broadly impactful security incidents due to publicly exposed AWS S3 buckets, often exposing sensitive data.
Ironically, despite coming out in March of 2006, and having a laundry list of security incidents associated with it, AWS didn’t make S3 buckets private by default until 2023, nearly 17~ years later. (For a more detailed discussion on the Shared Responsibility Model and Cloud Security, see my article “Cloud Shared Responsibility Model: Time for a (R)Evolution?”)
This configuration shift pivoted to Secure-by-Default and would require customers to specifically go in and expose an S3 bucket publicly, versus needing to make the bucket private when they provision and configure it.
Examples like this are clear cases where vendors can bake Secure-by-Default configurations into their products and services, ensuring customers have guardrails in place to keep them from doing things they likely shouldn’t and minimize the attack surface and risk of incidents from the onset of product/service usage.
Secure-by-Default of course presents a situation where although vendors may be able to provide products with secure configurations, customer may alter those configurations, which may introduce risk.
Opportunities and Challenges
Now it is clear that both Secure-by-Default and Design both offer opportunities to benefit the secure posture and risk of customers and consumers.
That said, both come with inherent challenges as well.
Secure-by-Design of course requires vendors to invest in security throughout the entire SDLC and put security on par with other incentives and considerations we have discussed, such as speed to market, feature velocity, revenue, profit and more.
The challenge here is that, while from a security perspective we may agree that it is wise, it could inevitably put organizations at a competitive disadvantage. If my competitor isn’t prioritizing Secure-by-Design, they are able to get features, functionality and products out to market faster, leading to potentially more market share, revenue, customer attraction/retention and more.
Additionally, many vendors are venture/capital backed, which comes with expectations on ROI. It also comes with the reality that cyber is just ONE risk the business is facing, not the only risk, as I discussed in my article “Cybersecurity’s Delusion Problem”.
The business is inevitably dealing with many other risks and considerations, such as keeping pace with competitors, market share, revenue, customer satisfaction, brand awareness/exposure and business outcomes. Companies have finite time, attention and resources, especially in the earlier phases of the company and must allocate those resources strategically to ensure the growth and resiliency of the overall organization, not just with a singular focus on cybersecurity.
Furthermore, despite a lot of FUD and claims around brand reputation, customer trust, loss of revenue, and more, currently, several sources demonstrate that cybersecurity incidents do NOT have significant impacts on the viability and profitability of companies, such as I pointed out about Microsoft, or in Kelly Shortidge’s “Markets DGAF about Security”, and a recent WSJ article titled “What is the Market Impact of the SEC’s Cyber Disclosure Rules? Not Much”.
The latter of which demonstrated that despite SEC 8-K filings of material security incidents organizations suffered little if any short term impact to share prices, nor long term consequences.
This means we’re asking businesses, in a capitalist society, or voluntarily put themselves at a competitive disadvantage to arbitrarily prioritize security, knowing doing so when their peers aren’t, negatively impacts them.
The markets, nor consumer spending behaviors are creating sufficient incentives for changes in vendors behaviors when it comes to cybersecurity.
Additional challenges include the fact that while we continue claim “security is a subset of quality”, we lack a universal definition of what secure is and how to measure it, as well as how secure is secure enough, and who is going to pay the cost, something I address in the article “Software’s Iron Triangle: Cheap, Fast and Good - Pick Two”.
Secure-by-Default on the other hand seems much more practical and likely to gain traction, given it isn’t necessarily competing with other priorities such as speed to market, revenue, feature velocity and more.
That said, it isn’t without its own challenges as well. On one hand, while vendors inevitably can ensure products they ship have secure defaults such as MFA, SSO, logging and more, as defined by CISA, there are some obstacles.
One of which is that modern environments are incredibly complex, and even single products can have exponential variations of configurations, making it unrealistic a vendor can enumerate and address every variant on configuration. More importantly though is the fact that products get integrated into an enterprise ecosystem of cloud, infrastructure, SaaS, API’s, microservices, workloads, networking and more - all of which when not holistically and coherently implemented present seams that attackers can exploit.
Most notably is the persistent battle between security and usability. We all know the phrase “if you want a system to be secure, lock it in a safe and throw it in the lake”. It is a quip on the fact that no system is infallible and often the more secure we make something the less capable and useable it may become.
Often, more rigorous security can mean more friction on things such as the enterprise, and user experience. This can unintended consequences, such as shadow usage (IT, Cloud, SaaS and now AI), due to situations where security is so cumbersome and painful that users simply work around it, creating unintended weaknesses, risks and vulnerabilities.
Luckily, there is increased research surfacing showing how UX Design can improve cybersecurity, and the need to design security into systems and software with the user in mind. This of course brings us back to the concept of Secure-by-Design and the need to conduct proper product management with security as part of the SDLC, and have it working cooperatively with other specialities such as Customer/User Experience (CX/UX).
Conclusion
So while neither Secure-by-Design or Secure-by-Default are without their own challenges, there is a lot of opportunity for each of them to have a positive impact on the software and technological ecosystem.
Secure-by-Design involves building security into the fundamental design and primitive structure of a system, software or product, including activities such as Threat Modeling and seeking to eliminate entire classes of vulnerabilities.
Secure-by-Default on the other hand focuses on hardening products prior to delivery to customers and putting configurations in place to mitigate customer vulnerability and exploitation and taking more ownership of delivering securely configured products from initial delivery.
Both concepts are absolutely critical and required to drive broad risk reduction.
This however requires a convergence between various factors such as market incentives, regulatory forces, business leadership and buy-in and a modernized approach to how we both design, develop and deploy digital products into society.
It is a daunting challenge, the potential benefits are enormous, as software powers nearly every aspect of modern society, with no signs of slowing down.
While we all know the phrase “software is eating the world”, the reality is that this gluttonous consumption has left nearly every aspect of society vulnerable to severe risks, both through benign activity and accidents, as well as intentional exploitation.