Chapter 5: Defensible Architecture

One of the five defense approaches is defensible architecture. In this chapter, we'll discuss what defensible architecture is, how it has developed, and how it plays out in several environments. Specifically, this chapter will cover how to design and implement a defensible architecture.

The focus of this chapter is specifically on aspects of the defensible architecture that need to be supported but are often overlooked in reference architectures, such as resilience, survivability, and visibility. The secondary focus of this chapter is on how these characteristics can be designed in architecture.

This chapter will cover the following topics:

• The definition of defensible architecture
• Defense in depth
• The new security boundaries – identity and data
• Roots of trust
• Elements of defensible architecture
• Defensible architecture tradeoffs

We will start this chapter by discussing the definition of defensible architecture.

The definition of defensible architecture

Defensible architecture is about making the design of infrastructure and applications resilient under attack and offers the best opportunities for a successful defense when under attack.

The context of defensible architecture, in terms of the incident response cycle, which we discussed in Chapter 3, Engineering for Incident Response, and especially in Figure 3.1 is depicted in the following diagram. This diagram is based on an assessment of current threats and risks, coupled with an in-depth understanding of the business processes and culture. It's aimed at improving cyber defenses, and implementing new applications and infrastructure that have both prevention and detection components to keep out and engage cyber adversaries. Defensible architecture is in turn based on business context, knowledge about past attacks, and threat intelligence:

Figure 5.1 – The context of defensible architecture

This definition has a strategic and tactical component.

The strategic component focuses on the types of attacks and threats that the network must be able to successfully defend against. The types of attack that an organization may be subject to depend on its business and the environment it operates in. The success of its defense and recovery depend on its understanding of its own business context and the specifics of the attack. However, attacks will happen, regardless of whether an organization understands the threat landscape or not.

A Superior Way to Understand Your Threat Landscape

A superior way to understand the threat landscape is to use the techniques discussed in the first three chapters of this book and ensure that you capture the incident information of the incidents you have already experienced. Once this is in place, you can go further and consider using cyber threat intelligence.

In addition, the defensible architecture enables tactical options when you conduct cyber defense. These tactical options are based on how the network implements those defenses. The key components are visibility (or observability) of attacks, and credible options to contain and eradicate observed attacks.

Pareto optimizable attacks

In many cases, 80% of regularly occurring attacks originate from 20% of adversaries, especially where these adversaries are focused on the specific sector in which the business operates.

Note

As an example, the silent librarian group, or the Mabna institute, specifically focuses on tertiary institutions (such as universities) with a spear-phishing campaign targeted at obtaining accounts with access to intellectual property. Attacks from this group have been a regular occurrence since 2013. See https://www.justice.gov/usao-sdny/press-release/file/1045781/download for the indictment of this group, which also outlines some of their specific methods. These phishing emails were usually highly targeted and believable, and they still are a regular occurrence for cyber defenders in this sector.

This 20% can be described as the persistent attackers. The acronym APT, usually designating a state-sponsored attacker, is also used for some of these long duration groups. Understanding the preferred kill chain of these attackers and mapping them on the ATT&CK framework can pay significant dividends. In particular, it will allow us to design and implement early warning detections for these sort of attacks, making them easier to resolve.

In addition to APT groups, threat intelligence vendors now also classify a FIN group of attackers, which stand for cyber-criminal organizations with primarily financial motives.

Understanding the kill chain

To design defensible architectures, it is helpful to understand the kill chain of the attacker(s) to determine what elements must be implemented to disrupt specific attacks. In the remainder of this book, we will use kill-chain and ATT&CK tactics somewhat interchangeably. To design mitigations against specific tactics, two specific architecture practices are helpful: threat modeling and attack path modeling. These will be discussed toward the end of this chapter.

Note

Specifically, when designing an architecture, consider developing tactical playbooks to design the necessary defenses. A tactical playbook is the plan of action for dealing with a specific attacker and attack using the resources that are made available by the environment. Tactical playbooks are not about quickly buying expensive new technology to deal with the latest zero-day attack. We will talk more about tactical playbooks in Chapter 6, Active Defense.

The idea of kill chain-driven defense is that for each action taken by attackers, we can consider how such an action could be detected and mitigated. In what follows, we will base our discussion primarily on the set of tactics, techniques, and procedures (TTPs) that are collected in the ATT&CK framework.

The definition of tactics, techniques, and procedures in the language of the ATT&CK framework is very specific and it makes sense to define it here:

• Tactics: These are the technical objectives of an attacker. They correspond roughly to the steps in the kill chain, such as reconnaissance, persistence, and performing actions on objectives.
• Techniques: These are the specifics of how these objectives are achieved. As an example, an attacker may achieve persistence by adding registry run keys to ensure that their software restarts when the machine is restarted. This is one of the many ways to achieve persistence, so, in general, a tactic can have many techniques.
• Procedures: These are the specific implementation details of techniques on platforms or with a particular toolset.

The ATT&CK framework is easily available to everyone, is rapidly becoming the standard approach to understanding the details of cyberattacks, and is also loosely modeled on the kill chain, with the tactics in the ATT&CK model corresponding to the steps in the kill chain.

Detection

The intricacies of attack detection, apart from being a key element of incident response, is also a key element of the design of defensible networks. Defensible architecture must be capable of determining whether a network, application, or piece of infrastructure is under attack. In addition, forensic readiness, especially in the form of a collection approach, must be designed in the architecture. We will discuss collection approaches toward the end of this chapter.

Mitigations

In addition to the detective controls of visibility and detection, we must also consider prevention controls, which make certain adversary actions impossible on our network and hence prevent an attack from proceeding. Some of those prevention controls are architectural. As an example, firewalls will limit the ports as well as the traffic connectivity, and possibly (for a next-generation firewall) be capable of packet inspection and blocking specific packets based on content, which may stop some attack tooling from working correctly on our network.

In kill chain-based mitigations, a common pattern is to consider how adversarial activity may be detected, denied, disrupted, degraded, or deceived.

The idea of how this might work in practice can be considered by following the ATT&CK framework: for each of the tactics and techniques employed by an attacker, we can consider how our defenses might deal with this specific activity of the adversary in our networks in terms of detection, denial, disruption, degradation, or deception. For each technique and procedure, the ATT&CK model enumerates several mitigation options that a defender may employ to thwart that specific activity on their network. The entire collection of mitigations is collected on the mitigations page here: https://attack.mitre.org/mitigations/enterprise/.

The discussion in the section Branches and pivots: how incidents change, on defenses in the MITRE ATT&CK model, as discussed in Chapter 2, Incident Response – A Key Capability in Security Operations, is one example of how defenses may be designed with the kill chain in mind.

Designing defenses based on the pattern of attacks that you already know about may leave important gaps in the defenses. Hence it makes sense to consider a more comprehensive library of known tactics such as ATT&CK. The attack data that's collected in the ATT&CK framework defines a set of mitigations and controls that, when taken together, allow us to map out what we have defended against and what remains to be done in more detail.

Optimal defenses contain both prevention and resilience, as well as components that allow us to detect cyberattacks early. Let's discuss these requirements for defensible architecture in more detail.

Requirements of defensible architecture

At this point, we can define what the requirements are for defensible architecture. The defensible architecture ensures that adversary activity on a network are visible and survivable, and it also ensures that defenders have actionable options. It helps to reconsider the four objectives of incident response, as discussed in Chapter 1, How Security Operations Are Changing, and Chapter 2, Incident Response – A Key Capability in Security Operations.

Defensible architecture assists with these four objectives primarily through visibility, which assists with minimizing dwell time and understanding motivation and capability. Secondly, defensible architecture is based on measures that make it hard for attackers to perform lateral movement and achieve their objectives, a feature we will call survivability.

Finally, a defensible architecture must enable tactical options for the security team to actively thwart attackers. Tactical options consist of using and repurposing existing tools and capabilities on the network to disable adversaries and stop them before they achieve their objectives, or the introduction of new technical tools and capabilities..

Such tactical options need to be built into the network in advance and need to be designed by the architect. Tactical options can consist of the capability to disconnect endpoints immediately once a compromise is detected, or the ability to immediately deploy additional monitoring. In this sense, security teams need to be agile: able to react to intrusions quickly and fail safely.

This leads us to a set of requirements for defensible architecture. The defensible architecture enables the following:

• Visibility: To be able to detect adversarial events. Defensible architectures ensure a sufficient level of telemetry to determine whether an attack is in progress.
• Survivability: This is in terms of adversarial actions. Defensible architectures have components that enable the prevention of cyber intrusions, but we cannot rely entirely on prevention to stop cyberattacks from being successful.
• Resiliency and redundancy, which allow the development of tactical options. In general, this means that both the prevention and detection components do not depend on a single point of failure.

In the remainder of this chapter, we will define the specific elements and their configurations that make defensible architecture possible. Before proceeding, however, we will consider defense in depth.

Defense in depth

The traditional pattern for defensible architecture is defense in depth. The main idea of defense in depth is that the defense is not dependent on any single layer. In this sense, the defense in depth architecture differs from (and improves upon) the eggshell architecture, which is based on a hard outer shell and a soft inside.

The basic idea of defense in depth is sound, but there are also some drawbacks. The main problem with the defense in depth model is that it is ideal for an infrastructure that we don't see much of anymore: the on-premises data center. The main two drawbacks of the traditional defense in depth architecture are an implied trust in network segments and trust in endpoints.

Implied trust in network segments

The traditional defense in depth model is heavily dependent on firewalls to segment the network into separate network zones. While there is nothing wrong with a firewall as a preventive tool in defensible architecture, the problem with considering the firewall as the main line of defense is that it may lead to us placing implicit trust into these network segments.

Implicit trust is trust that is not based on an explicit root of trust. A root of trust is a specific architectural element that anchors the security posture of infrastructure and is increasingly verifiable.

Zero Trust Is Zero Implied Trust

In recent times, the concept of a zero-trust architecture has become quite popular. The idea of a zero-trust architecture is that no implicit trust is placed in network zones. So, in a zero-trust architecture, for instance, the trust in the office network may be the same as the trust in the public internet: none. Zero-trust architectures rely on verifiable trust in users, assets, and resources. See https://www.nist.gov/publications/zero-trust-architecture for more information. In the context of this chapter, zero-trust architectures may be characterized as zero implied trust.

Another risk with the defense in depth approach to security architecture is that defense in depth may become a security bolt-on to a network that has been optimized for ease of deployment.

In the past, it was often common to develop and test applications in flat networks without firewalls, to speed up the development and testing processes. Firewalls were then enabled before deployment, and a ruleset had to be designed at deploy time, with the risk that the ruleset being implemented was over-permissioned to make the application work.

While this model kept networks secure with varying degrees of success, as an example of defensible architecture, it is a failure, since it focuses on implementing security technology on what is possible from a process and technical point of view, rather than from the viewpoint of what is required regarding preventive and detective controls.

Trust in the endpoints of the architecture

Another drawback of the defense in depth model is that it tended to rely on system hardening as a preventive measure. System hardening involved a process in which systems and services were progressively disabled while observing the behavior of applications and services that are business critical.

System Hardening

For those old enough to remember it, the early versions of Windows, such as Windows 2000, enabled most services out of the box and had to be explicitly hardened. Fortunately, times have moved on.

Such hardening processes, in turn, enabled an enhanced level of trust in the endpoint, regardless of who was using it or what data was on it. The large risk with this approach to implied trust is that hardening configuration may drift or not take modern attacks into account.

Defense in depth as an evolution

Defense in depth should be seen as an evolution in the development of the defensible architecture that has been useful in many cases, but that, in the time of greater utilization of cloud infrastructures and operational technology, starts to outlive its usefulness.

That is not to say that the elements that defense in depth has required in its security designs, such as system hardening and firewalls, are useless and can now be discarded. They still are, and will remain, important components in passive defense and prevention.

The approach I'm advocating is that these elements retain their usefulness, but an inclusive view of the architecture, which also considers operations, verifiability of trust, and defensive tactical options as architectural elements, is considered. This is the core of defensive architecture.

If defense in depth represents an older stage in the development of enterprise security architecture that is now slowly becoming obsolete, what is about to replace it? We'll discuss this in the next section.

The new security boundaries

As we have seen, the big vulnerability of the defense in depth model is its reliance on implicit trust in segments of the network or endpoints. The defensible architecture leaves no room for such implicit trust, but instead requires the reasons for trust to be explicit and visible. From the viewpoint of agile security operations, a defensible architecture is composed of the following elements:

• Explicit and verifiable roots of trust
• Visibility infrastructure
• Intervention infrastructure

In addition to these elements, the architecture is based on robust principles that give design guidance in cases where complex technology decisions are required. We will discuss these principles first.

Principles of the defensible architecture

In this section, we will look at three key principles that are the essential ingredients of a modern security architecture. These principles focus on the centrality of identity, the visibility of events, and provable security properties. These principles are examples only, and in your own specific case it is possible that you will use a different set of principles.

Identity

As we will see later in this chapter, identity is a key root of trust. Hence, a principle that commits the organization to strong centralized identity and identity life cycle management is a must for a modern security architecture. A principle that captures the importance of identity might read as Identity is the primary access mechanism to data and code.

The reason identity is a central element in security architecture is that in modern infrastructure, security is all about being able to tie actions to people. Hence, having a centralized and well-managed identity infrastructure is a key element of security design. With a central identity infrastructure, you can avoid having to manage and monitor multiple identity stores and don't have to start an investigation by trying to tie multiple user names to a single person.

In addition to people's identities, however, we also need to consider the identities of services and the identities of machines. Infrastructure must include services and machines in the identity infrastructure.

On another note, identity events should be centrally logged and should be searchable with a free-form query. You never know what curve balls will be thrown to the security team during an incident in advance, and smart organizations do not assume the details of investigations before they occur.

Conscientious software

Conscientious software is software that implements telemetry (such as logging) and event monitoring and can maintain a defined security state by implementing robust authentication methods, API security, and code signing. A good conscientious software principle might read as follows:

Software is security-aware, has the right telemetry, and matures toward becoming self-regulating.

With the increasing adoption of the cloud, the execution, and data environment of many of our processes is moving from a network of known and controlled security properties to unknown networks and environments. An increasing number of applications will be consumed as cloud applications. Hence, we require that software that is deployed in the production environment or is a candidate for such a deployment can display either its current capability or has a documented roadmap toward cloud maturity regarding authentication, telemetry, component reuse, the adoption of APIs, and incident response capabilities that allow the security team to address incidents professionally or allow the security team to work together with the cloud vendor toward such a response.

Attestation

An attestation principle might be as follows:

Software and infrastructure can report on their security posture so that a decision can be made to distribute workloads and data to platforms that have the right security posture.

Attestation, using cryptographic verification of integrity and authenticity, should be a near-term requirement for all the architectural elements in a newly designed environment.

With the adoption of cloud, organizations are moving their trust anchors into a distributed environment and hence also moving to a distributed trust model. Attestation provides essential proof of trustworthiness and the means for conducting audits for target computing devices. That is, attestation allows a program or platform to authenticate itself.

Remote attestation is a means for a system to make reliable statements about the pre-launch and launch components in a distributed system. A remote party can then make authorization decisions based on that information. Attestation is an evolving concept and not technically available in the short term for most systems. The next section will be about the roots of trust and how the security properties of data are derived from the roots of trust.

Resilience

When it comes to monitoring, generally, many controls are better than a single control. A resilience of visibility principle might be as follows:

Many points of visibility are preferable over a single point of visibility.

This principle goes back to what we noted in Chapter 3, Engineering for Incident Response, in that many points of visibility are preferable over a single point of visibility, even if the detection quality of that single point is significantly better than each component of the many points of visibility. The detective capability of many tools working in parallel will quickly outrun any tool standing on its own.

Roots of trust

A root of trust is something that can serve to make us trust something else. More specifically, a root of trust is a set of functions that allow us to imply trust in something that is anchored to a root of trust.

Some roots of trust are verifiable, though most are not (although I'm expecting this will increasingly become the norm). The roots of trust we'll discuss in the following sections are identity, data, and algorithms.

Identity as a root of trust

We have already discussed identity as a central element in the principles driving the security architecture. In addition, identity functions as an important root of trust. Identity functions is a principle because information technology is about people doing things with data and algorithms. An important consequence of this is that we must be able to pin actions to persons.

Identity functions as a root of trust because we trust the person that the identity represents in the role they are functioning in. That may be as an employee, customer, or contractor. To get that right, we need to manage an identity life cycle.

Identity life cycle management is a key aspect of security operations and focuses on the life cycle of our users and the roles they play during that life cycle, as well as how they transition from one role to the next, and the permissions that need to be controlled as part of that transition. Someone may go from being a contractor in May to being an employee in September and being a customer in June. That is one identity in three different roles.

Authentication is a protocol that allows a user to prove to a system that they are who they say they are and how they authenticate to all systems. It is preferable to have a single sign-on system for all applications and maintain the smallest possible number of authentication stores.

There are several reasons for this. First, a smaller number of authentication stores makes it easier to maintain a consistent set of account policies across an organization. Secondly, it helps with detecting events: the use of authentication stores needs to be closely monitored by the security team.

Data controls as a root of trust

Data is not a root of trust itself. The trustiness of data relies on the degree to which data has the properties of confidentiality, integrity, and availability – properties that are usually maintained and proven by something other than the data itself.

The confidentiality, availability, and integrity properties of data are maintained by the following aspects:

• Encryption: To avoid inadvertent or malicious disclosure of data, we use encryption. Encryption can also be used as a tool to protect the integrity of data. The use of encryption as a control also leads to the need to store secrets (that is, keys) somewhere securely and control access to them.
• Secrets management. The design questions here are about key storage, access to keys and the use of encryption protocols. Secrets management is another root of trust that impacts the security properties of the data that is encrypted with these keys.
• Authorization: An authorization control checks whether a user has access to a resource.
• Configuration: A configuration control is not a data control but focuses on the device where the data is kept.
• Data loss prevention (DLP): DLP is a control that focuses on what users can do with data. Examples of DLP controls are limitations on sharing documents in the cloud, prohibitions on emailing documents that are watermarked as confidential, and more.
• Digital rights management (DRM): DRM focuses on who has access to documents and data once it leaves the organization. DRM usually relies on a combination of encryption and key management for sensitive documents and is usually hard to implement and operate.

After going through data controls as a root of trust, let's look at algorithmic integrity as a root of trust.

Algorithmic integrity as a root of trust

Algorithms are what transform data into other data. Increasingly, algorithmic integrity is becoming important as a factor in how we make decisions with big data and AI attacks. AI attacks are a new category of cyberattacks that focuses on subverting the AI algorithm itself.

Algorithmic integrity focuses on whether we can trust our algorithm to work as planned. For most algorithms, this can be verified as a matter of code integrity and functionality testing under varying scenarios. With AI attacks, risks to algorithmic integrity consist of the following:

• Bias: Bias can be introduced when and where an attacker influences or modifies the dataset that an algorithm is being trained on. Bias often occurs in AI on its own, when the creators of models do not take a sufficient variety of inputs into account.
• Input modification: AI algorithms, at a very abstract level, are black boxes that take inputs (data) and produce outputs (verdicts, decisions, and actions). Because of their black-box nature, it can be hard to relate inputs to outputs, and an attacker who can take control of an input stream can influence the output.
• Model poisoning: Model poisoning focuses on the learning stage of AI and aims to subvert the learning of the model to make it produce an output desired by the attacker.

The increased use of AI in applications driving business logic, real-life decision making, and event actions in the real world leads to the need to consider AI infrastructure as a specific element in our overall architecture, as well as the need to develop a risk-based framework that can assess and measure the amount of risk an organization takes on when deploying it.

Attacking AI

See https://www.belfercenter.org/publication/AttackingAI for a discussion of AI attacks and policy and architecture recommendations on the cyber defense of AI systems. ENISA has also done an initial report on the threat landscape that is confronting AI: https://www.enisa.europa.eu/publications/artificial-intelligence-cybersecurity-challenges.

At the time of writing, there are no widely adopted best practices regarding the security of the algorithmic integrity of AI, but a few recommendations can be made:

• Determine whether AI can be used in a process or whether the difficulty of protecting the AI infrastructure outweighs the benefit of using it.
• Determine whether there is enough data and data of a sufficient variety to train the system.
• Develop a threat model for the AI. For a discussion on threat modeling, see the Threat modeling section in this chapter.

In addition to using AI as a tool for business intelligence, it is also increasingly used as a tool in security monitoring. This brings challenges of its own.

AI as a security technology

The second consideration in security architecture is that AI systems are increasingly used as security devices and are subject to the same vulnerabilities mentioned previously.

Example – Attacks on AI-Driven Anti-Malware Solutions

The article Cylance, I kill you by Skylight Cyber outlines an attack on the AI-driven Cylance antivirus program by reverse-engineering the AI algorithm and then adding several magic strings to the algorithm that will allow malware to run. It is well worth a read to understand how these attacks differ from usual cyberattacks: https://skylightcyber.com/2019/07/18/cylance-i-kill-you/.

It is worth considering whether AI brings something radically new to the practice of security monitoring, or, as in the highlighted case, AI is merely used as an alternative way to express signatures, and hence is little more than signature-based security monitoring.

Roots of trust and verifiability

Roots of trust should also be able to be verified. That is, a mechanism must exist whereby we can know that a root of trust is trustworthy and can't be compromised by an attacker. There are two ways of doing this:

• The indirect method uses business processes, logging, and monitoring to verify that the root of trust is trustworthy.
• The direct method uses attestation, which we mentioned previously in the Principles of the defensible architecture section, to verify that the root of trust is trustworthy.

An example of an indirect method is code signing, which signs executing code with a certificate to certify that it has not been modified between the author of the code and the user of the code. This method is indirect because it transfers the verifiability of the code onto the verifiability of the certificate that was used to sign the code.

The Trusting Trust Attack

A brief paper by Ken Thompson from 1984, Reflections on Trusting Trust, makes an argument that you can't trust code that you didn't write yourself in its entirety. This includes the operating system and compiler. A practical example of this attack in operation was the XcodeGhost malware on IOS, which involved a malicious compiler for IOS applications: https://dl.acm.org/doi/10.1145/358198.358210.

Verifying trust can easily lead to an infinite regress of verifying verification mechanisms. In most practical cases, you must decide which level of verification is good enough to ensure the desired security level. The point is that this may differ for different environments and different systems. The next section deals with some infrastructure elements that are needed for visibility and intervention.

Elements of the defensible architecture

So far, we have discussed security boundaries, as part of the defense in depth discussion, principles, and roots of trust. The defensible architecture also contains several core elements that must be implemented and operated in agile security operations. These elements are a collection of preventive measures, visibility and forensic readiness, and threat-based defenses, which consider threat modeling and attack path modeling. These will be discussed in this section.

Prevention

We have already discussed the set of mitigations that map to the specific techniques and procedures in the ATT&CK matrix, which are collected on the mitigations page of the framework: https://attack.mitre.org/mitigations/enterprise/. Such prevention measures are still important components of the security of a system but cannot be relied upon entirely to keep a system secure.

The traditional preventive measures that most people are familiar with are static defenses such as firewalls, signature-based antivirus, and permissions on accounts and filesystems. These are still important configuration items that we must get right.

Increasingly, however, with the emergence of living off the land techniques, preventive security becomes dependent on how a system is operated. In the living off the land approach, attackers use the tools already available on the system to penetrate deeper into the network. The tools that our administrators use to manage the systems are usually permitted to bypass simple static defenses such as firewalls and are not detected by malware detection software. This is because they form part of the normal toolkit that is already present in the system.

Therefore, from an architecture perspective, it is more and more important that we do not only consider the static defenses that need to be put into a system but also consider the operating model: the description of who does what on a system and for what reason. This will ensure that the system tooling has the right access to the system.

In addition, the use of system tooling needs to be monitored and reported, which brings us to the second component of the defensible architecture: forensic readiness.

Visibility and forensic readiness

A key security property of a system is how well you can respond to incidents on it.

Collection approaches are rarely considered in security design. Instead, it is commonly assumed that an assortment of firewalls, antivirus, and logging will be able to take care of defensive needs, alongside a notion of defense in depth. This confuses the relative role of collection and detection and places too much implicit trust in network segments and endpoints, as was discussed before.

One of the key elements of defensible architecture is that it makes decisions about where defenses are put and to what extent they will be employed explicitly. When designing a visibility approach, defensible architecture considers the following:

• What to collect: Examples may include event logs, packet captures, specific files, account events such as logon/logoff, process start events, and privilege escalation. It is important to consider this to ensure that, during an incident, we have the correct data. An important pitfall here is that the logging policy on the system itself, which determines what events are logged to begin with, must also be set to the right level.
• Where to collect it: Sometimes, especially in the case of packet captures, we have a choice of where to collect them. Event logs are usually collected from endpoints but may involve a log collection server, where logs are temporarily stored and then forwarded to their destination.
• How to collect it: This focuses on the technology, such as network monitors, logs, and event collectors, and how to implement and configure them.
• Where to store the collected data: Finally, you must consider where and how to store the collected data. The best option is usually a NoSQL database so that data can be investigated with custom queries on the fly.

  Architecture Pattern – Uncouple Detection from Production

  It is usually a good idea to separate detection infrastructure from production infrastructure. This is because, during an attack, the ability to trust the detection infrastructure is of key importance. An additional reason is that detection and production infrastructure may have different availability and performance requirements. In addition to this, changes to detection infrastructure, which may be required frequently and with high agility, can be made without affecting production infrastructure.

We may not always have a good understanding of the risks and types of attacks that an organization may be facing. In that case, the organization needs a generic approach to collection that has a reasonable chance of determining whether an attack is taking place, but that is also not optimized against a specific attack.

An example of what to collect in a generic Windows environment can be found in the ACSC guidance on Windows event logging (https://www.cyber.gov.au/acsc/view-all-content/publications/windows-event-logging-and-forwarding).

Architects designing defensible architectures must explicitly consider visibility and detection in the architecture. If this is still vague, it can be made clearer once we consider threat modeling and attack path modeling.

Threat modeling

Threat modeling helps us understand the design aspects of how infrastructure and applications may be attacked, and what can be done to address the risks from attacks in a structured fashion.

Threat modeling is a structured approach to generating threats once the rough application architecture is known. As an example, if you design a house and have a sketch showing 
a front door and some windows, a threat modeling tool will be able to auto-generate several threats that are associated with having a front door and a couple of windows facing the street, and it will also be able to suggest mitigations (in this case, things such as ensuring that your door and windows are visible from the street).

Threat Modeling Tools

There are several automated threat modeling tools available to assist architects in developing a threat model and documenting it. One of the easiest to use is the Microsoft Threat Modeling tool, which can be downloaded here: https://aka.ms/threatmodelingtool. The documentation for this tool can be found at https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool.

The threat modeling process depends on what is classified as a threat. A common model of threats is the STRIDE model. Let's look at it in more detail:

• Spoofing: Pretending to be something or someone other than yourself.
• Tampering: This refers to modifying some data in transit, in storage, or in memory.
• Repudiation: This is the process of claiming that you didn't do something or weren't responsible. A repudiated transaction, for instance, is disputed by the originator, which happens, for instance, when you, as an individual, dispute a credit card transaction. Repudiation may be honest or malicious.
• Information Disclosure: This refers to breaching the confidentiality of data.
• Denial of Service: This refers to abusing or overusing resources, such as computing or network resources, that are needed to provide a service.
• Elevation of Privilege: This is a process whereby an attacker, sometimes spoofing a valid user, is allowed to do something they're not normally allowed to do. Examples include a user running code as admin, or a visitor on a website running code on a web server, often due to a configuration or programming error.

An alternative method of classifying threats is to use the library of Tactics, Techniques, and Procedures in a framework such as ATT&CK. ATT&CK also allows architects to design defenses against the techniques and procedures enumerated in the framework, but the result can't easily be captured in a consistent threat model or diagram. A compromise exists to some degree: it is possible to map the techniques and procedures that make up the ATT&CK matrix to the STRIDE model and in this way develop a threat model at a more abstract level.

The standard reference on threat modeling is: Threat Modelling; designing for security, Adam Shostack, Wiley, 2014.

The threat modeling process follows several steps:

• Diagram: This involves creating the data flow diagram of an application. A data flow diagram outlines how all the data flows from the user through running code into storage.
• Identify: The threat modeling tool provided by Microsoft uses the STRIDE model to automatically generate threats against the data flow diagram. The STRIDE model considers the elements in the data flow diagram and determines which elements of Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege (STRIDE) apply to that element and then proceeds to generate threats.
• Mitigate: This step details how the generated threats are evaluated, as well as an architectural decision on how they may be mitigated.
• Validate: In this step, the architect validates the mitigations.

Threat modeling is a robust way to ensure that threats are considered, but the automated and somewhat abstracted way in which the process works means that just running the threat modeling tool by itself will not guarantee a defensible architecture. Just as important as running the threat modeling tool is to discuss the generated threats, their applicability, and whether corner cases may have been missed. Threat modeling is best used as a starting point for discussion.

Attack path modeling

In addition to threat modeling, it is sometimes useful to model attack paths. An example of attack path modeling is using the BloodHound tool to map attack paths through Active Directory. Where threat modeling considers the threat to an application or limited piece of infrastructure, attack path modeling considers the compromises of an entire environment by using threat intelligence or detailed threat reports.

So far, we have discussed defensible architecture without referring to the specific environment in which it is supposed to operate. In the next section, we will consider some of the specific tradeoffs that are operating in the three specific environments; that is, on-premises infrastructure, the cloud, and operational technology.

Defensible architecture tradeoffs

As we have seen, defensible architecture is a collection of workflows, practices, strategies, and elements that form a defensible architecture. In this section, we will discuss some specifics of common environments and the tradeoffs that they involve.

On-premises infrastructure

An on-premises security architecture is still often defined by the defense in depth model and characterized by firewalls and implicit trust in network segments. The on-premises infrastructure of data centers are increasingly being migrated to the cloud, and one way to describe what the consequences of that migration are is to characterize it as a migration from an architecture of fear, focused on prevention, to an architecture of trust, focused on trust engineering and visibility.

Migrating to modern architecture is likely to involve the following discussions:

• Trust in endpoints, sometimes called a zero-trust model.
• The role and implementation of stronger defenses at the network layer, such as the IEEE 802.1X standard for wireless networks.
• Enabling office functionality, such as printing, telephony, guest and visitor networks, and presentation and meeting devices such as wall-mounted TVs.
• Internet of Things infrastructure such as intelligent lighting.

From the viewpoint of defensible architecture, the key questions about on-premises infrastructure concern the definition and implementation of roots of trust, combining the new security boundaries with the old ones, and how to best implement and maintain a monitoring environment.

Cloud

The cloud architecture is different from the on-premises architecture in almost all these respects and brings in a different set of security concerns and tradeoffs. If we can describe the traditional on-premises data center as an architecture of fear, then the cloud infrastructure becomes an architecture of trust. This is not to say that the cloud infrastructure is inherently better than the on-premises architecture, it is just to point out that the core question of the cloud architecture is one of trust engineering.

The core tradeoffs of the cloud all involve engineering trust:

• When we store data in the cloud, who controls the keys to its decryption?
• How are the identities in the cloud (people, services, and machines) managed and monitored?
• How does code progress from development into production and what are the key steps along the way?

When deploying systems into the cloud, all cloud vendors make good security guidance available to ensure that your architecture is defensible.

Industrial

Industrial networks are the bleeding edge of defensible architecture and are among the most difficult to secure and protect. The well-known Purdue Enterprise Reference Architecture (PERA) layers an industrial network into seven layers, again putting implicit trust in network segments that are derived from the presence of security controls at the border.

The main difference in industrial networks is that for the lower layers in the Purdue model, where we have sensors and individual process control, such implicit trust is a requirement, and not something that will be engineered away in any reasonable sort of timeframe. Industrial infrastructures have very long lifetimes, poor security practices at the device level, and impact real processes, in some cases with life-threatening consequences.

That is not to say that the principles of defensible architecture cannot be applied to industrial environments.

The key questions of defensible architecture, which are traceability and visibility, can be implemented in industrial networks, although they require a deep understanding of context. Industrial network protocols differ from the usual IT protocols in that they are used to transport data and settings to industrial devices and contain the values that measure and control industrial processes. Such data makes no sense without comprehending the basics of the industrial process that is being controlled.

Another key element of defensible architecture, threat modeling, and attack path modeling is that it's possible for someone who understands both the technology and the context in which it operates.

Industrial Playbooks

Industrial environments are usually heavily scrutinized for workplace safety, but traditionally, there has been less focus on cyber safety. Industrial environments require a specific set of playbooks, as outlined by Dale Peterson at https://dale-peterson.com/2021/05/11/3-incident-response-playbooks-for-ot/.

The discussion on defensible architecture for industrial networks is still ongoing and will be heavily impacted by an increase in high-profile incidents affecting critical infrastructure.

Summary

In this chapter, we have focused on the decisive aspects of defensible architecture, especially the new security properties of identity, data, code, roots of trust, some specific elements of the defensible architecture, and some implementation notes and tradeoffs for various environments.

We contrasted the traditional defense in depth model with the defensible architecture, which is based on explicit roots of trust, the visibility architecture, and the intervention infrastructure. Roots of trust are primarily based on the verifiability of the claims that have been made by them up to a level that, as designers, we consider is enough.

In the next chapter, we will focus on how to operate this architecture by implementing and executing tactical playbooks while considering active defense.