Maksim Kabakou - Fotolia
When it comes to biometrics in enterprises, two seemingly contradictory things are true. First, biometrics have been around for a long time; and second, adoption has been lower than many expected given that long history.
This could be changing, though. The integration of biometrics into consumer technologies (for example, smartphones), coupled with the steady decline in cost and the increase in sophistication of readers could help biometrics gain traction.
Time will tell if this is the case or not, but in the interim, biometrics can be a valuable tool in an enterprise’s security toolbox. Judiciously applied, biometrics can help satisfy certain security goals.
It’s helpful for enterprises to have an understanding of the possible advantages (and, yes, the disadvantages) of biometrics from a security perspective as they consider possible usage.
Let’s take a look at some of these as well as how (as a practical matter) security pros might incorporate biometrics into their overall security programme.
It is important that enterprises first understand that biometrics change both the security properties and the threat model when they are used. There are a few ways in which this happens.
The immutable biometric
First, it impacts security properties in a potentially positive way as a secondary or tertiary authentication factor. That said, users are often concerned about attackers obtaining access to biometric data. Since the biometric itself is immutable (that is, it cannot be changed if lost or stolen), compromise is justifiably concerning.
However, most systems used for authentication do not store the biometric data itself. They retain instead an “extraction record” of the actual biometric in a format that makes it challenging (or, in some cases, practically unfeasible) to derive the biometric from the extracted record. This, though, is not universal. It is up to the enterprise to evaluate and make the best decision based on its usage.
Likewise, enterprises should recognise that some biometric information may be “public” in nature (fingerprints are left on keyboards, while voice patterns are available for capture every time a sentence is uttered). Again, enterprises need to factor this in to the solutions they build. Many biometric systems build in countermeasures (such as “liveness” detection, challenge/response, etc), but, once more, it is not universal and may be an optional (sometimes more expensive) feature. Being an educated consumer is therefore important here.
Lastly, as with any security control, the protection provided should be counterbalanced by the impact of the attack and the impact on the user experience.
An example of what I mean by impact of attack is the Malaysian car thieves in 2005 who hijacked a Mercedes-S car with a fingerprint-based security system; to circumvent the protection, they removed the driver’s index finger. I think almost every car owner would have preferred just handing over the keys.
By balancing the user experience, I am referring to balancing the way the system handles false acceptance and false rejection errors.
Since no two capture events are identical (a finger might be in a slightly different position, a person’s voice modulates slightly differently each time they say a phrase), the system under the hood looks for a probable match rather than an exact match. That probability can be adjusted. A narrower range of probability results in more false rejections (legitimate users being denied access) while a broader range means more false acceptances (non-legitimate users being granted access).
The place where those two values meet, the crossover error rate, will probably vary based on the usage the enterprise anticipates and the role the system is designed to fill.
These factors have implications for how enterprises should approach implementation.
As with pretty much anything, it is helpful to start with requirements. Even if the impetus behind the adoption of a biometric is not security per se (it may be user convenience or an economic driver such as policy/licence enforcement), it is valuable to analyse both the business and the security requirements.
Approaching this systematically and being inclusive in setting it is advantageous as it lets individual stakeholders voice particular concerns (for example, legal or compliance considerations about jurisdictional-based constraints about biometric use) and helps build buy-in. One strategy to tie requirements to stakeholder goals is through a formal process; the COBIT 5 goals cascade, for example, can be adapted for this purpose.
One the requirements are defined, it can be helpful to construct a threat model of the proposed usage. A standardised approach can be used here – for example, an approach leveraging the model espoused by Microsoft or OWASP can be adapted. Ideally, the goal here is to systematically evaluate and address the possible threats ahead of time.
In addition to computer-based threats, include physical ones during this phase. Ask the hard questions. Is it possible to “steal” the biometric? What are the consequences (for example, to the user) should that happen? What can be done to discourage physical-based attack scenarios to ensure safety in the event of a determined and ruthless attacker?
As part of this phase, evaluate systematically the plan for a potentially compromised biometric. What happens if a record is stolen? Can it be replaced? If so, what can be done to help mitigate the consequences? What’s the appropriate crossover error rate? What amount of false acceptances and false rejections are permissible in light of the goals?
Lastly, try before you buy. Having been through pilot phases for numerous biometric systems, I promise you that you will encounter unanticipated scenarios as you pilot. Iris scanners that give some users headaches? Physical characteristics that pose a challenge to some users (try fingerprinting individuals with very dry skin)? Residual oils on a glass fingerprint “pattern”? Error rates that differ significantly than those published by the supplier?
These are all challenges I’ve encountered in the field. The opportunity to test and adapt quickly is a necessity in light of what you might find.
Ed Moyle is director of emerging business and technology at ISACA.