The DMZ is a Web app security architecture workhorse. The DMZ operates under a different ruleset both in terms of what is allowed and in terms of the level scrutiny design, deployment and operations get. To the extent Web security works at all, its due in no small part to the isolation the DMZ provides.

The DMZ concept has lived on in the Web services world primarily through Web services gateways which limit Web Services attack surface, help developers navigate byzantine security protocols, and facilitates inbound and outbound app monitoring.

Here we are in the first or second inning of Mobile apps, will the DMZ still play a role? I think the answer is a resounding yes. The DMZ will continue to serve an important role but the nature of the role and the capabilities will adapt for Mobile apps. I think the DMZ still plays a role and is supported by the Web Service Gateway, but in addition expect to see increased deployments of API Security & Management layers to handle some front facing tasks

For Mobile Secuirty architetcure I expect each layer in the DMZ to handle similar responsbilities as they have to this point but to take on additional responsibilties with a mobile flavor.

Identity is the new perimeter, and so Identity and Access Management is a core problem at the DMZ. There is a clear need to support different token types and different protocols for mobile apps. OAuth and OpenID Connect are two of the most important here, but importantly its not just session cookies, the type ot identity token and protocol will change and so will how they are used. The session length is longer and there are local client based access control decisions to be made. The Mobile DMZ must have a way to enforce security policy for apps and data over asynchronous protocols.

In addition the access control protocol is often not just a client –> server, the security architect must account for the app developer who gets access via an API. The Mobile DMZ must have a way to issue, validate and refresh developer keys.

The Mobile DMZ serves an important function in providing defensive service, limiting what the app has access to and monitoring that access.Two additonal responsbilities include dealing with Lost/Stolen aka Remote Wipe. Many enterprises look to MDM here and that plays a role but does not help much on consumer facing applications. Client side data is often encrypted and here the Mobile DMZ is very likely involved to provision keys.

The DMZ is really about managing enterprise risk – publishing some data and functionality, while limiting the downside. This delicate balance is a result of the tension of push by development organzations and security’s job to ensure prudent measures are taken to manage the risks. API Curation is an important step ring fencing the scope of the enterprise mobile interface.

To support these activities new organizational roles must be fostered including the Service Admin and API Developer role. The Service admin readies the backend enterprise services to be published. The API Developer builds content on top of them. In addition security architects and app developers must factor in how to collaborate with these folks to ensure a clear chain of responsibility – who does what. For example, the Service Admin can instrument policies for security, measurement and monitoring, but the API developer is responsible to develop the front end. Understanding what is published and how to safely use the services is key.

So I think the DMZ is here to stay, I expect the some changes, some structural, some subtle. The structural change is the decoupling of the front facing part of the DMZ to API Security and management systems with the back end enterprise gateway served up by Service Gateways. Its still early days in mobile in general and mobile secuirty in particular but I think this shift already under way.

The post What Comprises a Mobile DMZ? appeared first on Application Security.