A recent conversation on sc-l reminded me of one of my favorite design quotes:
"Normally, everything is split up and problems are solved separately. That makes individual problems easy to solve, but the connections between the problems become very complicated, and something simple ends up in a real mess. If you integrate it in the first place, that turns out to be the most simple solution. You have to think ahead and you must always expect the unexpected."
- Jan Benthem, Schipol airport chief architect
Anyone who has flown through Schipol as opposed to, say, Heathrow can relate to this idea's efficacy.
So where this applies to security is that as so elegantly stated in Blakley and Heath's Security Design Patterns, security protocols often don't compose, yet applications are built on composition. The reality is the developers need more training on software security, for sure, but we also need much more focus on integration, otherwise our security protocols and mechanisms will solve irrelevant and/or trivial problems - a pseudo-security that breaks things up into small pieces and "solves" one easy problem ignoring a morass of real tricky problems that burn our users, compromise our data.
For example, the idea that firewalls separate good stuff and bad stuff with an autonomous DMZ in the middle "solves" the lets keep the bad guys out of our system supposedly. Except firewalls are a permittance architecture not a denial architecture you wouldn't have a DMZ at all except you are going to let people in. Other examples, SSL "solves" the communication confidentiality point to point and ignores the rest. Kerberos is a point to point protocol that gives tickets for a domain.
Now there are several ways to achieve better integration, but unless you think through the tradeoffs early on of say whether a federated, proxy or sts approach is better, it will be too late to implement.
We need more architects.
Posted by: Iang | March 23, 2009 at 11:51 AM