Identity Is Not Security – Context Is King

According to the 2017 Verizon Data Breach Investigation Report, 7.3% of users fell for phishing attacks. Even more astounding, 15% of those people fell for subsequent phishing attacks that hijacked their credentials.

It’s a short trip through those holes for hackers to spread out and infect other users across your enterprise, share your proprietary information – including the most private details of your customers – and basically wreak havoc.

And it may be a while before you even know they have infiltrated your infrastructure, since, after all, they are using valid credentials.

Despite this sad scenario, at least one company still goes to market with the specious logic that “Identity is security.”

Um, no. Simply put: Identity is NOT security.

In today’s organization, it is way too easy to compromise a user’s credentials – especially when many people still rely on their email address as a username. They’ve unwittingly fought half the battle for those attacking your infrastructure by using such an easily discoverable username.

Now armed with the username, all the attackers have to do is figure out the user’s password to be able to launch brute force, dictionary and phishing attacks, just to name a few. Cracking passwords is not exactly rocket science for these smart intruders.

The moral of the story: Identity is not security. Usernames and passwords alone don’t get the job done. Not in a world where mobility is so powerful for organizations looking for a competitive edge – and so powerful for those who want to do damage to your infrastructure.

That’s why context of access should be the king of all that your security rules.

The full context of how a person is trying to gain access to an application shouldn’t just involve typing in a username and password. Context of access provides the ability to consider other factors – such as the device the user is employing, the security status of that device, the exact location from where access is being requested, the type of network connection being used, and even the time of day. As those attributes shift around in the user’s always-on mobile world, your organization can use the parameters surrounding that context to allow, deny or limit access.

Let’s say a user is on a laptop using your secure local network. The user leaves the secure confines of the office network and logs in to the not-so-secure public Wi-Fi at the local coffee shop. Should that user have the same all-encompassing level of access to your proprietary enterprise resources?

The CFO’s report on quarterly results for the next earnings call?

The VP of Sales’ automation database?

Your employees’ HR records?

The answer, generally across the board, is no.

Yet many employees today can still access everything and anything from that coffee shop through a full remote desktop – with who-knows looking over their virtual shoulders for the ripe opportunity to penetrate deep into your network and steal your competitive information.

The above scenario is a recipe for disaster, and it’s completely avoidable.

As the Verizon report shows, just because a person has the right username and password when they are logging into your network doesn’t mean they are who they claim to be. Credentials today are too easily stolen.

But with context of access, security administrators now are better able to set up security policies to protect access to their mission-critical enterprise resources. They can quickly confirm whether the mobile device, laptop or home computer being used for access is already on the organization’s authorized list. They can determine whether an iPhone has been jailbroken, or the device being used is a rooted Android. They can check to see if the antivirus for those devices are up to date. They can verify that the security certificate for managed corporate devices is current and valid.

The combination of all these factors – the context of access – creates a 3-dimensional profile of the user at that specific point in time to apply against the security policy engine your organization uses for access management. Then, and only then, should security teams determine the level of access to provide, both to applications hosted locally and in the cloud.

It may indeed be a situation where the decision is made to provide full access to all applications. Or it could be a situation where access is provided only to a select number of applications. Or access could be totally denied. It is possible today, using context of access, to achieve all of this seamlessly, which makes it easy and simple for the end user.

Identity is still important to security, but identity alone is NOT security. It should be just one factor used in the much larger, and more important, equation that is context of access. By binding user credentials with security policies based on the multiple factors within context of access, organizations today can significantly strengthen the protection of their enterprise resources, and ultimately, their bottom line.