1 Raindrop

Mobile Security: Defending the New Corporate Perimeter

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
• Isolation/Separation
• Simplicity
• 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. 

Moscow Rules fixes the limitations of the DMZ model, the idea from the Cold war spy novels is a set of guidelines for agents operating in enemy territory. SInce you are behind enemy lines, you do not assume isolation like the DMZ does. In fact you assume opposite. 

 

The Moscow Rules operating principles are quite instructive for Mobile Application Security. Starting with:

 

"Play it by the book." If you are working with remote agents in hostile territory, you want to minimize room for error - to play it by the book, you need a book. More detailed the better - procedures, guidelines, and standards matter.

 

"Assume nothing" - is the client device rooted? Is it lost or stolen? What else is running locally? Did the developers implement correctly? There is a very long list of assumptions that people make about the efficacy of the DMZ that they cannot and will not be able to make about client operating ecosystems that mobile apps execute in. Turning towards software security architecture, the question to address then becomes as Brian Snow said - if we cannot trust, how can we safely use?

 

"Murphy's Law" - design for failure

 

"Everyone is potentially under opposition control" - its not just about delivering data to a client and protecting the server side. More to the point, systems have to be resilient in the face of intelligently patched and programmed client applications that can be turned back against the system. A common design pattern for services is to build the client using the emissary pattern - what software security designers need to cope with is hostile emissaries. Code, method, keys, channels, that the emissary has access to can and will be bent and turned back on the server, the system and its users. Your app is the attacker's IDE.

 

 

"You are never completely alone" - any time you work on a mobile development project you focus on your app, its natural. But your app lives alongside Angry Birds and many dozens of other app of unknown provenance. What happens to the identity tokens you gave to the mobile device? What else is listening to your IPC?

 

"Vary your pattern" - prepare for your app to be reversed. There's a major difference between one app being taken down and all the apps. Limit the damage to avoid cascade fail

 

 

"Never carry objects unless they be immediately discarded/destroyed" - web developers mostly needed to care about passwords, data, and session tokens. Mobile apps have a lot more than that. Plus they have a full execution lifecycle. For example, you are doing a sensitive operation on your app and a phone call comes in and suspends your app. What does your app do with the session and the data when it comes back up? How does your app manage and protect its cache, storage and memory?

 

So how should software security architects proceed using Moscow rules instead of just DMZ? I think the starting point is integration 

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

Rogue Trader's Long Walk

Wrote up my notes on John Gapper's excellent eBook "How to Be a Rogue Trader."  The FT has a sad story of the aftermath for one. Jerome Kerviel is walking from Rome to Paris before his jail sentence starts. 

It was after July 2007, when the financial crisis was starting to rout stock markets, that Kerviel’s initially modest gaming of the system started to get out of control. The economic situation was so bad, he thought, that the markets could only possibly go down from here, so why not bet big? He racked up a €28bn euro exposure in a few months, got the call right, and made the enormous sum of €1.4bn on his trading – although he declared only €55m as profit.

“At this point, no one was complaining,” he says. But hubris struck. At the start of 2008, he suddenly decided that the markets were set to rebound again, that the sell-off (which would last another year) was over. He built up a €50bn position, more than the value of the entire bank, this time betting stocks would rise. “I was confident, even though I was losing money, because I had always been right before,” he says.

In retrospect, he realises that at this point he had lost control. “It was just numbers on a screen. I was not even thinking in terms of money, just numbers of contracts . . . I had thousands, hundreds of thousands,

Giving that kind of leverage to a trader, to be able to build up positions bigger that the value  of the bank, wow. Its not hard to see why leverage played a leading role in 2008 crisis.