Context-Aware Security

The who, what, when, where and why of access.

Use cases in improving user productivity with a security analytics engine

Abstract

Don’t you wish you could give your users all the access they need, without worrying about bad guys getting their hands on legitimate user credentials and causing trouble?

You can simplify security by basing it on a few yes/no decisions when users log in, if you don’t mind denying access to users with legitimate needs. But, if you can base security decisions on the who, what, where, when and why behind the user’s request, it can reduce the chances of keeping people from doing their work and increase the ease of legitimate access.

This paper examines several ways in which static security keeps organizations from running smoothly. It then describes the context-aware model of a security analytics engine (SAE) that returns a risk score to enforcement points. Readers will see how the context-aware model can increase both security and user productivity.

Introduction

The theory behind security is noble: IT should ensure that only approved users can access systems and data, that they access them for only the right reasons and that they are doing the right things once they’ve gained access.

In practice, though, security has been a static process of IT administrators saying “no,” denying access and placing barriers between users and the resources they need to do their jobs. The result is static security that impedes user productivity and slows the organization from its principal business.

Risks like business-destroying theft and even cyber-terrorism have turned security into a moving target, calling for a better approach. With the advent of mobile users and the increasing sophistication of attacks, context-aware (or adaptive) security replaces the static approach with a real-time evaluation of the who, what, when, where and why surrounding each request for network access.

When users must remember multiple passwords, calls to the help desk spike, with the largest share of them for mere password resets.

This paper examines several ways in which static security interferes with the smooth operation of many organizations. It then outlines several use cases in a context-aware model of a security analytics engine (SAE) that returns a risk score to enforcement points. Readers will see how the context-aware model can increase both security and user productivity.


Static security at Acme — The traditional approach

Consider the traditional, static approach to security, at a fictitious company called Acme.

Acme has been in business for a few years and has not deployed contextual security, but instead has taken a static approach to security. All employees work on premises and have adequate network access to all the tools they need to do their job. The security built into each application has been easy to define and enforce, so IT focuses mainly on keeping systems running, only occasionally intervening on behalf of users to restore access or correct problems.

But over time, changes in the environment stretch Acme’s static approach to security.

Separate networks

Acme acquires another company and becomes a global business. Suddenly, Acme’s systems take on an entirely new user population on another continent with a new set of applications never before deployed with Acme’s approach to security.

Acme decides to maintain two different networks and issues credentials for each network to both sets of employees. Now every Acme employee has two passwords that expire on different cycles and demand different complexity rules (for example, one requires special characters in the password, the other forbids them). Calls to the help desk spike, with the largest share of them for mere password resets.

New SaaS application

The company continues growing, so the VP of Sales decides that the newest SaaS-based CRM application is the perfect thing to push the company to the next level. Without consulting IT, he subscribes to the service and requires that his employees begin using it. The data held in the system is sensitive, so IT and the VP of Sales agree to a static security policy: users may access the application only when on premises and only during regular business hours.

VPN access

Those static restrictions keep Sales from getting the most out of the CRM application, so IT selects an SSL VPN to maintain security while expanding access to remote employees at all hours.

However, this introduces the management burden of another set of user credentials, more software on employees’ computers and additional obstacles to users trying to get their job done. Calls to the help desk spike again for two reasons: the VPN is temperamental, and users have yet another password to forget.

The threat landscape outside

Meanwhile, IT is keeping an eye on the constantly evolving threat landscape and has implemented firewalls to block access from certain IP addresses. Unfortunately, Acme is trying to use a static approach to stay ahead of dynamic threats, so IT lives in a constant state of wariness. They know that the question is not whether somebody without authorization will get in, but when.

Bring your own device (BYOD)

Gradually, more users start bringing their personal devices (tablets, smartphones and laptops) to work and circumvent established security practices to share information and do their jobs. The risk of having sensitive information fall into the wrong hands is too great, so Acme IT reacts by banning personal devices altogether. This generates resistance from users all over the company and puts Acme at a serious competitive disadvantage, but IT does not have the time to vet and procure a mobilityspecific security solution.

Those are common situations. The static approach views security as a ring of keys, in which each new situation requires installing a new lock and issuing new keys. Eventually, though, the result is a jangling ring of keys that impedes access to every door. In that model, security is based on siloed yes/no decisions that ignore the many static security decisions being made elsewhere in the organization.

Context-aware security (or adaptive security) empowers organizations to base real-time security decisions on the total risk associated with multiple pieces of security information.

Context-aware security — A new, adaptive model

The disadvantage of the ring-of-keys security approach is its limited view of each request for access. When the organization allows or denies access based on a series of unrelated yes/no decisions, the likely result is incorrectly denying access to too many users with legitimate needs. But if the organization can base security decisions on the who, what, where, when and why behind the user’s request, it can make access control more accurate and increase the ease of legitimate access.

Context-aware security (or adaptive security) empowers organizations to base real-time security decisions on the total risk associated with multiple pieces of security information.

Contrary to the ring-of-keys approach, context-aware security is like a wellinformed, completely ethical guard accompanying each user and unlocking the door only when appropriate. As an additional measure of security, the guard may ask the user for a second form of ID if he does not recognize the user or if knows that the user rarely enters by that door.

The security analytics engine

One context-aware model implements a security analytics engine (SAE) that returns a risk score based on multiple factors:

Those are common situations. The static approach views security as a ring of keys, in which each new situation requires installing a new lock and issuing new keys. Eventually, though, the result is a jangling ring of keys that impedes access to every door. In that model, security is based on siloed yes/no decisions that ignore the many static security decisions being made elsewhere in the organization.

  1. Browser used – Includes historical analysis of any browser use that falls outside of normal behavior for the user
  2. Location pattern – Detects any requests for access originating from an abnormal location
  3. Specific location – Prevents access initiated from specific locations or geographies known to foster malicious activity
  4. Time – Detects any requests for access that occur outside of customary times and days for the user
  5. Blacklist – Prohibits requests for access based on a list of forbidden networks or network addresses
  6. Whitelist – Authorizes requests for access based on a list of approved networks or network addresses

The SAE is configurable to weigh the who, what, when, where, and why of access requests according to the organization’s needs, user populations, threats, practices, applications and infrastructure. The engine returns scores to enforcement points (such as access management software, firewalls and encryption technologies) that can allow/deny access or require step-up (two-factor) authentication before allowing access – a concept called adaptive authentication.

The SAE is configurable to weigh the who, what, when, where, and why of access requests according to the organization’s needs, user populations, threats, practices, applications and infrastructure.

context aware security analytics engine workflow

Security analytics engine in use with identity access management, firewall and monitoring.

Context-aware security at Acme

Returning to the company described above, the SAE has the potential to reduce complexity, mitigate risk and boost user productivity in Acme’s process of access control.

Risk policy

Assume that Acme has developed a risk scoring policy with the values shown in Table 1 for a user named Andrew Barney in the role of Sales Manager.

According to this policy, if the combined risk score for an access request by a sales manager reaches the threshold of 25, then step-up authentication is required; above 25, access is denied altogether.

Table 1: Risk scoring policy for Acme sales manager
Risk Policy Value
Time
During normal work hours 0
Outside normal work hours 10
Location
On-premises 0
Remote 10
Device
Corporate controlled 0
BYOD managed device 5
Unmanaged device 10
Policy threshold
Sales Manager 25

Scenario 1: Working late

Andrew is working at his corporate-controlled PC in the office one evening. At 8:17 pm, later than he normally works, he tries to access Acme’s SaaS-based CRM system, which does not require authentication when accessed from inside the corporate network. According to the scoring policy above, the SAE would return the total risk score of 10, as shown in Table 2.

Since Andrew’s total risk score is well below the threshold of 25 for a sales manager, Andrew may access the CRM application without additional authentication.

Table 2: Total risk score – Working late
Context item Value
Current time 10
Location 0
Device status 0
Account Abarney
User role Sales Manager
Policy threshold for role 25
Total risk 10
Access status Allowed

Scenario 2: Working late, away from the office

Two weeks later, Andrew is on the road. At 8:17 p.m., he requests access to the same CRM system from a hotel room. He is using his personal tablet, which Acme manages under its BYOD policy. Table 3 shows Andrew’s total risk score of 25.

Since the risk score hits the threshold, SAE tells the enforcement point to prompt Andrew for a second factor of authentication before allowing access. Andrew uses a two-factor authentication token to verify his identity and Acme’s web access management solution allows him to connect to the CRM application.

Table 3: Total risk score – Away from office on managed BYO device
Context item Value
Current time 10
Location 10
Device status 5
Account Abarney
User role Sales Manager
Policy threshold for role 25
Total risk 25
Access status Step-up Authentication

Scenario 3: Unmanaged device

Suppose that instead of using a managed personal device, Andrew tried to access CRM with a new tablet that is not yet managed by Acme’s BYOD policy. Table 4 shows the total risk score.

The combination of after-hours work, remote location and unmanaged devices pushes the risk score to 30. This exceeds the policy threshold of 25 for a sales manager, so the web access management solution enforces Acme’s policy and denies Andrew access to the CRM system.

If the access attempt had occurred during work hours or from Acme’s premises, the risk score would have been low enough to allow Andrew to access the CRM system.

Table 4: Total risk score – Unmanaged device
Context item Value
Current time 10
Location 10
Device status 10
Account Abarney
User role Sales Manager
Policy threshold for role 25
Total risk 30
Access status Denied

Scenario 4: Wrong user and role

Finally, assume that Bob Barney, one of Acme’s new developers, is poking around the network one day and decides to see what he can learn about Acme’s customers from the CRM system. Bob is at his desk on his laptop. Table 5 shows how the SAE scores his request for access.

Bob requests access during work hours, on premises and from a corporatecontrolled device, so his total risk score is 0. However, his account name and role do not match those approved for access to the CRM system, so he is denied access.

The result is the same when a request that seems legitimate comes from an IP address on the blacklist (perhaps one known to distribute malware) or from a suspicious location (for instance, a banned country).

Table 5: Wrong user and role
Context item Value
Current time 0
Location 0
Device status 0
Account Abarney
User role Developer
Policy threshold for role 0
Total risk 0
Access status Denied

Conclusion

Static security, based on a collection of unlinked security factors, no longer suffices for controlling access. A security analytics engine weighs factors from multiple sources and produces a total risk score that enforcement solution can use to control access in real time.

A context-aware, adaptive approach to security takes into account the who, what, when, where and why of access requests and can adjust enforcement in real time to provide the correct security in any situation.

With context-based security, organizations can protect themselves without imposing onerous authentication requirements and multiple password schemes on users. The result is stronger security without impeding user productivity.

About One Identity

One Identity's solution for context-aware security is the Security Analytics Engine (SAE) in One Identity Cloud Access Manager (CAM). SAE acts as a risk scoreboard that returns a risk score based on factors such as those described in this paper, and CAM enforces access decisions based on the SAE risk score.