Here is a keynote talk I gave at the Cloud Idenity Summit - I gave the talk awhile back but these topics keep coming up and thought it would be good to share.
A good operating principle for any new technology is "eat what you kill", its been said that when it came out Apple's iPhone did not destroy competitors, it paved over whole segments - portable music players, GPS, PDAs, digital cameras, and more were all thriving multi billion dollar industry segments in their own right until they got subsumed into the iPhone.
If we take the position that identity is the new corporate perimeter, then what is it replacing and how should we proceed?
The perimeter was the DMZ. Good stuff inside the perimeter on the server and outside? Well all bets are off. Unfortunately, over time the quality of protection of the DMZ degraded.
I'd like to begin not by burying the DMZ but to praise it, and ask, what did it, in fact, get right? There is a good list of things the DMZ did well that we can learn from as our security architecture evolves:
- Attack Surface reduction
- Centralize policy enforcement and management
- Separate zone in terms of level of scrutiny
- Normal rules do not apply
The DMZ was a defined zone where in Marcus Ranum's words the normal rules did not apply. In addition, its the one area in the software architecture where things were deliberately taken away rather than added, that's a win for security.
However, while the DMZ gave us a structural perimeter, the boundary that really matter is around data access. The data and users long since diverged from the DMZ structure. That means in turn that our perimeter goes from a structural perimeter to a more behavioral perimeter. The authentication, session management, data protection and other security services have to adhere more to the user, the transactions, and the data. /home is where the data is.
As applications move to mobile how do we process a security architecture that means we are now delivering code, not just data as in the web model? How to account for co-resident malicious applications and lack of control below the stack at the platform level? The DMZ was never designed for these scenarios. I suggest a better model for today's clients is to play by Moscow Rules.
"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
Protocols should be designed and implemented looking at the whole access control chain and chain of responsibilities. Mobile apps, by themselves, cannot deliver a full solution, consequently the API and server side matters a lot. Applications may in fact be servers since Mobile middle tiers send push notifications, texts and other updates down to the "clients". In short we need to go back and fully refresh the playbook of security protocols not just extend and pretend mobile is just another client, a web browser with cooler hardware. Its a new way of interacting with users, servers and data, new protocols and initiations.
We cannot assume isolation, instead we need to plan for new types of interactions
At the same time, we have to make things simple for users and developers.
Our protocols live inside front end and back end containers. This means that integration is a first class citizen in security protocol design. We have both a First Mile Integration problem on the client side and a Last Mile Integration problem on the server side.
Many of the DMZ guidelines do still apply, attack surface should be reduced, simple, centralized policy enforcement points add value. Normal rules should not apply to perimeters.
Where the biggest distinction lies is the DMZ assumes a separation that no longer exists and that's where security integration patterns need to be worked and fielded to defend mobile apps, assuming not isolation and security but rather usage in actively hostile environments.