Risk reasons, device recognition and behavior anomaly in VIP Authentication Hub

Products

• Symantec Identity Security Platform - IDSP (formerly VIP Authentication Hub)

Issue/Introduction

1. What is causing the "Invalid Device" tag to trigger?
2. "Device expired" when the "Device FP expiry" is set to 365 days. Is it due to inactivity?
3. What means "Behavior anomaly"?
4. Would the "registered devices collected through account recovery flow" be available in another flow like Login?
5. What are the best practices to start off with the learning starting from scratch?
   
   Since for high volume logins, every user would get a REVIEW so each of them would mandatorily need to go through a second factor and hence it would lead to a lot of unnecessary friction/cost.
   
   What's the experience/guidance on this from the existing implementation?
   
   

Resolution

1. Remembered device expired and the "Invalid Device" tag.
   
   When the tag that is part of the device signature is not valid, this error will show up.
   
   Debugging SDK should give more input on how an invalid tag is getting generated.
   
   For instance:
   
   deviceFPExpiryInactivityTime:
   
   This is tied to the last access time. The risk reason is expected to be "DEVICE_EXPIRED_NO_AUTH".
   
   To illustrate:
   
   If a user accesses the device today i.e. 9 July and if the setting is 90 days, then if the user accesses the device on say 9 Aug, then would the Device FP expire on 7 Oct.
   
   deviceFPExpiryMaxBindingLife:
   
   This is tied to the last created time. The risk reason is expected to be "DEVICE_EXPIRED_MAX_LIFE".
   
   
2. Yes, it's most likely the reason.
   
   eventId  : 8738000506308693385
   value    : DEVICE_EXPIRED_MAX_LIFE
   
   eventId  : 3374942537054267732
   value    : DEVICE_EXPIRED_NO_AUTH
   
   Generally for shared devices, the device recognition triggers first, saying it could be a shared device, and after successful evaluation with post-risk, that device is marked as shared and both users can use the same device.
   
   
3. Information is available as part of the risk reason, which gives generic information (1).
   
   To illustrate:
   
   "ANOMALY: Best Match: IP:different or unknown; IP:country matched, IP:unmatched state, IP:unmatched city, IP:significant distance from known locations, IP:unknown domain, IP:unmatched org, OS:matched, BROWSER:matched."
   
   This indicates IP is different etc.
   
   "ANOMALY: Exact match with known anomaly. "
   
   This indicates the user is logging in again from an already known anomalous cluster.
   
   
4. Yes, the device registered via risk can be used via the authenticate API.
   
   
5. In general, by best practices, start with low risk scores or higher risk thresholds and eventually increase to the ideal risk score.
   
   

Additional Information

1. Device Recognition and Behavior Anomaly in Authentication Hub Risk Engine