Chess Analogy Redux

Chess is currently top-of-mind chez O'Neill due to my son teaching himself chess by playing gnuchess on xboard on a Puppy Linux box I put together based on an old PC abandoned on the street by a neighbor who skipped the state during the height of the foreclosure crisis. We now play with an actual wooden chess set and have books such as "How to beat your dad at chess" (which, as my son pointed out, was not supposed to be for me to read cover-to-cover, thus defeating the purpose). One thing we've been working on is the chess opening. As an infosec person, it's hard to do anything (take a flight, start a car) without thinking of the infosec analogies. And chess openings are no exception. But Gunnar Peterson is way ahead of me on the infosec/chess analogies...

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.
http://1raindrop.typepad.com/1_raindrop/2010/01/beyond-the-opening-a-priori-is-a-problem.html

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 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

http://1raindrop.typepad.com/1_raindrop/2011/01/of-gateways-and-hedgehogs.html

So where does chess fit into this?

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.