Pete Lacey’s Weblog

A little clarity around my previous post of transport-level security and message-level security.

I’ll first note that neither security approach is bound to the REST or SOAP style of component interaction. There is nothing in REST that mandates transport-level security or precludes message-level security. The same is true of SOAP. That said, secure systems implemented via REST or SOAP today tend to leverage the transport-level security mechanisms inherent to HTTP/HTTPS, and a few SOAP systems leverage some subset of WS-Security. But lets take the terms “REST” and “SOAP” off the table, they’re immaterial here.

The point of the previous post was that transport-level security (TLS) and message-level security (MLS) (in their purest forms) are equally credible, and the existence of MLS does not suddenly make TLS worthless. Nor is MLS any more or less better suited to addressing the problems of phishing, identity theft, or trust than TLS is. I do contend that TLS, in the form of SSL/TLS, while not perfect, is mature and of continued value. I further contend that MLS, in the form of WSS, is also imperfect and comparatively immature — not bad, mind you, just young. MLS security provides value that TLS doesn’t, and I’m glad we have it, but the inverse is also true.

But the biggest point I need to make is that the concerns addressed by TLS and MLS are only a small subset of the total number of security concerns. Furthermore, the total universe of security threats, from organized crime and information warfare to shoulder surfing and lost laptops, is far larger than the total universe of available countermeasures, which in turn is larger than the authentication, authorization, encryption, and integrity solutions enabled by TLS and MLS. You cannot secure against every conceivable threat. Organizations have finite resources, and thus must apply threat mitigation under the rubric of risk analysis. When designing a new system, security considerations should be held paramount. A proper risk analysis in the context of the application’s function, design, and user-base must be performed, and it may indicate, for instance, that TLS or MLS or some aspects of both should be used (again, both techniques have value). But the application design must also account for a seemingly infinite number of other attack vectors (XSS, SQL injection, buffer overflows, etc.), and a proper risk analysis is the only means to determine how many resources to allocate to each conceivable threat. And, of course, security concerns extend beyond the application boundaries to securing the physical data, securing private keys, password management practices, network security, physical security, and on and on and on.

As an aside, I find the The eBankingSecurity PDF referenced in Tim’s Web Application Security post of only marginal value. It outlines the many ways that malicious code can steal user credentials or make an untrustworthy site look trustworthy. The fundamental premise is that if a client machine is compromised, then the game’s up. This is very true, but what to do about it? The paper doesn’t say. And therein lies the flaw, there’s no risk assessment or recommendations for how to proceed. It’s good that banks have their consciousness raised and are made aware that some of the security features they’ve come up with are not 100% effective. But what should they do? Fold up shop and go home?

And “the never-mentioned weakness of SSL” is anything but. It requires that the black hats rewrite your host file and install a trusted root certificate of their own making. This is not a weakness of SSL, it’s a weakness of any system that is based on trust, which, ultimately, they all are, including WSS and PGP. I fail to see how any TLS or MLS system can protect against this. I mean once your machine is 0wn3d, its 0wn3d. It’s up to the vendors of operating systems and browsers and security software to make it as difficult as possible for this to happen. But ultimately it’s up to the user to be educated enough to keep his or her machine secure.