Multiple Perspectives on Security

Security Journal

Subscribe to Security Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Security Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Security Journal Authors: Elizabeth White, Yeshim Deniz, Pat Romanski, Maria C. Horton, Liz McMillan

Related Topics: Security Journal, Network Virtualization, DevOps Journal

Blog Feed Post

Programmability in the Network: Risk-based Data Scrubbing By @LMacVittie | @DevOpsSummit #DevOps

There’s a whole lot of talking and proposing and presenting going on around risk-based

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

basic comms exchange

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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.