Identity is a New Perimeter - So Where is the IDS?

 Access is mostly defined by identity policies than by infrastructure topology. This makes identity perimeter that requires as much security scrutiny as the classic DMZ style perimeters of the past. Implicit in this analysis is that protection can fail and must always be backstopped by detection and other mechanisms. 

Network security has delivered a large amount of network detection systems over the years to identify malice on the network perimeters, but where are the equivalent for identity systems? A lot of it is potentially there, but buried in audit and app logs and the like. But where is the timely and detailed information on malicious use of identity services to be found?

Identity protocols like SAML, OAuth, OIDC, and others have made it far simpler to stitch together disparate systems, and they're embedded pretty much everywhere. However, the identity protocols only solve (at best) the protection use case like authorization. They are silent on coping with malice meaning there is room for attackers to roam inside of the identity protocols. For example, OAuth 2.0 shipped with a 70 page long threat model. Kudos to the team for transparency, but where is the tool marketplace to detect the many dozens of threats it specifies?

Identity protocol design should not stop at protection, abuse and malice are inevitable and should be factored in to include monitoring for known identity layer threats:

- Brute force

- Token replay

- Token modification

- Redirection (numerous options inside the protocol dances)

- Authentication or Authorization Bypass

- Spoofing (client and server)

The list goes on, and the implicit separation in roles and responsibilities from the identity provider and service provider makes all of this a bit more difficult, but all the more reasons to seek out a malicious identity detection system to coordinate the Blue team on potential inbound attacks. 

There are some nascent efforts starting now in some identity products, which is good to see, but a lot more to do to reach the level of visibility that the ecosystem really needs. Since the identity protocols are the layer that stitches things together, that means they are also a prime spot for increasing blast radius and traversal ranges. 

On Behavioral Perimeters

Classical security designs rely heavily on structural perimeters with DMZs as the most famous example. In structural design it is the infrastructure doing the heavy lifting, providing a barrier between bad stuff on the outside and the good stuff on the inside. But connectivity, mobility, cloud, and other tech has chipped that world away to where structural perimeters are able to mitigate a tiny fraction of the threats in something like MITRE ATT&CK.

Structural perimeters do several things well. Let's take network DMZs as an example. DMZs excel at limiting attack surface, closing ports, for example, but the attack surface is never zero. So what then? 

Behavioral perimeters start with the assumption that some data is getting through. Behavioral perimeters  navigate and adhere to data flows add an important layer of countermeasures to increase the hardening, detection, and other security capabilities. 

Getting a bit more specific, think about the series of steps in a KillChain 

• Reconnaissance
• Weaponization 
• Delivery 
• Exploitation 
• Installation 
• Command and Control
• Actions on Objective 

Comparing structural and behavioral approaches in defending a Kill Chain above. Where is the DMZ adding value here? From an ingress perspective, a DMZ can limit most attack delivery vectors. From an egress perspective, a DMZ can also address certain Exploitation and C&C vectors. These can form a useful piece of the overall security foundation, but really most of the threats in a basic MITRE ATT&CK model assume this foundation as tablestakes and bypass them so there is much more required. 

A perimeter that focuses on the behaviors (both desired and not) of the system is what is required for security designers to go after the next classes of threats. What do phishing, Golden ticket/SAML,  Supply Chain compromise, and SSRF all have in common? They all assume a structural DMZ and then offer ways to bypass it. 

While Threat Models and catalogs like ATT&CK are a good shorthand way to illustrate the limits of DMZ designs, they do not show the range or depth of what is required to build a stronger blue team. What we lack is a defender model. Many years ago, I worked on a predecessor to ATT&CK that focused on Attack Patterns elegantly named CAPEC (http://capec.mitre.org). The goal of CAPEC was to start a consistent way to analyze attack vectors, but that was not the end goal. It was supposed to spawn the blue team toward defender models. It has been a long wait, but that is why it is great to see MITRE and NSA come out with D3FEND (https://d3fend.mitre.org), which depicts defense tactics like Hardening, Detection, Isolation, Deception, and Eviction. Notice that all of these defense capabilities are active behaviors, this much more closely matches the way the blue team game is played today - granular security capabilities based on deep understanding of data flows and system usage.

I am heartened to see that D3FEND takes a data flow centric view of defense, just in Detection it enumerates a whole range of sensor locations ( Message, File, Identifier, Process, User Behavior, Platform, Network, and so on). This type of thing represents a step forward for blue teamers and I hope it catches on as much as ATT&CK has.  

In terms of putting analytical tools like D3FEND to work there are a couple of things to plan for to make a real system. So in addition to the areas that D3FEND looks at, consider augmenting with the following:

Inventory- To coordinate the wide range of security capabilities across a decentralized and federated system that so many people defend today when there is not the Single Point of Control, defenders  benefit from Inventory systems. After all, there is an additional level of complexity when both the assets and controls sprawl. It is one thing to identify the dozens of places that D3FEND lists to monitor, it is very much another thing to weave them together in a coordinated way. 

Response/Recovery - Sounil Yu has made the case that Infosec is in the era of response/recovery, and that is another area that D3FEND spends a good deal more time on than many predecessors, breaking the "right side" of defense into three focus areas - isolation, deception, and eviction. As this continues to (hopefully) evolve, it will be interesting for blue teamers to coordinate detection services with the response/recovery trifecta.

Assurance - Just the complexity of the range of controls in the D3FEND map should cause at least some  to pause, but now imagine operating them across a scaled, distributed system. There's no replacement for assurance in this case. The design should include a range of tests that show both expected and unexpected behaviors.

Implicit in all of this is threat models. Building behavioral perimeters is essentially the set of countermeasures that emerge from your threat models. So it is important to keep these fresh and consistently upgrade them from many perspectives. 

The Understudied Importance of Integration in Security Design

 A critical question to ask about any security countermeasure is - "and then what happens?" This simple question is all too often not asked as security people get swept up in the complex daily algebra of threats and countermeasures. Mapping threats to countermeasures is foundational, but that is just the start. Asking "and then what happens" on each and every countermeasure illuminates many challenges and opportunities for security designers. Answering "and then what happens" leads directly to integration, which is an understudied subject in Infosec. 

The way that you choose to integrate your security services can change your system structure and behavior, and can increase or decrease your attack surface. Many times in both security academia and vendorland, integration is relegated to "implementation detail." But nothing could be further from the truth, it is not an accident that the NSA is fond of saying, "we don't break standards, we break implementations."

The list of problems that can arise is not short. What if a proxy or gateway is put in place to mitigate an application threat, but successfully traversing it applies an overprivileged identity to the backend calls? What if a device level sensor runs in elevated privilege and requires the use of a compiler onboard to update? The list goes on.  There are numerous cases where trying to solve on problem introduces more. When most security people think about security capabilities, they think about them in the context of scary threats or the protective/detective capabilities that may mitigate the threats. But equally, the should consider security capability options in the context of the system in which they will live.

Security design is filled with problems like the ongoing arms race between defenders and attackers. But problems arise for blue teamers just as often when they do their capability analysis in isolation. It is possible to match the right capability to the right threat, and still not get the expected outcome. The chief reason for this is integration. 

When you design access control, monitoring, encryption or other services, remember that they do not live in a vacuum, they are part of an overall ecosystem stack of functionality. Your security service is usually defending just one part of that and often blind to the rest. That is why it is critical for security pros to put just as much focus on integration as they do on access control, identity, monitoring, and encryption. 

So what does it mean to incorporate integration into security design? As with many elements in security design, it pays to begin with understanding your attack surface. First, break down the network, application, message, identity, and data assets that are exposed in your system. From there when you deploy security services think through which of the layers your security capability will adhere to at runtime. Make a logical and physical dependency graph. Where will it run? What resources does it need?  Note, that where your security services adheres to in the attack surface may very well be different from that which it is defending. A service that lives as a network node may be in fact defending identity, or an application service could be defending data and so on. So clearly separate what the service is defending against from where it will actually live in your stack. 

Integration occurs on many levels. Make a dependency graph of your planned deployment, and let the graph be your guide to deepening your understanding of how your system will change with added security capabilities. Two fundamental questions to understand- 1) are there better or worse options on how to deploy the security capability and 2) what new threats are introduced by this deployment?

An illustrative checklist of some questions to ask. The overall set of considerations is probably a lot longer, but here are a few to get started:

- Endpoint

What is the deployment profile on the endpoint? Machine based, identity based, container based, other?

What is required for this to boot? 

What identity does this run as? 

What is the source of identity?

What system is in charge of lifecycle management?

- Communication channels

What network protocols are in use?

How are communication channels encrypted? And what system manages encryption infra?

How are communication channels authenticated?

How does the system handle network DoS?

- Message data

What integrity services protects the messages sent over the wire?

What authenticates the message data?

- App

Does the service require CICD pipeline integration?

How does the app perform input validation and data sanitization?

- Administration

How will the system be administered? Where is admin access exposed?

Who will have access? What are the access levels? How is admin authentication handled?

How are administrative actions audited?

What protocols are in use for administration?

What is protecting the admin access (jump boxes, proxies, tunnels)?

How is system update handled?

The security design process generally begins with a threat model that leads to a set of one or more countermeasures.  That countermeasure selection step should be followed by deployment integration planning and subsequent threat modeling to better understand the new threats and range of options to choose from.

"We shall not cease from exploration

And the end of all our exploring 

Will be to arrive where we started 

And know the place for the first time. "

-T.S. Eliot