by Avivah Litan | March 13, 2017 | Comments Off on UEBA and DLP markets Discover Time-Tested “Risk Based” Authentication
Security vendors and their customers are starting to adopt continuous time tested risk assessment techniques that raise the bar for malicious actors.
Of late, some security vendors and enterprise users have been integrating their detection systems with user authentication. When a suspect event is detected, the system automatically reaches out to the user to verify the event in question.
I’ve seen this method already integrated into two applications – UEBA and DLP, but surely any detection system would benefit from this integration. This is a no-brainer evolution of detection functionality.
- UEBA software can detect suspect events like an abnormal user log in from a foreign machine at a strange hour. Cynet, a security platform vendor with a UEBA module offers a feature that requires a user to re-authenticate via SMS OTP if it detects suspect activity.
- DLP applications similarly detect suspect transfers of sensitive data such as those to unknown parties. Symantec has implemented an ‘out of band’ verification feature whereby its DLP application reaches out to the user to validate they are indeed transferring that data willfully.
Similarity to Online Fraud Detection Market
The Online Fraud Detection market has been deploying risk based authentication and transaction verification since at least 2005, when the U.S. banking regulators mandated it. See FFIEC Guidance on Internet Authentication The security market is following suit as it moves towards risk scoring using advanced analytics and away from binary yes/no decisioning based on signatures and rules. Already, some access control vendors like SecureAuth and DuoSecurity support such concepts from the authentication standpoint.
Lessons from the Credit Card World
The credit card world deploys this concept successfully and most broadly. 3DSecure, a security and authentication standard promoted by the card brands (Visa, MasterCard) requires cardholders authenticate to their card issuers (usually with a password) when conducting an ecommerce transaction. But many successful online retailers and card issuers are hyper-sensitive to the need for a very smooth customer experience which by default excludes the need for users to re-authenticate themselves to the system.
The card issuers have therefore implemented transaction risk assessment around 3D secure transactions so that user (entered) authentication to the card issuer is only required on the riskiest transactions as determined by their risk models.
CA Arcot sells a 3DSecure compliant risk based authentication service to card issuing banks, and risk scores and authenticates transactions for some 200 million cardholders around the globe. (RSA Security has a similar business). CA Arcot has developed machine learning models that have become adept at risk scoring so that only a tiny fraction of ecommerce shoppers using its service must authenticate to the system, usually by entering a password.
It is worth pointing out that this convenient user experience could end in Europe under PSD2, an EU directive being strongly challenged by the card brands, because PSD2 could force inconvenient user authentication on every purchase transaction, regardless of the risk.
BUT….. Criminals Beat Risk Based Authentication and Transaction Verification
Before anyone gets too excited about the promise of risk based authentication and transaction verification – note this:
The criminals have figured out how to beat each and every one of those methods, for example by forwarding voice calls, SMS messages, or by using man-in-the-browser or man-in-the-mobile techniques. Most compromises of out of band user authentication or transaction verification use some form of social engineering which bypasses pretty much any control out there.
For years, bank users have experienced all types of compromises against ‘strong authentication’ using the methods listed above. One of the most egregious circumventions of risk based transaction verification occurred in the U.K. where many corporate bank customers must use a smart card reader and smart card to execute money transfer transactions. Here’s how that attack worked
- Bank issues corporate customers smart card readers and smart cards
- Fraudster infects corporate customer browser
- Victim logs into bank, fraudster in another location gets message from the malware of that event and calls victim on the phone; victim answers
- Fraudster tells victim that he is the bank calling and his account needs system maintenance
- Tells customer to shut monitor
- Tells customer that the bank needs to test money transfer functionality
- Fraudster transfers money out of customer’s account ten times
- Each time, fraudster asks victim to provide transaction verification code
- Victim inserts smart card into smart card reader and gives fraudster verification code from smart card reader ten times
- Money is moved successfully to fraudster account ten times!
- Fraudster tells victim he can now turn his monitor back on
Actually the game isn’t over. There are stronger measures that enterprises and service providers can take to ensure the customer or user is indeed the legitimate one. Basically, these measures require layers and layers of continuous identity assessment (See Absolute Identity Proofing is Dead; Use Dynamic Identity Assessment Instead ). In the end, there is no black and white security anymore. There are only degrees of certainty and risk. Risk based authentication and transaction verification certainly adds to those degrees.
Read Complimentary Relevant Research
100 Data and Analytics Predictions Through 2021
Over the next few years, data and analytics programs will become even more mission-critical throughout the business and across industries....
View Relevant Webinars
Digital Business Architecture: From Strategy to Guiding Execution
New techniques have emerged to help CIOs and EA practitioners leverage business architecture to guide investment and execution decisions,...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.