As cybersecurity professionals, we need to know that the software products we acquire are safe and able to support or accommodate the procedures and tools we use to keep attackers at bay while performing their given functions.With attacks perennially on the rise and the software supply chain remaining as vulnerable as ever, there is momentum gathering to see two major concepts enshrined in the software development process: secure by design and secure by default.But what exactly is the difference between the two, is one more important than the other or more likely to succeed, or do we need both?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. The concept of secure-by-design software is far from new and reaches back more than 50 years to sources such as The Ware Report. We’ve seen a recent resurgence in support for the concept, led primarily by Cybersecurity and Infrastructure Security Agency (CISA), which has published several guides on the topic, as well as alerts, and a voluntary pledge that companies have signed.Secure-by-default software is created with safeguards and security postures in mind throughout the development process, striving to avoid the age-old practice of “bolting on” of security after the fact.CISA has thrown its support behind this concept with the assumption that technology has historically been inherently insecure by design due to vendors prioritizing competing interests such as speed to market, revenue, features, and profits over security, with the systemic risks being passed downstream to customers, consumers, citizens, and society.This has often left customers needing to patch, harden, configure, and address inherent product weaknesses and vulnerabilities or risk falling victim to security incidents.According to CISA, “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.”Vendors following secure-by-design principles have integrated secure development practices such as NIST’s Secure Software Development Framework (SSDF) into their system/software development lifecycle, as well as integrating activities such as threat modeling throughout, including deployment.
How developers can follow secure-by-design principles
CISA provides a number of specific examples where secure-by-design development can be implemented:
- Memory-safe programming languages.Secure hardware foundations and the use of secure software components such as libraries and modules.Software bills of materials (SBOMs)Static/dynamic application security testing (SAST/DAST); essentially integrating automated security testing into development, which is often facilitated via continuous integration and continuous development 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 development lifecycle 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 more securely designed products can of course be used in ways that present risks despite their sound design.
The main secure-by-design problem: getting developer buy-in
However, as stressed by CISA in their publications, this requires significant investment and buy-in from executives and leadership so that secure-by-design principles can be prioritized on a par with other activities and incentives and be driven as a cultural transformation, as opposed to a verbal mantra.The challenge here is that, while from a security perspective we may agree that it is wise, it could inevitably put developers and vendors at a competitive disadvantage. Those who don’t prioritize secure-by-design can 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 of return on investment, and the reality that cyber is just one of many risks their business is facing. They must maintain market share, hit revenue targets, deliver customer satisfaction, raise brand awareness/exposure, and achieve the most advantageous business outcomes.It is a challenge to maintain a singular focus on cybersecurity: Companies have finite time, attention, and resources, and especially in their earlier phases must allocate those resources strategically to ensure the growth and resilience of the overall organization.Furthermore, despite a lot of fear, uncertainty, and doubt that cybersecurity incidents generate around damage to brand reputation, erosion of customer trust, and loss of revenue, several sources have demonstrated that cybersecurity incidents do not have significant impacts on the viability and profitability of companies. Despite SEC 8-K filings of material security incidents, organizations suffer little, if any, short-term impact on share prices, nor long-term consequences.This means we’re asking a developer in a capitalist society to voluntarily put themselves at a competitive disadvantage to arbitrarily prioritize security, knowing that doing so when their peers aren’t could negatively impact them.
Secure-by-default products come fully primed for security
Secure-by-default development focuses on ensuring that software components arrive at the end-user with all security features and functions fully implemented, with the goal of providing maximum security right out of the box.Most cyber professionals have experienced having to apply CIS Benchmarks, DISA STIGs, vendor guidance and so on to harden a new product or software to ensure we reduce its attack surface. Secure-by-default flips that paradigm on its head so that products arrive hardened and require customers to roll back or loosen the hardened configurations to tailor them to their needs.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 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. This configuration shift pivoted to secure-by-default and would require customers to specifically go in and publicly expose an S3 bucket rather than having to make it private at configuration.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 minimizing the attack surface and risk of incidents from the onset of product/service usage.
Diverging from secure-by-default settings can bring additional risk
According to CISA, “secure-by-default products are designed to make customers acutely aware that when they deviate from safe defaults, they are increasing the likelihood of compromise unless they implement additional compensatory controls.”CISA emphasizes the role of configurations when discussing secure-by-default, where it points to examples such as:
- Multifactor authentication.The elimination of default passwords.Single sign-on.Secure logging.But secure-by-default presents the potential that vendors are providing products with secure configurations, customers may alter those configurations to suit their needs, which may introduce risk.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 for a vendor to enumerate and address every variant on configuration.This can 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.CISA has even introduced a new concept they call “loosening guides” (as opposed to hardening guides that would historically accompany a product) for secure-by default products. CISA suggests these would be necessary to explain how to loosen a product by changing default configurations baked-in to prevent malicious activity or the risk of exploitation and incidents.
Baked-in security can come at the cost of useability
More important is the fact that products get integrated into an enterprise ecosystem of cloud, infrastructure, SaaS, APIs, microservices, workloads, networking, and more, all of which when not holistically and coherently implemented present seams that attackers can exploit.Notable here is the ever-present 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:” in other words, 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 the enterprise and user experience. This can have 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.On the plus side, recent research suggests that good user experience (UX) design can improve cybersecurity and support the integration of 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 specialties such as customer/user Experience (CX/UX).
Both offer improved security despite opportunities and challenges
It is clear that both secure-by-default and -design concepts offer opportunities to benefit the secure posture and reduce the risk of companies and end users. While neither is without challenges, there is a lot of opportunity for each to have a positive impact on the software and technological ecosystem.Secure by design involves building security fundamentals into the primitive structure of a system, software, or product, including activities such as threat modeling and seeking to eliminate entire classes of vulnerabilities. It requires vendors to invest in security throughout the entire SDLC and put security on par with other incentives and considerations such as speed to market, feature velocity, revenue, profit, and more.Secure by default focuses on hardening products prior to delivery to mitigate customer vulnerability and exploitation and takes more ownership of delivering securely configured products from initial delivery. This seems like a much more practical approach and likely to gain traction, given it isn’t necessarily competing with other priorities such as speed to market, revenue, feature velocity, and more.Both concepts are 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, but the potential benefits are enormous, as software powers nearly every aspect of modern society, with no signs of slowing down.
First seen on csoonline.com
Jump to article: www.csoonline.com/article/3631188/secure-by-design-vs-by-default-which-software-development-concept-is-better.html
