Here is a recent interview I (Gunnar here) did with IBM Security strategist Diana Kelley on Mobile Wallet security. Diana covers what security issues wallet developers need to be aware of and the risk profile for mobile apps
Wednesday, June 18, 2014
Wednesday, May 28, 2014
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:
However, while the DMZ gave us a structural perimeter, the boundary that really matter is around data access. The data and users longs 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.
Protocols should be designed an implemented looking at the whole access control chain and chain of responsibilities. Mobile apps 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 cooler hardware. Its a new way of interacting with users, servers and data.
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.
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
However, while the DMZ gave us a structural perimeter, the boundary that really matter is around data access. The data and users longs 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.
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 - 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 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.
"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?
"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? 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
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.
Wednesday, February 5, 2014
Open Letter to Satya Nadella, Re: Mobile Identity
Dear Satya Nadella,
Congratulations on your new role. I am excited that the board picked not only a tech CEO, but a middleware guy. There's great, latent power in Microsoft technologies and if middleware people know one thing, its connecting stuff together to create value.
I was further heartened by the "mobile first, cloud first" mantra you laid out in your first speech. I know you are busy, but here is one opportunity to consider, and I am pretty confident that customers will appreciate some focus on this issue.
The Mobile app everyone is banging the drum for is Office on mobile devices like iOS. However, I think there's another one that unlocks some more interesting use cases. There is no Active Directory for Mobile, and that is creating problems across basically every enterprise.
So far the bog standard enterprise response to Mobile has been MDM, a useful but limited management technology. Despite the fact that MDM sells like hotcakes, it provides little value to app developers and does not address identity integration. Enterprises that want to solve identity end to end are left to cobble something together themselves from pieces and parts. Would be better to think more like Boeing assembling purpose built components, but instead Mobile Identity is more Sanford and Son.
The industry has collectively been waiting these last five years for an Active Directory for mobile to fill that gap. What if the Active Directory for Mobile was Active Directory? I don't think there are big technical blocking factors to the device management side, and the value on the server/cloud side is a massive integration opportunity waiting to be unlocked.
So what are some of the use cases that customers need help with?
Congratulations on your new role. I am excited that the board picked not only a tech CEO, but a middleware guy. There's great, latent power in Microsoft technologies and if middleware people know one thing, its connecting stuff together to create value.
I was further heartened by the "mobile first, cloud first" mantra you laid out in your first speech. I know you are busy, but here is one opportunity to consider, and I am pretty confident that customers will appreciate some focus on this issue.
The Mobile app everyone is banging the drum for is Office on mobile devices like iOS. However, I think there's another one that unlocks some more interesting use cases. There is no Active Directory for Mobile, and that is creating problems across basically every enterprise.
So far the bog standard enterprise response to Mobile has been MDM, a useful but limited management technology. Despite the fact that MDM sells like hotcakes, it provides little value to app developers and does not address identity integration. Enterprises that want to solve identity end to end are left to cobble something together themselves from pieces and parts. Would be better to think more like Boeing assembling purpose built components, but instead Mobile Identity is more Sanford and Son.
So what are some of the use cases that customers need help with?
- Mobile identity for users on devices, not just devices
- Local authentication, disconnected mode
- Portability - consistent identity and policy on the device and on the cloud
- Granular access control - not just all or nothing access
Enterprises trying to solve these problems today are using duct tape to solve important security and identity problems, they would benefit from identity systems engineered from an end to end perspective. Its a giant open problem and the incumbents do not have incentives, beyond selling more hardware and ads, to solve it. Would be a great help to enterprises if someone solves it, why not Microsoft?
Sincerely,
Gunnar Peterson
Subscribe to:
Posts (Atom)