Cyberrisk from external digital attacks exists in large part because exploitable software vulnerabilities allow bad actors to launch attacks that can result in financial losses, reputational ruin, and legal liabilities. The complexity of software code almost inevitably allows room for errors that result in exploitable vulnerabilities. Potential consequences include the breach of confidentiality of data stored on the software, alteration of data residing on the software, and even the unavailability of the software application for use. With rapid technological advancements, bad actors are developing complex software exploits to undermine the security improvements that come with secure-by-design principles. Large software platforms generate complexity that makes it nearly impossible to detect all possible errors. Complexity also makes such software programs more difficult and expensive to manage. However, a secure-by-demand approach allows organizations to drive the quality of software by stipulating strict requirements for software manufacturers to adhere to, such as secure-by-design and secure-by-default principles.
To date, the threat level is too challenging for industry or government alone to fully defend or protect software systems.Sprawling, complex systems are attractive targets for malicious actors, who often stay hidden and carry out their exploits for extended periods. To date, the threat level is too challenging for industry or government alone to fully defend or protect software systems.1 Since vulnerabilities cannot be completely eliminated, cybersecurity risk cannot be entirely avoided. It can, however, be mitigated. The most practical way to mitigate this risk is by following secure-by-design and secure-by-default principles. Secure-by-design products are those in which software manufacturers—the enterprises that create, deliver, and maintain software—make security a core consideration from the earliest stages of the product development life cycle. Ensuring that the products they use and procure are secure-by-design is essential for organizations to be resilient against ransomware and other forms of malicious cyberactivity.2
Alternatively, secure-by-default means products are resilient against prevalent exploitation techniques out of the box without additional charge.3 Secure-by-default means the software products can be acquired by a user without the need to manually turn on any features or make configuration changes that require extra charges. This means software developers can develop secure-by-default software products through secure-by-design principles.
Software manufacturers can be motivated to follow these principles by tying them to brand sustainability and profitability, thus enabling them to retain clients and attract new business. This scenario does not require government mandates; pure market forces are motivating players to develop secure software for society’s benefit.
Principles in Practice
When software developers establish security requirements for the software they plan to develop, they must understand how each feature may compromise consumer data and privacy. If a line of code meant to provide a certain feature provides room for a breach of consumer data, then the developers should replace that feature or drop it altogether if necessary. At every stage of the development life cycle, there must be proactive, rigorous analysis of potential vulnerabilities and a concerted effort to avoid such vulnerabilities. Software developers need to consider and build security during the design and development of the software. They should also perform risk assessments as they progress and continue to view security as a business goal. Developers must understand how features may be abused and the potential impact of a breach on users.
Stakeholder Expectations
Meeting stakeholder demands for high-quality software with minimal defects can be a high bar to clear. Consumers in a free-market society could demand that software manufacturers develop solutions that meet very rigid security requirements. Software manufacturers would have to yield to those demands by adhering to secure-by-demand and secure-by-default principles.
For open-source software, there is room for inspection and testing by many experts, which is not the case for proprietary software. Without any laws to force commercial software developers to release their code for inspection, the only way they could be compelled to design and develop their software while prioritizing security requirements would be through secure-by-demand principles. While software users may demand that certain software standards be specified in contracts, there is no guarantee against errors that might later be discovered as zero-day vulnerabilities.
To cite one example, software could be developed with proper encryption capabilities to protect data confidentiality, but emerging quantum technology could render that encryption ineffective. There will always be new technologies, techniques, and approaches designed to undermine the positive outcomes that arise from following secure-by-design principles. To optimize the benefits of secure-by-design principles, it is necessary to understand their potential limitations and possible counteractions by malicious threat actors.
To optimize the benefits of secure-by-design principles, it is necessary to understand their potential limitations and possible counteractions by malicious threat actors.Secure by Design
Security by design exhorts software engineers and others involved in building IS architecture to think about security needs first and embed mechanisms to meet those needs in the architecture’s design and construction.4
The US White House’s Office of the National Cyber Director has been spearheading the principle of secure-by-design as a means to reduce software vulnerabilities.5 For proprietary software, the emphasis on security may be an inconvenience that interferes with the ultimate goal of generating revenue. With time-to-market constraints and no enforceable policy requirements to have software inspected, consumer demand for secure software would be the only avenue to force manufacturers to develop software using the secure-by-design principle.
Cyberrisk is business risk. Software manufacturers want to earn positive reputations by producing secure digital products with minimal security weaknesses. They could be motivated to build sustainable enterprise value by creating secure products that generate long-term profitability and a stellar reputation. Many of the digital products already in use likely were not developed using secure-by-design and secure-by-default principles, which means these principles are primarily being applied to future products.
Secure-by-design requires that manufacturers consider cyberthreats from the outset to enable mitigations through thoughtful design, development, architecture, and security measures. Its core value is to protect user privacy and data through designing, building, and delivering digital products and services with fewer vulnerabilities.6
Secure-by-design is futuristic, but it does not account for the legacy productivity software currently used by many organizations. Manufacturers can still improve that software with patches, but as history shows, applying those fixes is expensive for end users and can introduce new vulnerabilities. Thanks to the interconnectedness of computers that rely on so many software programs created before secure-by-design principles were established, the internet is rife with vulnerabilities that bad actors will continue to exploit. Furthermore, future products developed using secure-by-design principles will need to interface with legacy software. Since retiring legacy software is often impractical or impossible, there will be a mix of software created using secure-by-design principles and software dependent on security features added after deployment for the foreseeable future.
Secure by Redesign
Secure-by-design is proactive by nature: It incorporates security requirements before deployment. With legacy software, the challenge is to take corrective measures by addressing missing security features in software already in circulation. Most software manufacturers currently address software vulnerabilities by creating patches to address identified vulnerabilities. This approach treats security as an afterthought. However, in the case of legacy software that has already been deployed, software manufacturers hoping to overhaul their security may need to redesign such platforms (or retire them altogether if redesigning is both technically and economically prohibitive). If the redesign of a software platform is feasible but expensive, then software manufacturers could sacrifice resources and delay deployment of upgrades to ensure that future releases include robust security features.
For example, if a software system was designed without a proper means of authentication, a redesign of that platform could incorporate multifactor authentication (MFA) to address the previous design lapse. There must be an incentive for software manufacturers to continue assessing the deployed software’s performance in terms of security outcomes, however, even the secure-by-design approach may be overtaken by emerging technologies. There was a time when passwords worked—before bad actors started cracking passwords. Then there was a time when MFA was effective—until it was not.7 Secure-by-design principles should evolve along with rapid changes in technology.
Enhancing Legacy Software With Secure-by-Redesign Principles
Software manufacturers may proactively follow secure-by-default principles for new digital products, but legacy software should be reviewed for secure-by-redesign potential, as legacy software will interface with new software. Software manufacturers should be encouraged to review legacy software systems, identify areas that lack secure-by-design principles, and determine what a redesign of the same software program would entail in terms of cost and expertise to address the security gaps. Legacy software that is still in production but may not have robust security features should get serious redesign consideration, unless it is targeted for permanent retirement.
In a free market environment, it would be prudent to assume that a secure-by-demand approach may be more effective at compelling enterprises to adhere to secure-by-design principles than government mandates that would require manufacturers to follow prescribed software development principles. When it comes to critical infrastructure, it may be challenging to impose certain requirements, even if they are enforceable through some form of legislation.
With extensive knowledge of resilient security features, software manufacturers may need to contend with the feasibility and cost-effectiveness of redesigning new database applications, for example, with enhanced and more robust security features. If application functionality is not fundamentally changed with the redesign process, then firms could be required to divulge known security gaps of the existing application and disclose whether it is feasible to redesign it without drastically altering its productivity features.
“Software manufacturers should make available security logs to customers in the baseline version of the product,” the US Cybersecurity and Infrastructure Security Agency proposes. “For cloud service providers and software as a service (SaaS) providers, the software manufacturer should retain and make available to customers security logs for at least six months at no additional charge.”8
While it is not feasible to eliminate all vulnerabilities, it may be feasible for firms to make a concerted effort to identify most of the different classes of software defects to address before software is deployed to end users. Shifting the responsibility of software security to manufacturers through the secure-by-demand approach may force software manufacturers to address stakeholder needs with limited governmental mandates.
Overall, secure-by-design means cyber and operational resilience and improved profitability, as end users will confidently acquire software products with lower maintenance costs.The US Cybersecurity and Infrastructure Security Agency also proposes that “software manufacturers should treat the security of their third-party dependencies as an extension of their own security. To that end, software manufacturers should continually maintain provenance data of their dependencies, share this with their customers, and establish processes (such as through an open-source program office [OSPO]) to govern their use of, and contributions to, open-source software components.”9
The Way Forward
While the secure-by-design method is largely being considered for industrial control systems (ICSs), the interconnectedness of systems requires a comprehensive approach that addresses the collateral damage that arises from attackers gaining access to adjacent systems. There is a need to implement strong public/private sector partnerships to improve software security without impeding innovation.
To reduce the end users’ workload for addressing security during the systems operation phase, security decisions need to be made during engineering, and in a way that is traceable for third parties.10
Some major software manufacturers have begun to consider secure-by-design principles, but the question that remains is how all enterprises will be able to participate in the process. The US government, through the Cybersecurity and Infrastructure Security Agency, has been consistent in disseminating the concept of secure-by-design. Without mandatory requirements for enterprises to adopt the principles, organizations would have to conduct cost-benefit analyses to determine whether they could sustain their profits.
Researchers interviewed enterprises such as Microsoft and Google about secure-by-design principles.11 Microsoft pointed to its Security Development Lifecycle (SDL) as an example of a framework implementing security-by-design principles. One expert at Microsoft noted that customer demand plays a role. For example, in payment processing, security-by-design practices might be biased toward the Payment Card Industry Data Security Standard (PCI DSS).12
A concept that goes hand-in-hand with security by design is security by demand, which is when a software consumer demands to have software developers follow secure-by-design principles. In these cases, the consumer can only purchase software that was created using secure coding requirements that satisfy secure-by-design principles. This would compel software developers to focus on securing their software products before releasing them to the market. If large, influential software manufacturers choose to demonstrate to users that they are serious about adopting secure-by-demand principles, there is a chance that regulatory mandates may not be necessary to enforce them. Instead, market forces will compel software manufacturers to prioritize robust security features. If large enterprises adopt the secure-by-design approach and evangelize its advantages, that will allow market forces to demand products with strong security features with no additional costs to end users after deployment.
Overall, secure-by-design means cyber and operational resilience and improved profitability, as end users will confidently acquire software products with lower maintenance costs. The more enterprises understand secure-by-design principles, the better they will be able to articulate the need for software with robust and resilient security features.
Endnotes
1 The White House, “A Strategic Intent Statement for the Office of the National Cyber Director,” USA
2 Cybersecurity and Infrastructure Security Agency, Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem, USA
3 Lostri, E.; Sherman, J.; “‘Security by Design’ in Practice: Assessing Concepts, Definitions, and Approaches,” Lawfare, 19 August 2024,
4 Bygrave, L.; “Security by Design: Aspirations and Realities in a Regulatory Context,” Oslo Law Review, vol. 8, iss. 3, 24 May 2022
5 Cybersecurity and Infrastructure Security Agency, “Secure by Demand Guide”
6 Australian Government, “Choosing Secure and Verifiable Technologies,” 9 May 2024
7 Vakulov, A.; “How Hackers Bypass MFA, And What You Can Do About It,” Forbes, 6 September 2024
8 Cybersecurity and Infrastructure Security Agency, “Secure by Demand Guide”
9 Cybersecurity and Infrastructure Security Agency, “Secure by Demand Guide”
10 Fluchs, S.; Tastan, E.; et al.; “Traceable Security-by-Design Decisions for Cyber-Physical Systems (CPSs) by Means of Function-Based Diagrams and Security Libraries,” Sensors, 13 June 2023
11 Lostri, “‘Security by Design’ in Practice”
12 Lostri, “‘Security by Design’ in Practice”
ALLEN ARI DZIWA | CISA, CRISC, CCSP, CEH, CISSP
Is a cybersecurity specialist and subject matter expert (SME) for the Federal Reserve Bank of Cleveland (Ohio, USA). He has worked in technology and cybersecurity consulting for 17 years and currently serves on E-Council’s Global Ethical Hacking Advisory Board. He was awarded the Cybersecurity Exam Development Volunteer badge by ISC2. In recognition of his contributions to cybersecurity, he was admitted to the ISC2 Standards & Practice Unified Body of Knowledge Content Advisory Panel. He is a certified ethical hacker and certified threat intelligence analyst.
