You Can't Spell Enterprise Security without MFA

You Can’t Spell Enterprise Security Without MFA

Paul Madsen, Principal Technical Architect

Office of the CTO

Ping Identity

Copyright © 2013 Ping Identity Corp. All rights reserved. 1

Agenda


•Why•What •Which•When & Where

WHY MFA?


• Deficiencies & vulnerabilities of one factor mitigated by another (unless they are dependent)• Raises the bar for attackers• Compromise of one factor insufficient to enable attacker access to sensitive resources• Voted ‘Easiest to pronounce acronym’ 4 years in a row!


5

I come not to bury passwords but to appraise them

MFA is Using two or more login factors in

order to authenticate a

user



user

multiple independent



user

Dynamically ch

oosing from




user

Dynamically ch

oosing from

implicit & explicit

authenticationmultiple independent



user

/\

with the optim

al balance

of security, u

sability,

and cost

Dynamically ch

oosing from

implicit & explicit

authenticationmultiple independent



user

/\

with the optim

al balance

of security, u

sability,

and cost

Dynamically ch

oosing from

implicit & explicit

authentication /\based on an assessment of

risk (determined by

analysis of various

contextual signals and

other considerations)




user

/\

with the optim

al balance

of security, u

sability,

and cost

Dynamically ch

oosing from

implicit & explicit

authentication /\based on an assessment of

risk (determined by

analysis of various

contextual signals and

other considerations)


13

Authentication Factors

Firstly, some secret thou knoweth, secondly some object thoust have in thy living, and thirdly some quality of thy p'rson

In practice•Something you forgot•Something you left at home•Something you are nervous about sharing

15

Key Authentication Trends

Trope doesn’t adequately acknowledge 1.Device as factor2.Local authentication3.Contextual verification

17

Device as factor

Phones make great *have* factors

•Connected•Computation•Storage•UI

Phones make great *have* factors

•Connected•Computation•Storage•UI

In a package a user won’t leave at home

yes

noIs device authenticated?

no

yes

User authenticated?

Enjoy public application

access

Authenticating device & user

yes


no

yes

User authenticated?

Enjoy partial application

access

User logs in from untrusted

device.


access


yes


no

yes

User authenticated?


access

Enjoy full application

access

Devi

ce

Regi

stra

tion


device.


access


yes


no

yes

User authenticated?


access

Enjoy full application

access

Devi

ce

Regi

stra

tion


device.


access



access

Stand up straight


• If relying on device authentication, the ‘device posture’ of that device becomes paramount

• This ‘device posture’ includes aspects like PIN, malware, screenshot enabled etc

• In the enterprise, EMM solutions allow IT to define & enforce policies over device posture – and (in emerging trend) to report current situation into authentication systems

• Work underway in the Identity Defined Security Alliance to normalize this pattern

25

Local authentication

Local authentication

• Capabilities of phones also make practical a model where the verification check is performed locally, ie on the device• As used for ‘device unlock’ – the user logically authenticates to the device• Local authentication (particularly for biometrics) has privacy advantages – no secrets on the server

FIDO Alliance


• The issue with leveraging local authentication is how – A server can prompt the client to perform an authentication

– How client can ‘prove’ to server that it did so• FIDO Alliance normalizes the above pattern• Abstracts away from the server the specifics of the local authentication on the client via an asymmetric cryptographic challenge/response pattern• Inherently multi-factor – must have the private key as well as the local factor (either know or are)

28

Contextual verification

Contextual verification

• Contextual verification is a model of passively collecting signals & parameters from the user’s environment and analyzing/comparing them to identify anomalies (from expected)

• In the context of authentication, supplements (or in some instance replaces) traditional overt & explicit logins.

• Valuable because it can increase assurance without negative usability implications

• Signals can be collected via multiple channels & touchpoints, e.g. device, browser, agents

• Assumption is that attacker unlikely to be able to simulate all signals in order to impersonate valid user

• Manifests as • Geofencing• Device fingerprinting


Explicit giving way to implicit


Explicit

Implicit

Trend

Explicit

Implicit

31

Choosing Factors

Considerations when picking factors


• IT benefits Is the authentication method easy to deploy? Will it require additional IT resources? Can it work across multiple channels, e.g. online, telephony, etc?

• Usability Is the authentication method easy to use? Will end users accept the new process? Can users be expected to have a device capable of supporting a particular mechanism? Will users be concerned about privacy?.

• Initial costs Is there a cost per user that will grow every time a new user is added? What is the replacement cost – both for the device and its associated administrative burden?

• Deployment costs What are the costs associated with deploying the authentication mechanism. Is client hardware or software required? If so, how is that distributed to consumers and what are the associated costs?


Analysis

Lowassurance

Highassurance

Poor usability

Goodusability

Smart cards

OTP Hardware token

Passwords

Mobile authentication app

Device fingerprinting

Low cost

Medium cost

High cost

SMS OTP

Analysis

Lowassurance

Highassurance

Poor usability

Goodusability

Smart cards

OTP Hardware token

Passwords

Mobile authentication app

Device fingerprinting

Low cost

Medium cost

High cost

SMS OTP

FIDO?

36

Recommendations

Risky business


• Risk-based MFA demands that resources be analyzed for the risk of their compromise

• OMB m04-4 defines a model for assessing risk of an authentication mistake - determined by– Potential harm or impact

– Likelihood of the authentication mistake

• ‘Harm’ includes– Financial loss, damage to reputation, personal

safety, civil/criminal prosecution

• Once risk has been assessed, authentication factors can be chosen accordingly

Break away from password hegemony


Flexibility


• Particularly for consumer space, provide different options for MFA factors

• Both to support heterogeneous user base and to offer fall back mechanisms if and when a particular factor doesn’t work, e.g. if a mobile phone is offline or if the consumer is roaming, fall back to a generated OTP

40

MFA 2.0

MFA 2.0

1. Factor in context1. Anomalies initially determined by policy, allow for

natural learning future 2. Risk it

1. Choose authentication factors based on assessment of risk

2. Rely on contextual verification when possible3. Device advice

1. Leverage local authentication and device authentication2. Be sensitive to device posture


MFA 2.0


Risk & Policy EngineRisk & Policy Engine ContinueContinueStart Start

Active AuthenticationActive Authentication

DenyDeny

BehaviorBehaviorContextContext

External External Feeds Feeds

Community Community Intelligence Intelligence

DenyDeny

BehaviouralFeedback

CorrelatioCorrelationn

Environment Environment

ApplicationApplicationinfoinfo Policy Policy

Policy

DataCopyright © 2014 Ping Identity Corp. All

rights reserved. 43

IdP

Device

Environment

Authentication

MFA

Policy

DataCopyright © 2014 Ping Identity Corp. All

rights reserved. 44

IdP RP

Device

Environment

Authentication

MFA Authorization

45

The M

is table stakes

46

Thanks

Technology

You Can't Spell Enterprise Security without MFA