RSA Authentication Manager Express - PowerPoint PPT Presentation

rsa authentication manager express n.
Skip this Video
Loading SlideShow in 5 Seconds..
RSA Authentication Manager Express PowerPoint Presentation
Download Presentation
RSA Authentication Manager Express

play fullscreen
1 / 72
RSA Authentication Manager Express
Download Presentation
Download Presentation

RSA Authentication Manager Express

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. RSA Authentication Manager Express Technical Workshop Dave Taku, CISSP – Product Manager Chris Crellin – Product Manager

  2. Agenda 10:00 Welcome Session #1 10:10 – 10:40 Product Overview 10:40 – 11:00 AMX Demo 11:00 – 11:15 Sales Tools 11:15– 11:45 Deep Dive: The RSA Risk Engine 11:45 – 12:30 Lunch Session #2 12:30 – 13:00 RBA Integration 13:00 – 13:30 Deployment Best Practices 13:30 – 14:00 Troubleshooting 14:00 Wrap Up

  3. RSA Authentication: Innovation Timeline Understand the customer’s need to balance RSA Authentication Manager Express Cost Convenience Security B2C Applications More than 10,000 users Small & Mid-Size Organizations Fewer than 2,500 users EnterpriseMore than 1,000 users Risk-Based Authentication (B2C) Convenient, user-friendly strong auth with lower TCO Hardware tokens Software tokens Passwords SMS & text messaging

  4. Authentication Market by the Numbers Millions of SSL VPN users in 20121 Percent of companies still using passwords for remote access authentication2 Most commonly used password3 1 Gartner Specialized SSL VPN Equipment, 2008 2 Forrester Enterprise And SMB Security Survey, North America And Europe, Q3 2008 3

  5. Net New customers are the ideal for RSA Authentication Manager Express

  6. What We’ve Heard Secure Access for Mobility and Collaboration Required Capabilities Before Scenario Proven authentication technology “Lack of confidence about who is remotely accessing information” “Users struggle with cumbersome security mechanisms” Convenient and user-friendly solution Authentication solutions suitable for employees, contractors, partners, and clients “Diverse end-user base results in varying requirements” Easy to deploy and manage solution that integrates seamlessly “Security Solutions are Complex and Expensive” Fast to implement solution that can be proven to meet compliance requirements “Meeting and proving compliance is complex and time consuming” Cost-effective strong authentication that is stronger than a password, but easy to use for IT staff and end-users SOLUTION

  7. Introducing Authentication Manager Express Multi-factor authentication with zero footprint On-Demand Authentication Risk-Based Authentication Easy to ManageAppliance Platform

  8. On-Demand Authentication (SMS) • One-Time Password (OTP) delivered via SMS or email • Based on the RSA SecurID algorithm • Compatible with any mobile phone from any carrier • Open support for many third party SMS gateways and modems • No software to deploy or tokens to manage • Provides multi-factor authentication: • Factor #1 – PIN • Factor #2 – Mobile device or e-mail account

  9. Risk-Based Authentication How it Works Device Identification User Behavior SSL VPN Authentication Policy Protected Resources PASS Activity Details Assurance Level Web Portals Web Browser RISKY RSA Risk Engine Identity Challenge OWA PASS ? FAIL SharePoint On-Demand Tokencode Challenge Questions Access Denied

  10. Use Case: Web-Based Remote Access For Employees, Contractors, Partners and Clients SSL VPN Employees & Contractors Manufacturing Vendors accessing an Order Management System hosted by XenApp Healthcare Community Health Clinics eliminating the “token necklace” for medical staff Professional Services A Law Firm that exchanges sensitive information with clients using an online portal Employee Mobility SSL VPN and web-based email for employees & contractors Government State and local agencies that must adhere to compliance regulations Web Portals Partners & Vendors OWA Clients SharePoint

  11. Customer Challenges Related Before Scenarios that Compel Action • Purchase or deployment an SSL VPN in need of authentication • Development of a new business plan to launch an online portal for partners, customers or employees • Emergence of new or renewed government/industry regulations • Awareness of emerging threats • Incidents of breach, loss, or fraud • Reconsideration of strong authentication solutions based on awareness of new options including AMX • Appearance of a new security officer/executive

  12. Wins across all verticals and use cases Healthcare Finance Retail Manufacturing Government Services Industrial Biotech Devices Hospitals Clinics Insurance Local banks Credit unions Traditional Online Local government Transportation Defense Consulting Technology Accounting SSL VPNs, Citrix, OWA, SharePoint, web portals

  13. Abt Associates • Theater: Americas (US) • Company Profile: Mission-driven consulting company with 2,000 employees across 40 countries • Use Case: Secure remote access to Cisco SSL-VPN • Number of Users: 1,600 • Customer requirements: • Out of the box integration with Cisco SSL-VPN • Easy for users; previous token-based solution was challenging for the remote user base • Customizable challenge questions across multiple languages • How AMX solved the problem: • Out of the box integration with leading SSL VPN vendors meant a simple integration with the existing Cisco solution. • Behind the scenes risk-based authentication simplified the login process for Abt users, reduced help desk calls, and improved employee satisfaction with the company’s IT systems. • Customizable challenge questions enabled IT management to deploy step-up challenge questions in thirteen required languages.

  14. Datametrix • Theater: Europe (Norway) • Company Profile: Provider of IP-based solutions that enable secure communication through data, voice, and video. • Use Case: Secure access to a customer (B2B) web portal • Number of Users: 500 • Customer requirements: • Secure access to the web portal • Strong authentication that is easy for users • Prevent terminated users from gaining unauthorized access • How AMX solved the problem: • Proven risk-based authentication technology secures access to web-based applications • The transparent multi-factor authentication solution protects against unauthorized access without negatively impacting the customer login experience • Device binding and email challenge prevent terminated users from gaining access even if accounts were still active.

  15. Bernas, Padiberas NasionalBerhad • Theater: Asia Pacific (Malaysia) • Company Profile: Malaysian national company dedicated to managing the procurement, warehousing, distribution, marketing and exporting of all domestically grown rice. • Use Case: Secure remote access to Citrix • Number of Users: 250 • Customer requirements: • Strong authentication to protect sensitive customer information • Integration with existing Citrix solution • Easy for remote and technologically unsophisticated users to use • How AMX solved the problem: • Lightweight nature of AMX means a simple deployment process using minimal IT resources • Prewritten integration scripts enabled a simple, out of the box integration with the existing Citrix solution • Behind the scenes risk-based authentication means nothing new for users to learn, no end user disruption

  16. In Summary… AMX addresses the growing demand for tokenless authentication • WHO: Small and mid-size organizations with less than 2500 users that are still using passwords today. • WHAT: A convenient and user-friendly strong authentication solution based on two tokenless authentication technologies: Risk-Based and On-Demand. • WHERE: Browser-based remote access to SSL-VPNs, web portals, and other web-based applications. • WHEN: Remote access and information sharing with employees, contractors, partners, and clients. • HOW: An easy-to-manage and cost-effective hardware appliance that integrates out-of-the-box with the leading web-based solutions. • WHY: Traditional strong authentication alternatives are too expensive, complex, or cumbersome to meet the need.

  17. AMX Demo

  18. Licensing, Configuration, and Pricing • Licensing: Single SKU perpetual licensing • Licensed per registered user • Includes all authentication options • Credentials are re-assignable • Does not expire • Pricing: Volume based pricing tiers (similar to Authentication Manager) • Appliance bundles are available • No tokens to purchase or renew • Maintenance: • Annual software maintenance is 21% of license fee • 3-year AHR is included with the h/w appliance Years 4 and 5 optional and additional • Same as the SecurID Appliance 130 (1U hardened Linux OS) • Scalable up to 2,500 users • Primary + Replica (1) RSA Authentication Appliance 130 AMX Web Tier Server • Required for RBA deployments • Installs on a separate Windows or Linux server (not included) • Included with all AMX appliance orders

  19. AMX 1.0 vs. AM 7.1

  20. Deal Qualification Checklist • Use to quickly evaluate AMX customer fit • Green: No Issues • Yellow: Caution • Red: Stop • Review recommendations for flagged items

  21. RSA Partner Central • Collateral • Datasheet, solutions brief, etc. • All localized (Polish, Hungarian, Czech, German, etc.) • Demo/POC • Overview/demo (5-min Flash video) • Technical demo (12-min video) • Remote Validation Center (RVC) • NFR Kits: appliance and VM options • Sales Tools • Deal qualification checklist • Quick reference guide • AM vs. AMX comparison • FAQ

  22. Additional Training Opportunities • RSA Educational Services (Online Training) • SALES: Introduction to Selling RSA Authentication Manager Express • TECHNICAL: What’s New: RSA Authentication Manager Express

  23. Understanding the RSA Risk Engine

  24. The RSA Risk Engine • Proven sophisticated risk engine • Same risk engine as Adaptive Auth • Protects 250+ million online identities • Optimized for Enterprise use cases • Optimized for: Network Security vs. Fraud Mitigation • Predictable: Use case vs. challenge rate • Simplified: Assurance levels vs. risk scoring • Self tuning risk model adapts to each customer environment • Common device characteristics are de-prioritized in the risk score • Suspicious behavior is based on norms for the overall user population RSA Risk Engine

  25. The RSA Risk Engine Device Identification User Behavior SSL VPN Authentication Policy PASS Protected Resources Activity Details Assurance Level Web Portals Web Browser RISKY RSA Risk Engine Identity Challenge OWA PASS FAIL ? SharePoint On-Demand Tokencode Challenge Questions Access Denied

  26. Device Identification • 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. • For each device that interacts with AMX, the following information is captured: • Device Fingerprint • Network Forensics • Device Token • 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.

  27. Device Identification Device 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.

  28. Device Identification Network Forensics • Matches device IP configuration to previously registered IP addresses for that machine • Supports DHCP with partial credit based on strength of match: • Exact IP address: Perfect match • Same Class C subnet: Strong match • Same Class B/A subnet: Weak match Note: IP address is used as an identifying device characteristic, but the risk associated with a new, unrecognized, or stale IP address is also evaluated as part of the behavioral analysis

  29. Device Identification 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

  30. Device Identification Putting it all together • Device tokens (cookies/FSO) ensure a unique match • Without device tokens, strength of match is determined by statistical probability • The risk engine automatically updates its scoring algorithm based on the statistical probability of certain characteristics within each unique deployment.

  31. Behavioral analysis (predictors) • 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 • Comparative anomalies: e.g., new or infrequently used IP address are higher risk • Velocity anomalies: high velocity of users of a single IP/device or high velocity of IP addresses for a single user • Overall impact of behavior anomalies are based on frequency and recentness • Higher velocity and/or lower statistical probability increase the risk score • Recent events are considered high risk but become less impactful over time

  32. 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 unusual location soon after a failed Identity Confirmation challenge • High Risk: Clearly identified fraudulent activity • Authenticating from a machine with an invalid or modified cookie Note: The older a risk event, the less impact it has on your risk score

  33. Assurance Levels • Assurance Level: The degree of confidence associated with each user authentication attempt • Minimum Assurance Level: • Minimum assurance required to authenticate without being challenged • Defined by policy (multiple policies can be created) • Four pre-defined assurance threshold – HIGH, MED-HIGH, MEDIUM, LOW Strong Device Match Risky User Behavior Decreases Assurance Increases Assurance

  34. Identifying the Key Assurance Level Contributors for each authentication attempt 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 comparative anomaly • Highest contributing velocity anomaly

  35. Selecting a 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

  36. Other Determining Factors • The risk engine requires a learning period: • During which it is building up a profile of users, their devices, and of the general user population behavior. During this initial period, users may be challenged at a higher rate • The risk engine employs soft matching techniques: • That allow for a partial match based on statistical probability. For example, the risk engine may have insufficient information to unequivocally identify a device, but it will use a variety of forensic tools to assess the probability of a match and adjust its scoring accordingly. • The AMX risk engine employs a self-tuning model: • That dynamically compensates its statistical matching algorithms based on the commonality of certain parameters within your deployment. A self-tuning model improves security while optimizing the model for your specific deployment and reducing overall challenge rates, but this also means that results could vary over time

  37. Silent Collection • Enables a seamless migration of users from passwords to RBA without pre-provisioning or other administrator intervention • During silent collection, the risk engine: • Passively monitors user authentications attempts • Updates its risk model based on collected profile and behavioral data • Automatically registers user devices • Does NOT challenge high risk users • If a user achieves the minimum assurance threshold they are prompted to complete the self-enrollment process

  38. Silent Collection Pros and Cons Pros • Seamless transition with minimum disruption for end users • No administrator intervention required • User-specific silent collection period minimizes the collection window • Useful for initial AMX roll out and for on-boarding of new users • Better tuned risk engine before users are challenged Cons • During the collection period, authentication is password-only • Some risk that an attacker could bind an unauthorized machine • Collection period can expire before the user completes enrollment

  39. Lunch

  40. Agenda 10:00 Welcome Session #1 10:10 – 10:40 Product Overview 10:40 – 11:00 AMX Demo 11:00 – 11:15 Sales Tools 11:15– 11:45 Deep Dive: The RSA Risk Engine 11:45 – 12:30 Lunch Session #2 12:30 – 13:00 RBA Integration 13:00 – 13:30 Deployment Best Practices 13:30 – 14:00 Troubleshooting 14:00 Wrap Up

  41. AMX Integration

  42. On-Demand Authentication Flow Intranet Internet DMZ SSL-VPN Protected Resources 1. Connect to SSL-VPN 4. Access Granted SecurID Agent 2. Validate PIN 3. Validate On-Demand tokencode AMX Appliance 2. Send On-Demand tokencode

  43. Risk-Based Authentication Flow Intranet Internet DMZ Login Page (w/RBA script) SSL-VPN Protected Resources 1. Connect to SSL-VPN 8. Access Granted SecurID Agent 6. Redirect to SSL VPN with artifact 4. Risk Assessment (challenge if necessary) 7. Validate artifact using SecurID APIs RBA Service AMX Web Tier AMX Appliance 5. Return “auth artifact” 2. RBA integration script redirects the browser to the AMX web tier 3. Authenticate user

  44. Generating an RBA Integration Script • Configure authentication agent • Select third-party product from “Integration Javascript” drop down • Download customized integration script (am_integration.js ) • Follow Implementation Guide to apply the script to the third-party product

  45. RBA Integration Script • Adds Risk-Based Authentication to an existing SecurID Agent • Custom JavaScript added to the logon page of the protected resource • Redirects the user to the RBA logon service (AMX web tier) • Created during the SecurID agent configuration process and deployed out-of-band to the protected resource • Requires a product-specific RBA Integration Template • Certified Integration Templates • Bundled with each new AMX release • Updates available on RSA Secured ( and between releases • Custom Integration Templates • Can be developed using the RBA Integration Template and reference examples

  46. RSA Secured Partner Solutions Plug-and-Play Integration and Certified Interoperability • Certified and supported by RSA • Implementation Guides with illustrated step-by-step instructions • Builds upon SecurID agents already embedded in hundreds of products IMPORTANT NOTES!! If customer’s product differs from the version in the Implementation Guide, check with Partner Engineering to confirm compatibility If single sign-on (SSO) is a requirement, check the Implementation Guide to confirm support Visit to view all supported solutions or to request new product integrations

  47. Does an RBA Integration Template Exist? If not, can I create one? • A certified RBA integration template already exists if either of the following is true: • It is a certified “RSA Secured” solution for Authentication Manager Express • It is compatible with the RSA Authentication Agent for Web for SecurID • Web applications built on IIS or Apache web servers • Examples: Outlook Web Access, SharePoint, etc. • A custom RBA integration template can be developed if ALL of the following are true: • It is a certified “RSA Secured” solution for SecurID • Integration uses the native SecurID APIs (RADIUS implementations are NOT supported) • The user interface is browser-based – i.e., It does NOT require an installed client Note: ODA does not require an integration template since ODA is natively supported by SecurID authentication agents

  48. Deployment Best Practices

  49. Deployment Best Practices • Confirm the use case is a good fit for AMX • Using the Deal Qualification Checklist • Plan in advance for the network deployment • What Deployment Scenario will be used? • Does the customer require server redundancy? • Will the deployment require web tier servers? • What is my load balancing strategy? • Do I have the latest integration script and Implementation Guide for the application to be protected? • Collect network configuration data using AMX planning tools • IP addresses, host names, firewall ports, etc.

  50. Deal Qualification: Common Deal Breakers • AMX does not support RADIUS • SSO requires one of the following: • Kerberos Constrained Delegation (KCD) • Offline authentication API (Citrix only) • Separate web tier server required if RBA or Self-Service will be accessed from outside the firewall