Programmability in the Network: Risk-based Data Scrubbing

This post is brought to you by the letter “C” (for context).

There’s a whole lot of talking and proposing and presenting going on around risk-based . Usually it’s around authentication and access. The basic premise is that based on a score, formulated from a set of variables (context), you decide whether or not someone is allowed access to a resource. The formula is based on context and can include things like location, device, time of day, day of week, and application status.

Now, interestingly enough, one of the top 5 security challenges identified by respondents in our latest State of Application Delivery report was a very specific one regarding data leakage from mobile devices accessing apps in the cloud.

Really. It was that specific.

Now, generally speaking when we discuss location in the context of context we’re talking about user location; the location from which an app is being accessed. But there’s no reason that we couldn’t also include a bit to flip in a policy that included the location of the app. Because, programmability.

The reason this requires programmability is because there’s (generally speaking) no checkbox in a security policy that says “in the cloud” and even rarely “on a mobile device.” Sure, an app could ferret out the device by examining the HTTP header “User-Agent” but still you’d be left with “in the cloud”. If the app was only deployed in the cloud you could assume, but location-specific coding is a source of technical debt (as is the mobile specificity, for that matter) If the app ever leaves the cloud (and it’s been known to happen) you have to rewrite the app or, at a minimum, change whatever resource / configuration file you were reading that value from. Same thing if you decide to change the behavior with respect to device type (or need to expand it to  include new device types). 

Enter programmability.

What you want to do is basically write some code that executes in the network that says “if the user is on a mobile device and this app is in the cloud, scrub this data” where this is the sensitive data you’re afraid might leak out through the mobile device. Could be an account number, could be personal data, could be anything. Programmability lets you decide what is sensitive data and what you don’t want exposed – and when – without codifying it permanently in the apps.

Basically, if you determine that client device type “X” has a higher risk of exposing certain types of data you can simply scrub it out if and only if the client device type is “X”. Or perhaps it’s based on a combination of device type and location. Or on the time of day.

That’s kind of the point of programmability; it can enable you to model your app delivery policies (which includes security) after the corporate policies that minimize risk without maximizing complexity. It’s the basis for the contextual security that’s going to be necessary to adapt to the increasing sophistication of attacks and the growing diversity environments from which you have to deliver (and secure) applications and data.