Traditional authentication solutions require a trade-off between security and usability, often deployed with a “one-size-fits-most” strategy. Today’s enterprise needs more to effectively protect critical applications when delivering access in a world without boundaries.

By applying a risk-based approach to our authentication strategy with identity assurance, we can go beyond simple authentication approaches. We can deliver both security and convenience without sacrifice. Risk-based identity assurance is transforming multi-factor authentication from a simple yes/no decision or step-up process by adding intelligence to the decision of which access is granted in which situations.

Identity assurance helps to quantify:

1. How sure am I this user is who they claim to be?
2. How sure do I need to be based on the information they are accessing?

There are six keys considerations when creating an identity assurance strategy. By examining each of these you can improve information security while simultaneously optimizing the end user experience.

This is the first in a series of blogs in which we explore these six key areas. The first is business context.

Business Context and Authentication
Business context is the information we can seamlessly gather to help form baseline assumptions about an access request. A good way to look at business context is to break it down into three fundamental pieces:

1. The data
2. The person
3. The environment

The Data: What Is Being Accessed?
Often when multi-factor (and two-factor) authentication solutions are put in place, they protect data that resides in the company’s data center. However, due to the massive expansion of enterprise SaaS applications and hosted data centers, more and more sensitive data is stored in the cloud instead of a corporate data center.

Unfortunately, authentication has not always kept up with ensuring the most sensitive data is protected appropriately, no matter where it resides. As a result, companies are left with a multitude of applications, each containing a set of user identities with different, disjointed authentication requirements. All too often these authentication requirements don’t align to the sensitivity of the information contained in them.

Regardless of the data location, the fundamental question is, “How sensitive is the data being accessed?” Is this resource storing company intellectual property or the company holiday calendar? It’s important that we treat this data appropriately as the alternative is either too little security for the sensitive information or unacceptable user experience for information where access should be simple. When we treat data appropriately, based on its sensitivity, we can then apply a single solution to give an appropriate and consistent experience.

The Person: Who Is Requesting Access to the Data?
Equally important to the data contained in the protected application is the access a specific user has within that application. Is this user an IT administrator with nearly limitless access or is this person an end user with limited access? We need to view these users specific to their different levels of assurance to gain access. We have information available about the user in potentially multiple identity repositories. We must be able to leverage the available data from all of these sources to adequately ensure the appropriate security is applied.

The Environment: What Is the Session Context of the Request
The last piece of business context is the environment of the data request. The first component of the environment is the user’s device where we discern if it’s registered, known for this user, or managed by the company. Beyond device, we look at other session context attributes such as trusted networks, trusted locations, black-listed locations and IP addresses. Each of these types of attributes can impact if we allow access to the resource and what level of additional assurance a user must provide to gain access.

Putting It All Together
Taken together, these three business context fundamentals (data, person, environment) allow us to build policies to ensure the authentication required is appropriate for each access request. When evaluating multi-factor authentication solutions to provide identity assurance, make sure the solution fully leverages business context to create powerful policies. Equally important is that these components are configurable in an easy-to-understand way so an administrator can have confidence in who they are allowing access and what authentication will be required.

While business context is one key to a successful identity assurance strategy, it is important to look beyond what can be done with static rules created from these types of attributes. We also need to consider anomaly detection –the topic of our next blog in this series. In the meantime, learn more about identity assurance and how business context impacts authentication decisions in this video.