Friday, October 15, 2021

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

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...