Of Gateways and Hedgehogs

As I have shown a couple of times STRIDE Threat Models are a useful way to "see" your security architecture and communicate decisions. STRIDE Threat models can be improved by adding in the Attack Surface construct which further helps to refine the security architect's job of identifying and locating countermeasures.

Yesterday's post looked at using STRIDE+Attack Surface to analyze opportunities for improving REST security. As we can see there is a lot of territory to explore beyond "Firewalls + SSL" for Rest security architecture, and for that matter where REST is used in places like Mobile and Cloud applications.

Threat	Data	Method	Channel
Spoofing	SAML, XML Sig	SAML	TLS w/ mutual authN
Tampering	SAML, XML Sig		TLS w/ mutual authN
Repudiation	Audit logging	Audit logging	Audit logging
Information Disclosure	SAML, XML Encryption	Secure Coding	TLS w/ mutual authN
Denial of Service	Availability	Availability	Availability
Elevation of Privilege	SAML, XACML, oauth	SAML, XACML, oauth, Hardened Interface

STRIDE + Attack Surface combination is also helpful in analyzing Deployment security architecture. Let's take the case of Security Gateways. These tools can do many different things, as I described in the Security Gateway Buyer's Guide, and so using the STRIDE+ Attack Surface is a good starting point to identify what security services you would like the Gateway to be responsible for.

Let's start with Attack Surface, in a basic application deployment your Attack Surface could include

• Communication Channel: HTTP, TCP, JMS
• Method: URI namespace, Web services
• Data: XML, HTML, JSON, HTTP content 

Network security might be able to offer a limited amount of security policy control to the Communication channel, but Network security (like firewalls) have zero ability to help protect against or detect threats at the Method and Data levels.

Let's take a simple case where you want an ESB to aggregate some data from various back end resources and publish those out to remote clients, for example mobile apps.

If you front end the ESB (Or other aggregator) out to the Mobile clients, you are not simply publishing the data and Web services to the Mobile world, you are publishing you entire Enterprise Attack Surface as well. Think about what is exposed if the Gateway is not there to mediate.

So Gateways are quite important because they can play a role across the entire Attack Surface, including

• Communication channel: proxy network protocols
• Method: access control, publish only authorized methods
• Data: content validation, encryption, and integrity services

These are all over and above what is doable with network security, and against its a quick sketch not a comprehensive list. But its important for security architect to think about where and how they want to defend.

Gateways can be usefully deployed to deal with many threats in the STRIDE model

• Spoofing through authentication services that extend to from the communication channel to the method to the message data level
• Tampering for communications and message data
• Repudiation through logging communications, method requests and message data
• Information Disclosure through encryption services, and content validation and encoding
• Denial of Service through availability services
• Elevation of Privilege through providing hardened interfaces, content validation and encoding and authorization services

So the Deployment model drives a lot of the reality as to where and how security can defend. If you push all these defenses back into your app not only do you have the Attack Surface-bloat problem, you also have the issue of affecting performance and performing the security checks in the same space as that which you are trying to defend. In other words by the time you spot the attack it may already be checkmate.

Consider the Hedgehog opening that Black is playing

In WIkipedia's wonderful description "Although Black's position is cramped, it has great latent energy", notice Black's layers of defense around its position.

Strategy matters a lot, opening positions in security architecture determine what moves are available to you later in the game and how well protected your resources are.