- How does the solution pull together fraud and threat signals to infuse context into a session before a user authenticates?
- Can the solution capture and store additional signals after authentication to inform downstream applications?
- Can the solution add a Google reCAPTCHA node into a registration journey to require user input and reduce automated/bot attacks?
- How does the solution enable step-up authentication and transactional authorization for transactions occurring outside of the normal device, location, or behavioral context of a user?
- Does the solution score user sessions with a high, medium, or low level of suspicion, and send users with a high risk to a honeypot version of their intended target?
How does the solution pull together fraud and threat signals to infuse context into a session before a user authenticates?
When detecting fraud and threat signals before a user authenticates, ForgeRock facilitates integration with existing threat detection and monitoring solutions, using a common audit log service that is commonly consumed by third-party SIEM and analytics solutions such as Trellix (formerly FireEye), Guardian Analytics or Logstash.
Additionally, the ForgeRock Trust Network provides access to more than 75 vendors that provide authentication, identity proofing and threat intelligence capabilities that can be easily integrated into the risk engine to further extend the ability to detect fraud. Technologies such as identity document validation, bot detection, and identity data analytics are essential to reduce the occurrence of fake accounts being opened, while behavioral biometrics, user behavior analysis, transaction risk analysis and exposed credential analysis are instrumental in detecting account takeover and limiting fraudulent purchases.
Data from these threat detection sources can be used to alter the authentication level, which in turn governs access to resources. For example, a user comes to a website after authenticating with an email address and password, which is configured as authentication level 0. Had the user authenticated using a one-time password, they would have had authentication level 1 in their session. With authentication level 0, the user currently cannot access a particular page, say within the /hr/* URL, as the policy governing access requires authentication level 1.
Can the solution capture and store additional signals after authentication to inform downstream applications?
Yes. Intelligent Access provides a powerful platform for modeling the authentication journey using authentication nodes to detect digital signals. This information is not only used to determine risk but also to inform downstream apps of the accumulated knowledge gained during the authentication journey, for example, via session headers, journey variables and cookies.
Can the solution add a Google reCAPTCHA node into a registration journey to require user input and reduce automated/bot attacks?
Yes. Google reCAPTCHA nodes can be added to self-service registration journeys. The CAPTCHA node implements Google's reCAPTCHA v2 and reCAPTCHA v3 widgets and hCaptcha’s v1 widget.
See CAPTCHA node for further information.
How does the solution enable step-up authentication and transactional authorization for transactions occurring outside of the normal device, location, or behavioral context of a user?
With Intelligent Access, authentication nodes can be added to an authentication journey in any position to either set or modify the authentication level. Controlling access to specific resources is done through authorization rules. ForgeRock has a policy engine that allows rules to evaluate the current authentication level and trigger step-up authentication if the user needs to access more sensitive resources.
ForgeRock provides an environment condition type for transactional authorization that can be added to authorization policies. With the flexibility offered by authentication journeys, you can tailor the authentication flow to easily take into account multiple signals and even multiple factors required for a transactional authorization.
Does the solution score user sessions with a high, medium, or low level of suspicion, and send users with a high risk to a honeypot version of their intended target?
Yes. ForgeRock natively supports risk-based authentication (or adaptive authentication) through its Intelligent Access capabilities. Administrators can use digital signals to design a smart login journey that minimizes friction and maximizes security for legitimate users, while suspicious users could be denied access or redirected to a honeypot environment for further monitoring.
As part of the policy evaluation to determine adaptive access, scripts and journeys can be invoked to gather and process contextual data. This contextual data includes factors such as endpoint device context, location, and historical user access patterns which are typically held per identity in the identity repository.
Risk scoring can be pulled together through a Risk Score Aggregator node available from the ForgeRock Marketplace. ForgeRock uses a number of signals to leverage risk scoring for adaptive access decisions that are aggregated in this way. Different flows can be designed based on the various risk level categories/scoring available, which include NONE, LOW, MODERATE, HIGH and UNKNOWN. Based on the risk level and the amount of further investigation a customer would want to conduct, user traffic can be redirected to a honeypot version of the application instead of the real application.
Identity Cloud documentation:
Reduce the Total Cost of Fraud (whitepaper)