The Case for Security by Design

The Root Cause of Breaches

In May 2023, attackers exploited a SQL injection vulnerability in MOVEIt – a widely used file transfer service. Organizations across the public and private sectors were impacted, with highly sensitive PII, including health information about newborn babies. The ongoing proliferation of software vulnerabilities like this has led to more people calling for a security by design approach.

At Security Compass, we strongly believe in security by design. Empowering teams to build secure software by design is our company’s mission. The costly legacy “find and fix” method for securing software is insufficient to make a material improvement in cybersecurity. Security by Design is not just about preventing threats; it’s about instilling confidence in every stakeholder, from the boardroom to the end user. We support software manufacturers to integrate security across the development process, right from the requirements stage, which in turn enables them to take ownership of security outcomes for their customers.

Benefits of Security by Design

Integrating security by design with the appropriate people, process, and technology is not only good for risk management – it bolsters the bottom line. With over a decade of experience in implementing our solutions, we’ve helped companies around the world achieve secure-by-design outcomes:

• A leading building supply company reduced cost and time to market for security requirements by 30%, and increased collaboration between security and development
• A large bank reduced risk, improved visibility and cut the time to assess risk by over 90%
• A Smart Home Products brand successfully embedded a Security Champion in every development team
• A global consultancy lowered their threat modeling process time from over 230 hours to 60 hours
• Several federal government organizations reduced their time for compliance activities from months to days

These outcomes ultimately yield faster time to market, more revenue and lower risk.

Navigating Regulatory Changes in Software Security

Governments and industry standards boards are taking notice. In 2023, the governments of the United States , Canada, Australia, United Kingdom, Germany, Netherlands, New Zealand, Czech Republic, Israel, Singapore, Korea, Norway, and Japan published guidance on security by design. An executive order in the United States mandates secure software practices for vendors who supply software to the federal government. OWASP introduced “insecure design” as a top 10 risk in 2021. States and federal governments are starting to write laws or bolster existing ones for Internet of Things vendors to incorporate security by design. Proposed legislation for hospitals in New York requires security by design practices. Moreover, some countries are considering shifting liability for breaches to software manufacturers with safe harbour provisions for those that incorporate security in the development process. Even if you ignore the business benefits, not incorporating auditable security by design practices is likely to leave any software or hardware manufacturer at risk for regulatory noncompliance and maybe even liability for breaches at customer sites.

Overcoming Common Challenges in Security by Design

While the business benefits and regulatory requirements are compelling, security by design is not a “plug and play” solution. Most people think of security as a quality that you test for: security vulnerabilities are scanned in code or discovered in a penetration test. The idea that you can prevent ever having a vulnerability takes a mindset shift. Over the years, we’ve seen a number of anti-patterns emerge from organizations who pursue security by design without putting in place the appropriate steps to adjust for the mindset shift.

• Inattention to change management: Because the business benefits of security by design seem obvious, many organizations rush into embracing new tools and techniques without considering the impact of changes to software, product and business teams. Fortunately, many organizations have already learned this lesson from other initiatives and have formed change management best practices. Classic techniques like stakeholder analysis, incentive alignment, early involvement of potential detractors, and communicating/learning from the results of pilots can prove effective.
• Moving too fast: One of the most challenging realities of embracing security by design is that it creates new work for teams. For example, development teams who embrace threat modeling and/or defining security requirements have more work to do up-front in the development process, which in turn takes away time from writing code in fixed-length development sprints. This is often at odds with product management/business goals of shipping more capabilities to users within the sprint. If a security team tries to inject 100 new security requirements for a development team to analyze and potentially action at the beginning of a two-week sprint, the effort will almost certainly fail because even reviewing the requirements will leave little time to complete features. Successful implementations often start with a crawl-walk-run approach: begin with work that requires a small investment in time, such as implementing a single, small security requirement. While this approach doesn’t materially improve risk posture right away, it helps build acceptance to the concept of security by design. As development teams become accustomed to taking on security work in planning, they can slowly increase the time investment and reduce more risk. Ideally, teams plan for proactive security work alongside other feature work on a regular basis.
• Begging the question: When organizations haven’t holistically embraced security by design, champions of the initiative often want to prove its benefits with a pilot or limited rollout. Without a mandate, they ask development teams to participate voluntarily. However, when faced with more immediate priorities such as feature work, development teams often drop voluntary work and do not perform tasks such as threat modeling or defining security requirements. The pilot fails to provide proof, and detractors point to the lack of traction as evidence that security by design doesn’t work. In our experience, voluntary efforts from individual developers to implement security by design rarely work. Instead, business and product stakeholders need to embrace the concept of security by design and allocate sufficient time to truly perform security by design activities.

The 3E Framework: A Rollout Strategy for Security by Design

If you are leading security by design at your organization, there’s a good chance you have faced or will face some of these anti-patterns. It can be frustrating to be up against a mountain of change resistance for an initiative that has such obvious business benefits. In periods of constrained budgets, starting an initiative that will require people, process and technology support is especially difficult. Fortunately, we’ve seen enough organizations succeed in rolling out security by design that we’ve identified a common pattern we call the 3E framework: Educate, Embed, Empower.

1. Educate: When it comes to security, ignorance is bliss. Development teams have a false sense of security because of clean penetration tests, or a broad cybersecurity compliance as SOC2 compliance. Training development teams on basic security awareness allows them to better understand the true breadth and complexity of creating secure systems. Successful security by design rollouts often start with this awareness as a precursor to processes that impact development processes, such as threat modeling. In parallel, champions begin the process of soliciting buy-in to security by design from executives by focusing on the business benefits of lower costs, reduced risk, and faster time to market.
2. Embed: For security by design processes and technology to work, they require people to champion them. Security champions are developers who have a strong interest and above-average knowledge of security. They are embedded within development teams and serve as the ideal owners for activities such as threat modeling and defining security requirements. Absent these champions, security by design initiatives often falter with lack of ownership.
3. Empower: Once development teams have been educated, executives have bought into the initiative and security champions are embedded in development teams, the groundwork has been laid for empowering development teams to rollout processes like threat modeling and security requirements. This is when organizations really begin to experience the business benefits and gain an advantage over competitors who are still stuck in costly “scan and fix” approaches to secure software.

Alongside these steps, successful rollouts often take into consideration:

• Metrics: Tracking KPIs and seeing progress over time helps to illustrate the business benefits. This often involves augmenting reactive metrics like defect density with proactive ones, like compliance against internal policy for security requirements.
• Budget: Any successful security by design program encompasses people, process and technology. Organizations need sufficient budget in all three in order to reap the significant business benefits.

Real-World Success Stories: Implementing Security by Design

One large manufacturer we worked with followed this strategy. They started with a large-scale roll-out of security awareness training for multiple roles across the development teams. They leveraged industry accreditation with ISC2 to embed security champions inside the development teams. They subsequently rolled out security requirements and threat modeling across teams and saw significant reductions in risk; penetration tests started to turn up a few findings in product teams that incorporated all of these steps.

The amount of change required isn’t always appealing to security and development teams who are strapped for time. Acknowledge this with your wider team and encourage empathy across functions as you balance speed to market with sharing the responsibility of designing and building secure applications. The alternative to security by design or the status quo, where customers deploy products with known, preventable vulnerabilities and expose themselves to being exploited in the wild and incurring even more damaging costs like loss of business and loss of customer trust.

Security by Design is not a luxury—it’s a necessity. As the CEO of Security Compass, I firmly believe that when we prioritize security from the start, we’re not just building software; we’re enabling a world where we can trust technology. Let’s shift the paradigm from security as an add-on to security as a default, ensuring that every customer inherently receives the secure products they deserve.

How Security Compass Can Guide You in Security by Design

If you build products with software, you can get started with security by design today. Start by assessing yourself on the 3E framework: are stakeholders educated? Have executives bought into security by design? Our role-based training can help you get started. If you’ve moved past education, have you embedded security expertise by forming champions? Our partnership with ISC2 to offer the Software Security Practitioner accreditation is a great way of validating security expertise for champions. If you are ready to empower development teams, SD Elements helps integrate threat modeling, security requirements, and compliance into the development process.

Contact Security Compass now to learn how SD Elements can help your organization achieve security by design, minimizing risks while maximizing efficiency and compliance.