The scope and scale of data breaches, like the Target debacle and more recently Home Depot, have shocked many. Some question why it took Home Depot five months to detect a malware intrusion. While others talk about how Target might have handled card data differently and kept it out of the hackers’ hands.

The debate centres around case-specific vulnerabilities and the challenge of detecting an intrusion. Rarely, if ever, do we consider that maybe our concept of identity is flawed – that we might have done more to stop a person accessing an account they were not supposed to in the first place.

Identity is not enough

To understand why upfront proof of identity is not enough to secure data assets, it is important to remember that when a person interacts with a computer system, they do so in real time. In a single session, a user on a corporate network might check his or her emails, print a confidential document and move a sum of tens of thousands of dollars.

In each of these transactions, the person is making a number of implicit claims: that they are who they say they are, that they are authorized to do what they are doing, and that they are on a secure device.

In IT security models that rely on upfront proof of identity, these claims are verified – insofar as the system is capable – before the transactions themselves take place, rather than while they are happening. In a sense, proof of identity is a transaction in itself – one that liberates a person from additional scrutiny in future, regardless of how out of character his or her subsequent behavior might be. This is a shaky proposition, no matter how many authentication methods you string together to secure the initial sign-in.

> See also: The changing face of consumer identity

How would a recognition-based solution work? The answer is pretty simple – it takes into account the context in which the user makes his or her claims, and does this on a transaction-by-transaction basis.

There are lots of factors that could be used as context. IP address, operating system, presence or absence of antivirus software, location, and time of day – all of these attributes offer evidence that might be used to determine whether somebody is who they say they are, or whether they ought to be trusted. The more parameters in play the better, every single item of data expands the system’s scope to make informed decisions.

Think again of the information you use to recognise a person in the real world: their appearance, their clothing, the sound of their voice and their vocabulary, and any number of behavioral attributes. A recognition-based approach uses this principle.

It is important to note that recognition, unlike upfront proof of identity, is not a binary proposition. The system might concede that although a person is attempting to carry out a transaction using a device it has never seen before, the rest of their story checks out well enough to grant access.

As for the degree of leeway the system should allow, this depends on the value of the transaction. If a user wants to open a low-risk document, it can afford to give them more flexibility in terms of device, operating system and IP address than if they were requesting access to confidential financial data, or looking to move a few thousand dollars.

Recognition is the best defense

Some of the biggest data breaches of recent memory – perhaps most notably Target’s – have been a consequence of stolen username and password pairs. It is not just retailers that are implicated in these attacks, either – the use of spear phishing in cyber espionage is well documented, as in Mandiant’s landmark 2013 report on state-sponsored hacking in China. Time and time again, it has demonstrated that upfront proof of identity is a fundamentally fallible proposition on which to base access.

Some companies are working to address this. Typically, however, they end up buying or developing SIEM systems to detect anomalous behavior on their networks. Some of these tools are effective, but they are not the same thing as making recognition the foundation of access management – they do nott stop transactions from happening if contextual criteria are not met, but simply monitor and analyze security events.

Think of how many credit card numbers a hacker can download in a minute, or even a second. Will real-time reporting ever really be responsive enough to deal with the kind of problems we are looking at today?

Imagine a stranger came into your office with somebody else’s ID card: by examining how they look, dress and behave, you would almost certainly recognise that they are not legit. If this process can happen in the real world, is there any reason that it should not happen on a corporate network?

Sourced from Jamie Bodley-Scott, technical product manager, Cryptzone