RSA Authentication
Manager Express
Technical Session
Michel Tepper
Consultant
Westcon Security
RSA Authentication
Manager Express
Technical Session
Understanding Risk Based
Authentication
Integrating RBA and ODA
Deploying AMX
AMX Authentication Methods
AMX Authentication can be deployed as:
• Risk Based Authentication (RBA) with On-Demand Authentication (ODA)
for the Identity Challenge
• RBA with Security questions for the Identity Challenge
• ODA only
Risk –Based Authentication method
Risk-Based Authentication assesses the Risk by evaluating:
• Information about the client device
• User behaviour
If the risk is High, the user is challenged using:
• On-Demand Authentication
• Security questions
AMX Risk Engine
• Evaluates the risk associated with each
authentication attempt
• Challenges users if their assurance level does not
meet the policy defined threshold
– On-Demand (SMS/email)
– Security Questions
• Risk model continuously adapts to changes in each
customer environment
– Common device characteristics are de-prioritized in
the risk score
– Suspicious behavior is based on norms for the overall
user population
• Same Risk Engine protecting more than 350 million
online identities (RSA Adaptive Authentication)
Risk-Based Authentication
Multi-Factor Authentication without replacing Passwords
Factor #1:
Something
You KNOW
Factor #2:
Something
You HAVE
Factor #3:
Something
You DO
Step Up:
Something
You KNOW
or HAVE
AMX Risk Engine Scores
Factors used to determine a risk score include:
• Device matching
– Devices bound to the user account are low risk
– Positive ID = high assurance + low risk
• Behavioural anomalies
– Will lower overall assurance
– Raise risk level
Overall assurance = device match + user behaviour
Device Matching
• Device information is a collection of facts about a user’s machine. These
collected facts are evaluated by the risk engine to help identify fraudulent
authentication attempts.
• If the device can be identified as a registered device for that user, the
authentication attempt is considered low risk; otherwise, the user is
considered a higher risk and will be challenged.
Device Matching
Device Fingerprint
• Analyzes the detailed hardware and software
characteristics of each computer
– User agent string: The version, platform, and the acceptancelanguage header (the user’s language preference)
– System Display: Width, height, and color depth of the user’s
screen
– Software Fingerprint: Browser components and plug-ins
installed on the device
– Browser language: The language of the actual browser
– Time zone: The user’s current time zone in GMT
– Language: The user’s browser language and the system
language
– Cookies: Whether or not the user has cookies enabled on their
device
– Java-enabled: Whether or not the user has java enabled on
their device.
Device Matching
Device Token
• Device tokens are created and placed on the user’s machine for future
identification using a combination of cookies and Flash Shared Objects
(FSO’s)
• Device Token Recovery can automatically restore user-deleted tokens
based on device forensics
• Device Token Theft Protection prevents impersonation of a device using a
stolen token (e.g., via malware) through a combination of techniques
– Encryption of the device ID in the token prevents reuse on another computer
– Tokens generation counter prevents replay of an older token
Device Matching
Determining assurance based on the strength of device match
Match with existing
attributes in profile?
Collective statistics
What’s the probability of a
random match ?
User Profile
User
IP address
cookie
%
Attribute
Value
cookie
...
0%
IP class B
124.55
3%
recently used user-agents
match
ü
user-agent
MSIE 5.5
recently used SW fingerprints
match
ü
IP class B +
user-agent
combination
recently used cookies
ü
match
SW fingerprint recently used IP class B
user-agent
no match
The lower the probability of a random match, the
greater the trust in the device’s identity
...
1.5%
0.1%
Behavioral analysis
• Evaluates behavioral trends for each user/device and corporately across all
users in the organization
Anomalous behavior increases the risk associated with an authentication attempt
Common behavior lowers the relevance of this factor in the overall risk score
• Three categories of behavior are evaluated
Profile anomalies: recent password or account changes
Velocity anomalies: abnormal rate of IP-to-user/user-to-IP authentication attempts
IP anomalies: associates risk with new or infrequently used IP address
Examples of Risky Behavior
• Low Risk: Common activities that nonetheless could be associated with
fraud
– New accounts, recently modified accounts, or authentications from previously
unknown locations
• Medium Risk: Multiple activities combined in a suspicious way
– Authenticating from an unknown location soon after a failed Identity
Confirmation challenge)
• High Risk: Clearly identified fraudulent activity
– Authenticating from a machine with an invalid or modified cookie
The older a risk event, the less impact it has on your risk
score
Identifying the Key Risk Score Contributors
Overall Assurance Level
– Assurance based on device identification and
behavioral predictors
– Five levels from Very Low to High
– Assurance < the defined policy threshold will result
in an Identity Challenge
Device Identification Score (Arg 3 - 5)
(raises
the overall assurance level)
– Highest contributing token element
– Highest contributing networking element
– Highest contributing device fingerprint element
Behavioral Analysis Score (Arg 3 - 5)
(lowers
the overall assurance level)
– Highest contributing profile anomaly
– Highest contributing IP velocity anomaly
– Highest contributing user velocity anomaly
How It Works: Risk-based Authentication
How It Works: Risk-based Authentication
AMX supports 4 minimum assurance levels:
• High
• Medium-high
• Medium
• Low
Assurance Level
• Assurance Level – Confidence associated with a user authentication
attempt
– A strong device match increases the assurance level
– Suspicious behavior decreases the assurance level
• Minimum Assurance Level:
– Assurance threshold required to authenticate without an Identity Challenge
– Defined by policy (multiple policies can be created)
– Four pre-defined assurance threshold – HIGH, MED-HIGH, MEDIUM, LOW
Guidelines for selecting an appropriate Minimum
Assurance Level
• High Assurance: BEST for protecting sensitive assets when higher challenge rates are acceptable
• Authentication from easily-identifiable, corporate-owned assets (e.g., an employee laptop)
• Users that regularly authenticate from the same location (e.g., branch office, partner location, or an
employee’s home)
• Medium-High Assurance (Recommended): VERY GOOD for protecting sensitive assets when
higher challenge rates are not acceptable
• Authentication from corporate and individual-owned assets when policy can be dictated (e.g., cookies
must be enabled).
• Laptop users that frequently authenticate while traveling
• Medium Assurance: GOOD when a balance between protection and end user convenience is
required
• Authentication from uncontrolled, Individual-owned assets (e.g., a personal laptop or home PC)
• When corporate policy cannot be enforced or when tracking objects (e.g., cookies or flash shared
objects) cannot be reliably used
• Low Assurance: Provides the lowest level of protection and should only be used with the least
sensitive assets and when end user convenience is the overriding priority.
• Provides only minimum device assurance while challenging users primarily based on suspicious
behavior
RSA Authentication
Manager Express
Technical Session
Understanding Risk Based
Authentication
Integrating RBA and ODA
Deploying AMX
Deploying On-Demand and Risk-Based Authentication
• On-Demand Authentication
1. Configure authentication agent (identical to SecurID / ODA in AM 7.1)
•
•
RSA Authentication Agent for Web (IIS/Apache)
Any RSA Secured Partner Solution that is web-based
2. Configure ODA delivery method
•
•
Email (SMTP gateway)
SMS (Aggregator or modem)
• Risk-Based Authentication
1. Configure authentication agent (same as ODA)
2. Deploy RBA integration script
RBA Integration Script
• Modifies the logon page of the protected resource (e.g., SSL-VPN or web
application) to securely and transparently redirect users to the RBA logon
service hosted by AMX
• Simple RBA templates (XML-based) used to automatically generate
deployment-specific integration script
• RBA templates come from several different sources
– Built into the AMX appliance (Checkpoint, Cisco, Citrix, Juniper)
– Download certified solutions from RSA Secured (www.rsasecured.com)
– Create new RBA templates using the Integration Guide and reference examples
• Note: RBA templates can be created for any web-based product that
already include a SecurID agent. RADIUS support will be available in a
future release
SMS Integration
•
•
•
•
Includes AM 7.1 SP4 enhancements
Supports SMS aggregator and SMS
modem options
New SMS plug-in is compatible with
most HTTP-based SMS gateways
More RSA Secured Partner Solutions
–
–
–
–
–
–
–
–
–
–
Clickatell
KPN SMS Gateway
Logix Mobile
Multitech MultiModem iSMS Server
Sybase 365
Talariax sendQuick Alert Plus
AT&T (coming soon)
mBlox (coming soon)
StrikeIron (coming soon)
Syniverse (coming soon)
Visit www.rsasecured.com for a current list of supported products or
to request integration with a specific SMS aggregator or modem
RSA Authentication
Manager Express
Technical Session
Understanding Risk Based
Authentication
Integrating RBA and ODA
Deploying AMX
AMX User Interfaces
Authentication Manager Express provides the following interfaces:
• Security Console (admin)
• Operations Console (admin)
• Self-Service Console (user)
• RBA Service Console, login user interface shared by:
– Security Console
– Operations Console
– Self-Service Console
AMX Security Console
AMX Operations Console
RBA Service Console
AMX Components
•
•
•
•
•
•
•
•
An Authentication Manager Express has the following components:
Primary Instance
Replica Instance (optional)
Web tier (optional)
Identity Sources
Self-Service console
Authentication agents (optional)
RBA integration
Deployment Decision Tree
Deployment Decision Tree
Deployment Decision Tree
AMX component – Primary Instance
Primary instance handles:
• All administration (including self-service)
• Authentication requests
AMX component – Replica Instance
Replica provides:
• System – level redundancy
• Real-time backup of all system data
• Fault-tolerant authentication
• Authentication load balancing
AMX component – Web tier
Benefits of a web tier include:
• Protect internal network
• Allows customization of the RBA service and SSLVPN user interface
• Improves system performance
• Requires Replica
AMX component – Identity Sources
You can store data in:
• The Internal Database
• Active Directory
Supported Identity Sources
AMX supports:
• Up to 5 Domain Controllers + one Global Catalogue
• One Identity Source filter per physical directory
• Connections from AMX to external Identity Sources are Read-Only
AMX:
• Does not modify your existing LDAP schema
• Creates a map to your data
Note: Active Directory Application Mode is not supported !
Self-Service Console
Can be customized:
- Branding
- Header &
Footer
- Styles
Authentication Agents
An Authentication Agent:
• Is the component on the protected resource that communicates with AMX
authentication requests
• Is required by any resources that uses ODA or RBA
• AMX only works with web-based authentication agents
Different types of authentication agents protect different types of resources:
https://gallery.emc.com/community/marketplace/rsa?view=overview
RSA Authentication
Manager Express
Technical Session
Summary
Summary of main differences between AM and AMX
AMX supports the following authentication methods:
• RBA
• ODA
• ODA as sole authentication method
• No SecurID (hw / sw)
AMX supports a single replica only
AMX supports the following external Identity Sources:
• Up to 5 DC + 1 Global catalog
• Read-Only connections
• Single Identity Source filter per physical Directory
AMX supports Security Domains but not Realms
Thank you very much.