ABAC not RBAC: Welcome to the (IoT) World of Contextual Security

There are many more attributes that can be gleaned from a seemingly simple application request than may at first meet the eye. There is, of course, IP address. From which can be determined one’s location. That’s geolocation and it’s fairly standard practice today to grab that piece of data. But from that one can also infer some other attributes, such as “inside a corporate property”. One can also use a bit more advanced data mining and determine whether the location is or is not typical for the user trying to access the application.

And that’s just from an IP address. The operating system and device parameters are easily obtainable by examining headers in the HTTP request sent to access the application. When it’s a web browser, even more specific fingerprinting can be accomplished and, subsequently, compared against previous communications to determine whether or not “Jim” is actually the same “Jim” you’ve allowed access in the past.

All this information; the variables extracted and inferred, make up what the application delivery controller (ADC) industry has called “context” for many years now. That context is what informs security decisions, enables innovation in delivery, and assists with applying acceleration techniques that improve the application experience.

So it was not surprising to read this article declaring the death of RBAC and the introduction of ABAC (Attribute Based Access Control).  It’s based on context, just described with a much cooler acronym that rolls off the tongue a bit better (and sounds like something far more formal).  The focus of the article (go ahead and read it, I’ll be here when you get back…. ) is really on eliminating role as a primary means of authorization and replacement with attributes and speaks to more an internal or business-to-business access control mechanism, but the concept is one that’s broadly applicable. It’s used extensively in anti-fraud solutions, for example, across the banking and financial industries. You’ve probably interacted with one in the past when you log in to do some banking or check your stocks and during the process the app proceeds to annoy you with one of your security questions – because you’re logging in from a location that isn’t typical for you, or using a new device, or a different browser.

Given that a significant percentage of compromises in the last 15 years have been attributed to application access issues (stolen credentials, primarily) resulting in millions of dollars in fraud and loss of personal information, these kinds of techniques are increasingly important to protect both corporate and consumer data alike. According to Javelin Strategy & Research’s 2014 Identity Fraud Report: Card Data Breaches and Inadequate Consumer Password Habits Fuel Disturbing Fraud Trends 61% of breaches in general are the result of stolen credentials. 

And now, given the increasing number of “things” that will be communicating with apps across the globe, the need to provide “things” with access to apps is existential.

And that traditionally means some form of credentials. Credentials that can be stolen and (ab)used to wreak havoc on internal systems, networks, and data.

Now there’s no organization I know of seriously considering assigning every “thing” they might need to allow access to a role. The scale required to achieve that is possible, but not practical. Too, assigning individual identities to each and every “thing” seems an insurmountable challenge; mathematically a limit* that can be never be reached. But the fact is that those things (and their owners) are going to need access to apps, at least some of which may be in your data center proper. Apps that activate it, control it, and report on it.

This is important to consider before deployment. Before general availability. Before millions of consumers have your “thing” trying to access those apps.

Consider how you’re going to provide secure access now, before it’s a problem. Architect a solution that is based on context – on attributes – before it would require firmware or software updates to umpteen million devices.

The vendor of a network interface (ethernet, bluetooth, etc..) can be identified by the MAC addresses. That’s a highly pertinent piece of information when troubleshooting on a local network, especially if the engineer or operator can readily identify it in a packet capture. There are going to be opportunities with “things” that offer the same kind of attribute-based identification that can assist in designing and implementing an ABAC system. Not MAC addresses, which don’t persist outside the local domain, but other device-identifying attributes that can be embedded in the communication exchange and used by the access gatekeepers to determine legitimacy.

And given the number of things you’re going to have to identify if you’re playing in the IoT game, you’re going to want to design and implement one.

So if you’re diving into the IoT (and data from our upcoming State of Application Delivery 2016 report says quite a few of you are) then it’s really not too early to start considering how you’re going to securely manage access. Call it context, call it ABAC, call it something else. But whatever you call it, don’t call it something you forgot to consider – and act on.

*Okay I admit it. My undergraduate minor was, in fact, in mathematics. There. I’ve said it.