“The actual XML message is contained in the HTTP request and security is provided by HTTPS, which isthe secure version of HTTP. This, in a nutshell, is virtually everything that a Web service user or creator needs to know about REST.” -Dion Hinchcliffe
The goal of Threat Modeling is not to enumerate threats, but rather to identify and locate countermeasures. If we use the STRIDE threat model we have six threat categories that yield six or more security architecture concerns
Threat | Countermeasure |
Spoofing | Authentication |
Tampering | Integrity Hash |
Repudiation | Audit Logging |
Information Disclosure | Encryption |
Denial of Service | Availability |
Elevation of Privilege | Authorization, Hardened Interfaces |
The above mapping is not a complete set but is an opening position for thinking about designing and delivering Countermeasures to cope with Threats.
There is one additional area to consider and that is the Attack Surface, meaning the Data, Method and Channels that the attacker can use. If we combine the STRIDE threat model with Attack Surface we see six threat types that can target three different parts of the attack surface.
Threat | Countermeasure | Data | Method | Channel |
Spoofing | Authentication |
|
||
Tampering | Integrity Hash | |||
Repudiation | Audit Logging | |||
Information Disclosure | Encryption | |||
Denial of Service | Availability | |||
Elevation of Privilege | Authorization, Hardened Interfaces |
|
What does delivering these Countermeasures mean for Rest Web services?
Simplicity is a big part of REST's enduring appeal, sadly most security protocols are not simple, but SSL as Dion Hinchcliffe noted is widely deployed, so where does SSL help us as it relates to our Threat Model plus Attack Surface view?
Threat | Countermeasure | Data | Method | Channel |
Spoofing | Authentication |
|
||
Tampering | Integrity Hash | |||
Repudiation | Audit Logging | |||
Information Disclosure | Encryption | SSL | ||
Denial of Service | Availability | |||
Elevation of Privilege | Authorization, Hardened Interfaces |
|
We have 18 possible places to deal with Threats, SSL gives our Web Services and encrypted channel which helps deal with Information Disclosure threats on our HTTP wire. It does not offer any other Countermeasures. That means that a SSL-only REST Web Services has zero protection against Spoofing, Tampering, Repudiation, Denial of Service and Elevation of Privilege. Further, a SSL-only REST Web Service has no zero protection against Information Disclosure at the Data (message) or Application Method level.
This is the state of affair of most REST Web Services today, but you might ask "hey security guy enough of your threat talk - what countermeasures options are available? What can I do about this? And please, be RESTful."
There's quite a lot than you can consider doing actually
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 |
The above is not a complete list but it does give many ideas beyond plain vanilla SSL, many of the above options are standardized and so available at relatively low cost and complexity. Does not mean that all are appropriate in your instance or even that all 18 areas of the checklist be populated, but the above is a very useful decision support exercise to expand the range of defensive possibilities; and a tool you can use identify and locate cost effective countermeasures.
Comments