Anyone who has taken one of my Web Services security classes has heard me talk about all the ways that potentially can be used to provide security services to a Web services application. I put together a checklist to enumerate many of the possible security architecture concerns.
One thing we do in every class is an on the fly threat modeling exercise that we use to come up with a draft set of countermeasures. Its one of my favorite exercises and the list of threats and countermeasures is different every time. The output is a set of countermeasures that can provide a starting point for building out a comprehensive Web services security architecture. I remember a few years back, John Wilander looked at the list (which was particularly large) and basically saying - "and no one will actually build all of that stuff into their system."
It was an excellent point and it remains a big challenge, the challenge of choice. One reason I use Threat Models at all is to fill the gap between the Thou Shalt and Thou Shalt Never in the security policy. The typical information security policy does not provide much that can be used for build security in activities. The countermeasures output from Threat Modeling are very actionable, but its not feasible to build every single one in. How do you choose?
Last week in a training class, a related question came up. Web Services security standards are great because you can implement them in so many ways. They are also horrible because you can implement them in so many ways. Let's take WS-Security, its a widely implemented standard for Web services security, included in Microsoft, IBM, Apache, Axis, Axis2, SPring and many other stacks. However, by itself, saying you are using WS-Security could mean a system with a high degree of assurance or something that's tissue paper-like. WS-Security supports passing messages with username and password in plaintext with no data encrypted; on the other side WS-Security supports X.509, Kerberos, SAML and other XML Signature routines, and full message encryption.
So saying a system uses WS-Security proves little about the design, its important to look in detail at the security properties and select from there. A basic strength scale should show the relative strengths of token type, the encryption routines, authentication, and communication channel
| WS-Security Property | Weakest | Stronger | Strongest |
| Token |
Username- password hash digest |
SAML, Kerberos, X.509 | |
| Authentication |
Username- password hash digest |
Signed tokens (above) Timestamp + Nonce |
|
| Message Encryption | None | Payload encryption | |
| Communication Channel | SSL |
TLS w/ Client + server mutual authN |
TLS w/ Client + server mutual authN, and integrity |
The above is illustrative and not a complete set, where the Weakest and Strongest start and end is implementation-specific, but these scales are very useful when navigating the myriad of tradeoffs inherent in building security in.
The weakest tokens are not signed or verifiable through digital signatures.
Authentication can be done weakly through username and password in the header or stronger through signed tokens with signed timestamps and nonce.
Message encryption can be turned on or off. As can message integrity (not shown above)
Communication channel can be as simple as one way SSL or made more robust with client and server side certificates.
Again, not a complete set, but these scales are helpful because there is almost always a lot of debate about each security property and how to implement and whether is needed at all based on business risk.
If you are a Service Provider its quite likely that you will need to support many different configurations based on what your consumers can support so this is helpful for tracking those as well.
Lastly, it gives the security architect something she reall needs - options. I have seen many times where a Service Provider says - "well this client cannot support Ws-Security standard (or whatever), so we just need to drop back and punt and use SSL." But the good and the bad of Web Services security is that there is almost always more than one way to do it, if they don't support WS-Security maybe they can support XML Sig or XMl Encryption or SAML and you can get similar properties into the design through those standards, so having a checklist of options and strengths can be incredibly useful to find ways to improve Web Services security.
If you are implementing new technology like Cloud or Mobile then you are providing and consuming Web services, its best to start with a plan to build security in to these apps. Its also a guarantee that you will have many choices to make on how to accomplish this so having a strength scale checklist for options, decision support and communications is quite useful in the field.
Comments