If you need it, you have to do it yourself

iang posted his Hypothesis #5 Security Begins at the Application and Ends at the Mind. My favorite bits (emphasis added):

The application must do most of the work [1]. For really secure systems, only application security is worthwhile. That is simply because most applications are delivered into environments where they have little control or say over how the underlying system is set up.

...

If you need it, you have to do it yourself. This applies as much to retries and replay protection as to authentication and encryption; in a full secure system you will find yourself dealing with all these issues at the high layer eventually, anyway, so build them in from the start.

iang hits on they key point, at best the vendors and service providers ship you a box of legos, it is totally up to you to put them together in a rational way that meets your security goals. This is really a different way to approach security and to do that you need framework(s), here are two ways to think about it - enterprise level and service level.. 

The vendors have done a much better job shipping general purpose security lego blocks in the last 4-5 years. However there is still tons of room to shoot yourself in the foot. In the talk Brian Chess and I did at RSA last year, we talked about ways to misapply XML Encryption, XML Signature, WS-Security and others. We compared the web services security world to Saltzer & Schroeder's design principles. There were about 250 people in the room, at the beginning of the talk we asked for hands on who had read the Saltzer & Schroeder paper. One hand went up (a person who helped author the aforementioned specs). During the talk we showed a half dozen ways the standards had been misapplied to open up new security holes in the security mechanisms themselves(*), at each point the one person who had read the Saltzer & Schroeder paper would shoot his hand up and say "of course you would never do it that way." Except no one else had read the paper and the frameworks give you too much room for error and people make those same mistakes every day. So, yeah its up to you, you have to do it yourself. Best get busy diving into rabbit holes.

* for more info on web services and XML holes see Brad Hill's paper

Comments

[Brad]

This hypothesis of Ian's, and his other, "It's your job, do it." are mostly just restatements of yet another classic paper, by Saltzer (again!), Reed and Clark: "The End to End Argument in System Design".

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

[Brad]

Doh, should RTFA first. Of course, he refers to the paper directly.

Taken seriously, the end-to-end argument exposes some of the flawed use-cases and broken features built to accommodate them in WS-Security, the biggest of these being security architectures built around "intelligent" gateways and proxy appliances.

Like network firewalls, IPsec or WAFs, they may be useful in isolating, integrating or mitigating legacy apps that don't know how to do security, but are almost always worse than having applications take responsibility for their own security guarantees, end-to-end.

[Marinus van Aswegen]

In the brave new SOA world each endpoint (lego block) needs to take accountability for enforcing security controls. If you can compose a new application, what's stopping your adversary from doing the same?