Michel Tepper Consultant Westcon Security

1. RSA Authentication Manager ExpressTechnical Session Michel Tepper Consultant Westcon Security

2. RSA Authentication Manager Express Technical Session Understanding Risk Based Authentication Integrating RBA and ODA Deploying AMX

3. 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

4. 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

5. 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)

6. Risk-Based AuthenticationMulti-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

7. 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

8. 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.

9. Device MatchingDevice Fingerprint • Analyzes the detailed hardware and software characteristics of each computer • User agent string: The version, platform, and the acceptance-language 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.

10. Device MatchingDevice 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

11. Device MatchingDetermining assurance based on the strength of device match The lower the probability of a random match, the greater the trust in the device’s identity

12. 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

13. 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

14. 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

15. How It Works: Risk-based Authentication

16. How It Works: Risk-based Authentication • AMX supports 4 minimum assurance levels: • High • Medium-high • Medium • Low

17. 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

18. 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

19. RSA Authentication Manager Express Technical Session Understanding Risk Based Authentication Integrating RBA and ODA Deploying AMX

20. Deploying On-Demand and Risk-Based Authentication • On-Demand Authentication • 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 • Configure ODA delivery method • Email (SMTP gateway) • SMS (Aggregator or modem) • Risk-Based Authentication • Configure authentication agent (same as ODA) • Deploy RBA integration script

21. 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

22. 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

23. RSA Authentication Manager Express Technical Session Understanding Risk Based Authentication Integrating RBA and ODA Deploying AMX

24. 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

25. AMX Security Console

26. AMX Operations Console

27. RBA Service Console

28. 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

29. Deployment Decision Tree

30. Deployment Decision Tree

31. Deployment Decision Tree

32. AMX component – Primary Instance Primary instance handles: • All administration (including self-service) • Authentication requests

33. AMX component – Replica Instance Replica provides: • System – level redundancy • Real-time backup of all system data • Fault-tolerant authentication • Authentication load balancing

34. AMX component – Web tier Benefits of a web tier include: • Protect internal network • Allows customization of the RBA service and SSL-VPN user interface • Improves system performance • Requires Replica

35. AMX component – Identity Sources You can store data in: • The Internal Database • Active Directory

36. 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 !

37. Self-Service Console Can be customized: - Branding - Header & Footer - Styles

38. 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

39. RSA Authentication Manager ExpressTechnical Session Summary

40. 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

41. Thank you very much.