Remember playing whac-a-mole as a kid? Even if you haven’t, you can picture it: every time you hit one mole down, another one pops up. It was fun when we were kids, but dealing with that kind of endless cycle in real life is not fun. Many organizations handle security this way – constantly scrambling to fix vulnerabilities as they surface and hoping to stay ahead. This patch and pray approach isn’t just exhausting; it’s ineffective and leaves systems exposed to ongoing risks.

This brings us to what I am calling Candy Coated Defence – an IT system that is hard on the outside, like candy with a tough shell, but soft and vulnerable on the inside.

Everything starts in the code, but we often don’t see weaknesses until they surface in the final product – whether it’s security appliances, software libraries, or services. By the time these flaws appear, fixing them becomes more costly, complex and risky. I remember one of my former colleagues had just heard Shakira’s song Hips Don’t Lie on the radio and said, “Hey, that song made me think about the code: the code doesn’t lie, it’s the source of truth.” That stuck with me because the code is always the source of truth. It reflects the reality of how secure (or insecure) the system really is. I know you have heard this a hundred time before, but there is truth to it – ignoring security until the end is like building a house on an unstable foundation. No matter how impressive the house looks, it’s bound to fail. Addressing security from the very beginning is not just a best practice, it’s essential.

Recently, I read about how numerous systems are still vulnerable to the Log4Shell exploit, which was an unwanted and early Christmas gift from November 2021. The vulnerability allowed attackers to execute arbitrary code on systems using the Log4j logging framework, making it extremely pervasive and dangerous. Despite patches being released shortly after its discovery, the ubiquitous use of Log4j in software means vulnerabilities keep surfacing in unexpected places. Two years later, Log4Shell has become like Clark Griswold’s Jelly of the Month Club – the gift that keeps on giving!

Many systems remain unpatched or continue to be affected indirectly through third-party dependencies. This is a classic example of Candy Coated Defence – the outside appears secure, but the interior remains vulnerable, just one initial exploit away from being compromised.  It’s a stark reminder that we need a better strategy. As an industry, we need move beyond reactive measures and embrace proactive principles like Secure by Design and Secure by Default principles, as emphasized by organizations like NIST and CISA.

Shifting Left: Building Security In
The concept of shifting left means integrating security earlier in the development process rather than bolting it on at the end. I recently heard a presenter at a Government of Canada security conference tell the audience that implementing DevSecOps is the answer to shifting left. While that sounds great in theory, I don’t think it’s entirely realistic in many government environments. Most departments are still operating in traditional Waterfall methodologies or have only recently migrated to Agile, and very few have fully adopted DevSecOps practices. We need a solution that works regardless of the development methodology in use.

The key is to focus on building security into every stage of development, whether you’re using Waterfall, Agile, or any other methodology. By addressing security from the outset, vulnerabilities can be caught before they become deeply rooted in the system. Security isn’t just the responsibility of the ‘security team’; it’s something that everyone must take part in. When all roles – developers, management, and beyond are engaged, security becomes a natural and integrated part of the workflow.

From Hardening Guides to Secure by Default
When I worked in the US securing national security systems, we relied heavily on Security Technical Implementation Guides (better known as: STIGs) to manually harden each system. While thorough, this process was arduous, cumbersome and prone to human error. Administrators had to go through every component and lock it down manually, which often led to inconsistencies.

In my opinion, one of the advantages of Secure by Default is it takes the opposite approach. For example, instead of requiring IT admins to enable firewalls, encryption, and access controls after setup, these features are already in place when the system is deployed. Much like candy that’s already hardened on the outside, Secure by Default ensures the system is ready to defend itself from the start, minimizing the risk of misconfiguration and reducing human error. You start with a secure configuration and can relax it if needed, which greatly reduces the risk of misconfiguration and saves time. This reverses the old method of starting open and trying to lock things down manually after installation.

Embracing Secure by Design
As stated above, Secure by Design ensures security is incorporated into every stage of product development, addressing risks before they become vulnerabilities. Instead of bolting on protection after the fact, security is integrated directly into the system’s core architecture, allowing for stronger resilience against emerging threats. This approach also reduces reliance on the reactive patch and pray strategy, especially for widely used components like Log4j, where vulnerabilities can have far-reaching impacts. By embedding security early, systems are better equipped to handle threats without constant intervention.

Here’s a look at some of the most critical vulnerabilities over the past decade that could have been prevented by applying Secure by Design and Secure by Default principles:

Vulnerability	Year	Consequence	How Prevention Would Help
Heartbleed	2014	Allowed attackers to steal sensitive data from servers using OpenSSL	Secure by Design would ensure better input validation and secure memory handling in OpenSSL, reducing the risk of this type of exploit.
WannaCry	2017	A ransomware attack that spread globally, affecting thousands of systems	Secure by Default configurations (like automatic patching) could have prevented the unpatched SMB vulnerability that led to the attack.
BlueKeep	2019	Allowed remote code execution on vulnerable Windows systems	Secure by Default would enforce tighter configurations on RDP to prevent remote code execution by default.
Log4Shell	2021	Enabled remote code execution on systems using the Log4j library	Secure by Design would have enforced stricter input validation in the Log4j library, while Secure by Default would ensure automatic updates to patch this vulnerability quickly.
Crowdstrike Falcon	2024	Out-of-bounds memory read and supply chain attack affecting SSH authentication in Linux systems	Secure by Design would catch the supply chain vulnerability early, while Secure by Default would implement robust system protections and input validation to prevent exploitation.

Marrying Secure by Design and Secure by Default

While Secure by Design ensures that security is embedded throughout the development lifecycle, Secure by Default guarantees that systems are configured with the most secure settings right out of the box. Together, these two principles create a powerful approach to security that not only prevents vulnerabilities from creeping in during development but also minimizes risk during deployment and operation.

For example, when a system is designed with security in mind from the start, it already anticipates potential threats, builds in protections, and follows secure coding practices. Once deployed, Secure by Default settings ensure that those protections are immediately active without requiring manual intervention. This dual strategy reduces the likelihood of misconfiguration, human error, or delays in applying critical security features.

In practice, the combination of Secure by Design and Secure by Default might look like this:

• During development: Security features like encryption, access controls, and vulnerability scanning are integrated into the code itself, ensuring that security is a core part of the system’s architecture. Regular security code reviews ensure that developers are not only writing secure code but also understanding and applying key security concepts throughout the development process. This helps build a culture where security is prioritized from the start.
• At deployment: The system is pre-configured with secure settings, such as strong authentication, disabled unnecessary services, and automatic updates. The need for manual hardening is minimized because security best practices are already in place. The team deploying the system is trained on how to configure security settings and can adjust them as required by enterprise security policies, ensuring proper configuration from day one.

This combined approach results in more resilient systems that are better equipped to handle threats both during and after development. By marrying Secure by Design and Secure by Default, organizations can reduce their reliance on reactive measures like patching and instead focus on maintaining a strong, secure foundation from the outset.

Too often, systems appear secure on the surface but remain vulnerable at their core, like being hard on the outside and soft on the inside. Traditional approaches that focus on exterior defences but neglect security at the foundational levels leave systems exposed to persistent and evolving threats. Marrying Secure by Design and Secure by Default addresses this directly by ensuring that security isn’t just an outer shell but woven into every layer of the system: from development through deployment.

By embracing both of these principles, organizations can move away from the patch-and-pray cycle, ensuring that systems are secure from the inside out. When security is embedded at every level, you no longer have to rely on an exterior defence that hides internal weaknesses.

The Candy Coated Defense approach is unsustainable, much like the endless game of whac-a-mole that never truly ends. The widespread issues with Log4j vulnerabilities serve as a wake-up call. By embracing Secure by Design and Secure by Default, and shifting left to integrate security early on, we can build systems that are robust from the inside out, saving ourselves time, effort, and the headache of constant firefighting.

We need to move beyond relying on strong exteriors that hide internal vulnerabilities. By embracing comprehensive security measures that protect every layer, and by recognizing that we’re all in this together, we can avoid signing up for the Jelly of the Month Club of vulnerabilities and ensure our systems are truly secure from the inside out.