Last January, I quoted Gunnar Peterson used who a chess analogy for AAA, as part of a larger post:
I think of AAA access control technologies as Opening Game strategies - many people think of Kerberos and other ticketing systems are security, but really they just establish the initial ruleset for operations, the real game begins once they're in place, in use, and under attack. The structure used at the opening does not dictate all or maybe even most of the events that occur in the middle and end game.This made me think about AAA in particular, and how it breaks down into its component parts. So much effort is put into the first "A" of it, i.e. to authentication. But much less effort is put into the next steps. Authorization in particular is often murky. Even when you look at how people use Web Access Control products which do authorization, you often find that they are only being used for authentication and their single sign-on feature. I've referenced this chess analogy during 2010 in screencasts and webinars focusing on actual authorization products, including this screencast on Vordel's interop with Oracle Entitlements Server (Vordel as PEP and OES as PDP) and this webinar with Axiomatics. Authorization is "what happens after the opening" and deserves more attention than it's got in the past. The chess analogy is a good way to explain this, since it's not a case of "Make the opening then hope for the best". The opening is important, sure, but there is also the middle game and the endgame.
So, now, a year later and another nice chess analogy from Gunnar. He talks about where a Gateway fits in front of the ESB, saying:
"If you front end the ESB (Or other aggregator) out to the Mobile clients, you are not simply publishing the data and Web services to the Mobile world, you are publishing you entire Enterprise Attack Surface as well. Think about what is exposed if the Gateway is not there to mediate.So where does chess fit into this?
So Gateways are quite important because they can play a role across the entire Attack Surface, including
- Communication channel: proxy network protocols
- Method: access control, publish only authorized methods
- Data: content validation, encryption, and integrity services
If you push all these defenses back into your app not only do you have the Attack Surface-bloat problem, you also have the issue of affecting performance and performing the security checks in the same space as that which you are trying to defend. In other words by the time you spot the attack it may already be checkmate.i.e. if you don't have a Gateway in the architecture, then you're losing out on your well-defined opening, and it's the equivalent of jumping straight into the middle game without a clear opening strategy. This is another nice chess analogy which I'll be using in 2011 - thanks again Gunnar :-)
The usual caveats of infosec analogies apply, as well put by Chris Hoff here.