Identify yourself for MIM

by Brian Katz on August 28, 2012 · 0 comments

I had a great conversation on twitter today with Gunnar Peterson and Paul Madsen. It started from Gunnar’s great post (read it now) and the Venn Diagram that he created. Gunnar has hit the nail on the head in reference to stuff I have been talking about for a long time on this blog and in person. Essentially he has built a Venn Diagram based around 3 concepts, Mobile Security, API Security, and Enterprise Security. He was kind enough to place things like MDM (Mobile Device Management) and MAM (Mobile Application Management) in the diagram for us.

We may disagree slightly about MAM since I think it ties into Enterprise Security as well but I think in his case it pertains to how he has set this diagram focused around security. I would do the exact same diagram but remove the word security from it.

I sent Gunnar a note after reading his post where I posited that we could replace identity in the middle of his venn diagram with MIM (Mobile Information Management). MIM needs all of these pieces plus identity to work properly. MIM, as a reminder, is when you secure your enterprise data, and where policy actually follows the data. For a better understanding of MDM, MAM and MIM at 50,000 ft level see this post.

If we have built our system correctly, we have our data that’s sits in our enterprise data stores that we make available through the use of APIs. These APIs that will allow us to connect to the data, have to take identity into account. You use the API to access the data, but to insure that you only see the data you are allowed to; identity must be passed along with the information request. That identity is part of your enterprise identity system, usually based on existing IDs in Active Directory (or some other enterprise directory system).

The next step is building an app that accesses the API to the data. Your developers look at the API and figure out what data matches the requirements they were given to build that app. They map them out so they can request them from the API and at the same time they have to build identity into the request. They may choose to do straight authentication against your enterprise id system, could use a certificate to do the same thing, or go with a token provided through oauth or SAML.

In this description though, we are looking at MAM, not MIM. In these cases you have this built into each app, which is the definition for MAM. The issue with using MAM in this case is you now must find a way to link your apps if you want to share data between them. MIM, by definition, isn’t built separately for each app. MIM requires that each app is built with some standard API/SDK that treats data the same way.

So let’s take this a step further and define it for MIM. We build the API to access our data store but when we pull the data from it, we wrap it with identity. Policy and corresponding encryption. This can be it’s own separate wrapper or it can be through tagging the metadata, but the data that you requested now has defined permissions and policy which translates into who can use the data and what can be done with it. For example, the data may have a policy on it that says it can only be used in online mode; it cannot be cached for offline use. It may have a policy that restricts what email account it can be used with or whether or not a screenshot can be taken. All of these actions are dependent upon the user and their identity.

The advantage of MIM, is that data can now be passed from any one app on a device to another app on the device that can read the policy and follows the policy. Any app that does not respect the policy won’t be able to read the data in the first place (yes the data is encrypted). Remember the tenet, data is protected while at rest or in transit and regardless of the device or location. This last piece is quite important, it isn’t just whether it is a mobile device like a phone or tablet, the same rules now apply to a laptop or desktop. This means that data that ends up in a service like Dropbox doesn’t put the organization at risk as the data is being protected at rest.

None of this works without the identity that Gunnar has so readily identified in his diagram, which is why MIM also has a place in the center.

Previous post:

Next post: