iPad mini wallpaper

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards #vdi

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards #iOS6maps

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards @klout

Posted via email from Pre(posterous)

New line of greeting cards ( @klout )

Posted via email from Pre(posterous)

New line of greeting cards #venn

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards #BYOD

Posted via email from Pre(posterous)

New line of greeting cards #BYOD

Posted via email from Pre(posterous)

All BYOD threats are NOT created equal

I hold this truth to be self-evident (but I'll argue it anyway).

You can classify threats to business data on mobile devices (whether BYOD or not) depending on whether

1. the employee initiates the process by which business data is put at risk 
2. there is malice involved in the above process, ie an active 'attack' against the data compared to inadvertent disclosure

Below is a taxonomy, with representative threats

I will contend that the measures that IT should consider to stop/control each of the above categories may be different (though there will certainly be overlap).

For instance, to mitigate the risk of a well-meaning but naive employee moving corporate data onto a cloud service provider to help themselves 'get things done', IT need not immediately start thinking about encryption, keys, and containers. Arguably simpler would be for the enterprise to

1. make sure employees are aware of corporate policy about such 3rd party applications or
2. prevent employee from installing the 3rd party native app (perhaps hard to reconcile with BYOD) or
3. actually subscribe to a cloud service storage provider (hopefully chosen based on discussions with the oh so demanding CoIT-aware employees), and so bring back this BYOC scenario into IT's domain of control. 

Similarly, while Lyle and Mary in the above may be both acting maliciously - it's clear that stopping Lyle is a different proposition (by removing him from AD, revoking any extant tokens, etc) than slowing down Mary (by turning off phone features like camera & screen shot, by making her data access dependent on roles, monitoring access and watching for patterns, etc).

You can also categorize the security protections IT might apply. At a really high-level, IT can

1. stop business data getting onto the device (e.g. by ensuring only authorized employees can access and download, or never serving up actual data but rather only pixels, etc)
2. once data is on device, prevent inappropriate viewing (by having a PIN on the device)
3. once data is on device, prevent inappropriate sharing (via encryption, disabling screen shot, etc)
4. once data is on device, prevent it from inappropriately leaving device (by preventing installation of 3rd party storage provider native apps)

These different types of protection guard against different categories of threats shown in the diagram. 

For instance, a PIN may not provide much protection against a determined and malicious attack (and not at all against Mary's dreams of sun) but it will surely help protect against the employee's daughter coming across sensitive product strategy during a chat session with her friend Brittany.

(High-level) Consideration for OAuth token lifetimes

When choosing lifetimes for OAuth access & refresh tokens, the following three considerations should/may/might factor in:

1. Application sensitivity (the risk of application data being compromised) - the more risk associated with an application, the shorter should be the token lifetimes (all else being equal)
2. Average application usage frequency (how much time passes between separate application sessions) - if an apps gets used only once a month, the appropriate refresh token lifetime will be different than for an app that gets used daily (all else being equal)
3. Average application  session duration (how long a user typically interacts with the native app) - if an app is used only briefly, the appropriate access token lifetime may be different than for an app that is used continuously all day (all else being equal)

If the above considerations are in conflict, risk is likely the more important consideration. In other words:

Tie goes to the (risk) runner 

Overly simplistic Claim #1 - a refresh token only serves a purpose if its lifetime is longer than the average time period between application usages

Apps that are used only infrequently therefore demand longer RT lifetimes - because otherwise the RT would have expired before it was ever used.

But this consideration is overridden by application sensitivity/risk

So, a taxonomy if you will

• Low sensitivity & infrequently used ---> Longish RT lifetime (both push lifetime up)
• Low sensitivity & frequently used    ---> Longish RT lifetime (opposing forces)
• High sensitivity & infrequently used ---> No RT (opposing forces, risk wins)
• High sensitivity & frequently used    ---> Shortish RT lifetime (both pull lifetime down)

Overly simplistic Claim #2 - an access token lifetime should not exceed the average length of time for an app's usage session.


But this consideration will also be overridden by application sensitivity/risk

So, another taxonomy

• Low sensitivity & short usage  ---> Shortish AT lifetime (opposing forces)
• Low sensitivity & long usage    ---> Longish AT lifetime (both push lifetime up)
• High sensitivity & short usage  ---> Shortish AT lifetime (both pull lifetime down)
• High sensitivity & long usage    ---> Shortish AT lifetime (opposing forces, risk wins)

Depending on where your application sits in the 3D array defined by sensitivity, session length, and usage frequency - the above might help you choose values for the access & refresh token lifetimes. 

For instance, for a low sensitivity app used infrequently for only short times , you could consider

1. short access token lifetime (because session length suggests so and risk doesnt overrule)
2. long refresh token lifetime (because frequency suggests so and risk doesnt overrule)

etc etc

MIM == (MKM) Mobile key Management?

In a great post on the relevance of identity to MIM (Managed Information Management), Brian Katz proposes a model for MIM that I believe looks roughly like

1. Native app obtains a security token (via combination of SAML & OAuth)
2. Native app uses that token on API calls (as per OAuth)
3. API validates token and determines user identity
4. API makes authorization decision about granting request (based on user roles & application type etc)
5. API attaches appropriate (enterprise-defined) MIM policy to returned data
6. Native app respects MIM policy

Brian writes

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

This sort of sharing has pretty serious implications for the crypto & key capabilities of the individual applications - and the architecture.

Consider two applications App1 and App2 on the device that need to share a given bit of enterprise data for some type of mashup.

When the API first releases the data & policy to App1, it can encrypt the data for App1 using the public key (ignoring the subtlety of how a symmetric key is used under the covers) associated with a private key that App1 can access. As App1 has the private key, it can decrypt the data and use it. Also, because presumably the call between the application and the API was protected by TLS, the application can be confident that the provided policy was valid and not interjected by an attacker - and so will respect its stipulations.

As Brian hilites, the data is protected both in transit (by combination of TLS & data encryption) and at rest (by the data encryption).

Subsequently sharing of the data between App1 & App2 introduces new twists.

if App1 hasnt changed the data then it could simply hand on to App2 the original encrypted data returned by the API. This of course presumes that App2 can decrypt it, implying that App2 must have access to the same private/secret key that App1 does. In this model, the ultimate guarantee of protection for 'data at rest' is the degree of protection for the private key(s), hidden away in whatever key store the OS provides.

if App1 has its own distinct key pair (as will surely be necessary if MIM is to support different apps having different data access rights), or if App1 changed the data after receiving it from the API (and it's a pretty poor mashup that doesnt expect this to happen) then the original encryption applied by the API is now useless - App1 needs itself to encrypt the data for App2. This implies that App1 is able to discover App2's public key, and know how to sign the data before sending it on. As did the API originally, App1 encrypts the data, attaches the MIM policy, and sends it over to App2.

But while the encryption applied by App1 ensures that App3 can't read the data - it does nothing to help App2 trust the MIM policy that accompanies the newly encrypted data. Unlike when App1 originally received the MIM policy directives over a TLS protected channel with the trusted API (and so could trust their origin & validity), App2 receives the new data+policy package from App1. So why should it trust & respect the policy? as far as App2 is concerned, App1 (or an attacker) could have modified the policy.

For App2 to trust (and be willing to respect) the MIM policy attached to the changed data - it needs to know that the policy came from the enterprise. The surest way to support this requirement is for the enterprise to digitally sign the policy (using its own private key). If a MIM policy statement is signed by a private key belonging to the enterprise, then App2 can use the corresponding public key to validate the signature, and so trust the policy. But, it's not enough for the enterprise to sign a policy statement in isolation. If so, an attacker could trivially switch a (valid) strict policy statement for a (valid) lax policy statement for nefarious purposes. It is the combination of data + policy that must be signed - only then will App2 know that

1. this policy came from the enterprise
2. the enterprise wants this policy applied to this data

But, even if the enterprise applied a signature to the original combination of data and policy that was returned to App1 - if the data was changed before being sent over to App2 - the original signature will no longer be valid.

Consequently, App1 needs to apply a new signature. But this requires that App2 trust App1.....

Thus the title of this post - MIM done with inter-app sharing as described above implies a complex key management architecture - MIM ultimately boils down to MKM.

The complexity of all of the above MKM (and the implications of inter-app trust) is what made me propose to Brian on Twitter that, instead, the apps do not directly share data but, rather all data flows to/fro the API - and it is with the AP that individual apps maintain their trust (and get data).

An admitted downside of this alternative model is that, while data can still remain protected at rest - no inter-app sharing is possible when not connected to the API, ie on a plane.

Redefining the application perimeter

For browser-based applications, it's easy to deal with those employees who 'have decided to pursue other career opportunities' - the enterprise either stops issuing SSO assertions to those applications or actively de-provisions that employee at the application providers (either on-prem or SaaS). For browser-based apps then, it's relatively easy for the enterprise to Turn Off Access (TOA) to the application.

If you were to draw a circle around the 'application', you'd draw it solely around the application server because that's where the data sits.

TOA to mobile native applications is more complicated - at least if the native applications have pulled data from the server and stored it locally. If you were to draw a line around the 'application' then you would need to include the corner of the device where that application stored its data.

For local-storage native applications, TOA requires the enterprise to

1. delete any data on the device
2. prevent the native application from downloading more data (via API calls)

The first requirement implies some MDM type functionality or agent on the device (equivalent to deleting the data would be delete the keys used to encrypt the data).

The second requirement can be met by either

1. deleting from the device the security tokens that the native application had been issued to authenticate its API calls (again implying MDM type functionality) or
2. leaving the OAuth tokens on the device but revoking/canceling them at the server (so they can no longer be used on API calls) or
3. ignore the tokens and deprovision the employee account at the application provider so that, even if the application presents a valid token on an API call, the authorization will fail

Given you need some level of MDM type functionality to remove any application data, it seems logical to depend on the same to delete the tokens, ie #1 above. But that presumes the tokens are available to the MDM agent. Perhaps this depends on where the tokens are stored, eg keyStore or not??

Simply revoking the OAuth tokens, as in #2), rather than worrying about deleting them from the device is attractive because the operation can be performed solely on the server and not the device. But revocation presumes either that a) the application providers will, on receiving an API call with a token attached, call back to the enterprise to validate that token (as necessary when the tokens are simply pointers and not self-contained objects) or b) the application supports some sort of 'revocation endpoint' at which the enterprise can actively push 'kill token' messages (for which there is currently no standard).

SCIM provides a protocol by which #3 can occur. But active de-provisioning does presume that the application provider supports SCIM (or a proprietary equivalent). Even if the tokens are deleted or revoked, the enterprise will likely want to deprovision the employee account if possible to ensure they don't continue to pay for it.

Local-storage native applications, whether used on BYOD or corporate owned devices, change the application perimeter, and so change the requirements for dealing with ex's. 

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)

New line of greeting cards

Posted via email from Pre(posterous)