Imagine if you could move security from a series of static yes/no decisions to a dynamic, adaptive approach that takes into account the circumstances of an access request and enforces the correct decision for the individual situation. This is an emerging practice called contextual (or adaptive) security that is proving to have major positive impacts at the organizations that choose to adopt this approach.
Let me explain with an example.
There are a number of factors that come into play when deciding who should be able to access what:
- Identity information such as role and authentication
- Application information such as specific authorizations
- Network information such as location, time of day, and device used
- Other information such as individual user usage habits and known malicious or approved IP addresses
Each can return a yes/no decision with regard to access
It could be represented like this:
In this simple example (and the way the vast majority of organizations undertake security) if any single factor returns a “no” answer, access is denied. So if policy, by default, only allows access during business hours, the fact that a legitimate employee is working in the office doing the right things but happens to be working late doesn’t matter … or best case requires IT intervention to temporarily provide the necessary access.
But what if you could take all factors into account and dynamically adapt security to suit the situation. Then access is based on a risk score, not a bunch of un-related yes/no decisions.
So we could represent that like this:
For a user of this type a security threshold of 25 has been set and a variety of risk factors are taken into account to generate the score – device used, time of day, application, location, etc.
So let’s play around with the numbers. An approved user is seeking access to an application that he needs to do his job, he’s working after hours on prem with a company owned and controlled device. The “scoreboard” would look like this:
Where previously the after-hours request would have been outside of policy and access would have been denied, in this situation the after-hours request becomes part of the accumulated risk score and since 10 is well below the threshold of 25, access is allowed.
Let’s change a couple of factors – same after hours request, but now the employee is working remotely and accessing from his personal device that the company manages but does not own. The scoreboard would look like this:
With a score of 25 (right at the threshold) access would still be granted but only with additional levels of assurance that the user making the request is actually who he says he is. So the access control solution asks for a second factor of authentication and after proving the identity of the user, access is granted.
Let’s take the example one step further. Now, everything is the same except the user is making the request form a shared computer kiosk that company neither knows about nor controls. The scoreboard would look like this:
With a score that exceeds the threshold (and the corresponding higher risk that the company simply isn’t willing to take) access is denied.
This is admittedly a simplistic example, but the concept is sound. There are literally dozens of factors coming from everything from an IAM system to firewalls, and from applications to other systems that can contribute to the risk score, and a number of points that could enforce the decision.
This risk scoreboard approach to security is a reality and can be quickly and easily implemented in your organization. To learn how, download and read the white paper Context-aware Security – The Who, What, When, Where and Why of Access. You can move security from a static, restrictive approach to an agile and adaptive business-enabler.