Secure by Design - What is It and How Do We Do It?

Security must be integrated into the heart of system design. The principle of "Secure by Design" advocates for embedding security measures from the inception of a product or system, rather than retrofitting it after development. This is a pretty abstract concept, but one that most of us agree is incredibly vital in protecting our nation’s and society’s interests. Safeguarding civilization as Dragos puts it in their mission statement.

Efforts such as CISA’s Secure by Design, Secure by Default, Department of Energy’s Cyber Informed Engineering (CIE), NIST System Security Engineering (SSE), ISA/IEC 62443-4-1 and many other initiatives provide insights into this topic. But with all this guidance, it can be confusing to understand what we are intending to accomplish and where the burden of responsibility lies. Even defining the scope of secure by design can be murky.

‍

Is security a feature? Is security a measure of quality? Is security a functional requirement? Yes. All of the above. But there are subtleties in these questions. What is security? Does it encompass Safety, Reliability and Productivity (SRP), clearly important characteristics within critical infrastructure, or are we just focused on the CIA triad of Confidentiality, Integrity and Availability? We have a bit of a definition problem, depending on who you ask. I’ve always been a fan of Dan Geer’s quote “Security is the absence of unmitigatable surprise" and when you get down to it, many of the suggestions in CIE speak to this concept, or what I have always referred to as “failing gracefully”.

Failing gracefully. What does that even mean? Really it comes down to ensuring that when failures occur, and they WILL occur, regardless of what your vendors tell you, that it is still a survivable event. It’s not going to end your company. You have redundancies in place, you have layered defenses, you have smart humans, and you probably have manual safeguards in place for when the automation fails. Break glass. And you can detect that failure too. Ultimately, it’s an all-hazards approach to ensuring survivability. This is not even information security or cyber security. This is business resilience, or business continuity at its core. And our secure by design initiatives are there to ensure that the mission can survive all adversity.

Do we need CIE to do secure by design? No, it’s one approach, and one I am a big fan of. I’ve seen articles comparing the two, as if you have to choose to do secure by design or CIE. Or approaches that seek to map controls frameworks to these concepts to simplify the conversation so it does not require a lot of thought, and you can just measure conformance with the requirements. The reality is a secure design in one system, is not secure, even for the same products, in another system with different critical functions and threat vectors. Security as a holistic concept, not taken in a vacuum. This is where threat modeling comes into play, because it introduces context and a view of the big picture. But before we get into that, I want to back up a step and look at this from the big picture.

Perspective

Who is doing design in your project? We all suffer from bias when we do work, based on our own objectives as well as the available information to make good decisions. I’ve written before about the differences here based on Product OEM vs Systems Integrator in Unraveling Security Engineering - Product vs Systems in Critical Infrastructure so I won’t belabor the point. The reality is that the Product OEM has a myopic view focused on their product only and a small set of user stories and can’t always accurately model risk. Often they are aligning to product certification requirements such as IEC/ISA 62443, which is a great set of standards, but its not a replacement for secure by design. Though we will touch on the SbD aspects of 62443-4-1 in a moment.

Secure by design cannot be prescriptive. This is at the core of the engineering discipline where requirements are defined and engineers need to determine how best to solve for them, through innovation and technical knowledge. You can include a set of standards as a requirement, but the standards drafting team has no clue what you are building years after they drafted the standard. How could they? It’s an unreasonable expectation. No, this requires context of the current need, and somebody who understands the problems and the usage scenarios needs to drive this effort. The standards set a strong baseline, but engineering needs to look beyond these controls and ask themselves what is really needed here. Sometimes that means more controls, sometimes it means less. Always with the alignment of other important stakeholders.

But probably more important than any of this, is just getting the language to do secure by design into your contracts. Integrators and other stakeholders do what the contract says, rarely more than that. So certainly telling our partners what we expect is a foundational step. I know some in industry are working on this very thing, what provisions are necessary? Having contributed language on SBOM and HBOM provisions in the past, I know this is not always easy territory to navigate, but if we do not start learning how to ask, nay demand, security by design - it's unlikely to occur.

Threat Modeling

What are we building and why is it important? That is really the starting point of threat modeling. It’s not about data flow diagrams and fancy software tools. Adam Shostack, a notable threat modeling expert has simplified the concept of threat modeling in a 4-step process as:

1.     What are you working on?

2.     What can go wrong?

3.     What should we do about it?

4.     Did we do a good job?

Now let’s contrast that with the CCE methodology which includes:

1.     Consequence Prioritization

2.     System of Systems Analysis

3.     Consequence-Based Targeting

4.     Mitigations and Protections

In step 1 – what are you working on, it’s about setting the stage for the entire process. It’s about setting scope boundaries for the process and understanding what is important. This starts the conversation, and in many ways begins to deconstruct the system similar to the CCE approach. One of the biggest differences being that CCE is focused on critical functions, not systems, but the systems analysis is just there because it’s a dependency of the critical function. The system is meaningless unless it does something important. It establishes context for why we should care.

In step 2 – we ask what could go wrong? While the order is a bit different and it occurs at a different level of abstraction, where threat modeling is focused on how the system or application could fail, CCE is asking from the very beginning, what consequences may never happen here? It’s been my experience that this is the most important question to ask in every single risk management activity inside the organization. It’s where we step outside our silo of technical security professionals and engage with the business. It’s where we start to have conversations with decision-makers who can resource our initiatives and help clear the organizational obstacles in our path. And it becomes our guiding light for the entire secure by design process. Every decision is about the functionality we need and the consequences we must avoid.

In step 3 – what should we do about it, we start formulating our plan. This is really the last phase of CCE where we begin formulating the protections to prevent the negative event. In CCE phase 3 is not about planning, but about using those consequence triggers to define a pathway for the attacker to cause a black swan event. It’s similar to threat modeling as we are defining targeting paths, but it’s closer to a red team exercise than it is an evaluation of standard threat modeling frameworks like STRIDE, STRIDE-LM, DREAD or PASTA. These are fantastic frameworks, and they might provide ideas for attackers, but CCE might be more likely to identify opportunities for cyber sabotage using the 5 D’s of Deny, Disrupt, Deceive, Delay and Destroy. We are focused on consequences here. Threat modeling objectives might align, such as use of tampering to produce a consequence, but it’s more focused on the techniques that need to be mitigated, not the damage itself.

In step 4 – we ask ourselves if we did a good job, which implies a continuous feedback loop, which is not something that CCE or CIE typically embrace, though the topic of security culture in CIE suggests that humans will continue to ask these questions. In a paper by Sarah Fluchs, she compares different secure engineering approaches, and indeed this was one of her criticisms of CCE, that it tends to be a point in time and not a continuous activity. The triggers for assessment are important. And the decisions we make are continuous.

Security Design Decisions

Everything we just discussed was about making decisions based on the available information. At the core of Secure by Design is this concept of design decisions. Sarah has written exhaustively about this topic at the IDEAS project, which you can read more about. But in order to make good decisions we need context. And we need a methodology for good decision-making. This is where CIE comes in. While CCE is a simplified methodology that implements the vision of CIE, CIE itself tends to be more about the thought process itself.

I’ve written about CIE before, and also maintain the CIE wiki so won’t go too deeply here, but its really about asking questions that force you to establish whether you are making good design decisions and embracing the concepts culturally. Culture aspects are also called out by CISA in their Secure by Design paper that advocates for:

• Take ownership of customer security outcomes
• Embrace radical transparency and accountability
• Lead from the top

These establish a strong cultural basis for fostering secure by design thinking, but then we tend to get back into very specific controls that must be implemented such as use of memory safe languages, which is a fantastic way to reduce vulnerability risk, but it’s really just another compliance requirement.

A similar approach is seen in IEC 62443-4-1 which is focused on establishing a maturity level for the product supplier as it relates to secure product development lifecycles. But the questions asked are a bit different.

In 62443, the section of secure by design comes down to establishing a defense in depth strategy and validation throughout the engineering design process. But the actual section is mostly focused on the security posture of external interfaces for the product in question. The questions posed are excellent, including such concerns as input validation and supply chain security validation. But by and large this is still a traditional threat modeling exercise focused on trust zoning. It also assumes the types of negative cybersecurity events that will occur, which also limits the creativity of assessors seeking to validate SbD has been performed.

It goes on to describe the defense in depth approach shown below, and also secure design validation processes as well as a set of documented best practices. Many of these are fantastic high-level objectives such as secure design patterns, least privilege, and design simplicity, a clear intersection with CIE principles for design simplicity. But what are secure design patterns?

We do start to see some of these recommendations such as use of memory safe languages or removing administrative interfaces from the internet in the form of CISA SbD advisories and white papers. But this guidance is still piecemeal and not centrally managed in any type of repository that one could ingest into their process beyond sporadic guidance and the explicitly referenced practices in 62443-4-1 or component level requirements in 62443-4-2.

But the focus here is not on the thought process itself, beyond the fact that we need to perform threat modeling, which is really what is being described in 7.4.1.

Final Thoughts

As I’ve alluded to above, Secure by Design is not a product we buy, but the decisions we make and the thought process and methodology applied when making these decisions. And ultimately tracing these decisions to the downstream outcomes, good or bad.

We have a long way to go before we can distill this down to measurable outcomes, which is why people keep gravitating back to compliance. It does not require thought and it's simple to measure. But its burdensome and frankly wasteful at times. I’d be interested in your thoughts on how to measure this. For instance, do we ask the 12 core questions from CIE (below) and determine if they were part of the overall design? Or is the guidance in the CIE Implementation Guide scratching your itch? Or are you doing something else entirely?

• How do I understand what critical functions my system must ensure and the undesired consequences it must prevent?
• How do I select and implement controls to reduce avenues for attack or the damage which could result?
• How do I prevent undesired manipulation of important data?
• How do I determine what features of my system are not absolutely necessary to achieve the critical functions?
• How do I create the best compilation of system defenses?
• How do I proactively prepare to defend my system from any threat?
• How do I understand where my system can impact others or be impacted by others?
• How do I understand where digital assets are used, what functions they are capable of, and what our assumptions are about how they work?
• How do I ensure my providers deliver the security we need?
• How do I turn “what ifs” into “even ifs”?
• How do I manage knowledge about my system? How do I keep it out of the wrong hands?
• How do I ensure that everyone’s behaviors and decisions align with our security goals?