Threat Guard
Protect your customers—and your business—with a comprehensive risk engine providing modern account security and a frictionless customer experience
Next Identity Secure includes Threat Guard—a modern risk engine capable of detecting a variety of fraudsters, bad actors, and cybercriminals. Threat Guard uses industry-standard providers to evaluate and supply data points to accurately identify fake devices, location spoofing, and high-risk behavior in a user's online fingerprint.
Threat Guard is composed of:
- Risk Indicator Source Provider: This is the service that Next Identity will engage to supply the threat detection information. Currently, there are two supported providers of information: IPqualityscore and Akamai Edge Account Protector. Some later actions and configurations available are dependent on the provider used.
- Risk Indicator Signals: These are the types of risks that can be flagged based on the data from the Risk Indicator Source Providers. Examples of signals are bot detection, risk detector, impossible travel detector, and new device detector.
- Threat Guard Actions: These are the actions that can be taken in the end user workflow once a Risk Indicator Signal is triggered. Actions include allow, step up auth, block, and notify.
- Threat Guard Action Trigger Matrix: Depending on the Source Provider of the Risk Indicators, a different matrix may be available to customers to choose the best action to take when a specific indicator is triggered.
Threat Guard Risk Indicator Signals
Bot Detector
Bots can pose significant business problems, as they can be hard to detect and prevent. The Source Providers of Threat Detector data can identify and alert Next Identity to many non-human users in real time. This feature allows an application team to reduce the number of fake and replicated accounts, credential stuffing attempts, and other harmful activities that could damage your business.
Although simple bot management techniques such as CAPTCHA or honeypot can be beneficial in reducing the probability of bots submitting forms, they may not always be adequate to prevent more intricate attacks, like credential stuffing. The Threat Guard's Bot Detector Signal is intended to help bridge that gap and provide superior levels of protection for your enterprise application.
Risk Detector
We understand how vital it is to safeguard your business against fraudulent activity. The Source Providers of Threat Detector data analyze many data points to develop real-time risk scores for a transaction.
The Risk Detector Signal indicates potential threats in real time. The Risk Detector Signals are configured (based on the source provider in use) to set a high-risk, medium-risk, and low-risk threshold, giving your application the opportunity to take appropriate action based on the severity of the risk score indicated.
New Device Detector
Device detection is a process used to identify a device or browser by determining which technology, such as the operating system (OS) and browser plugins, along with other active settings, are present. Unlike website cookies stored on a user’s device, device "fingerprints" are stored server-side. The Threat Guard Risk Indicator Source Providers can identify a suspected new device based on user, the result of a user logging in from a new device is based on the configuration for that application and will be passed along to the appropriate output.
Impossible Travel Detector
The Impossible Travel Detector is a security feature that helps safeguard sensitive information by detecting and flagging any suspicious activity related to user movement. With this feature, Threat Guard Data Source Providers can determine a user's location during sensitive actions such as authentication or updating personal information and compare it to the location of their most recent action before that. This is then passed along to the Threat Guard Service, and appropriate action can be taken during the end-user workflow.
A key benefit of the Impossible Travel Detector is that it allows security teams to detect and prevent account hijacking. They can configure Threat Guard and choose to notify, perform a step-up verification, or even block a request from a flagged account.
Signal Check Order
The Next Identity Threat Guard completes the signal checks in the following order:
- Bot Detector: Identifies automated bot activity.
- Risk Detector: Identifies potential fraudulent behavior, including fake accounts and malicious users.
- New Device Detector: Identifies the device used to attempt transactions.
- Impossible Travel Detector: Identifies authentication from locations that meet impossible travel criteria.
Depending on the source of Threat Guard risk data, configurations can be made to set appropriate allowed thresholds for each of the above risk signals (see the sections on risk action triggers for specific providers for more detail).
If any of the above triggers a “blocked” status, it will not continue checking the other risk factors. If any of the above triggers a step-up challenge, the service will not send a second notification or alert after that unless specifically configured.
Actions for Threat Guard
Four different actions can be triggered in the Next Identity Threat Guard service based on configured allowed thresholds for each transaction:
- Allow: Allow the request to proceed.
- Step-up Authentication: Require the user to re-enter the password or complete verification.
- Notify: Alert the user of the potential attack via email or SMS.
- Block: Block the request from proceeding altogether.
Action | Description |
---|---|
Allow | Allow the request to proceed with no interruption to end-user experience. |
Step-up Authentication | Requires the user to complete a pin verification. The pin will be sent through the same identifier key used for sign-in (ex., If email was used for sign-in, the pin will be sent to email; if mobile was used for sign-in, the pin will be sent via mobile). This is limited to email or mobile (SMS mobile messages only, no voice pins). Magic link instead of pin is not supported. The user will not be asked for a step up more than one time per transaction. If the first attempt at sending a pin fails, there is a configurable option for the user to select the method to send a follow-up pin (email or mobile) depending on what verified identifiers exist in the user record. |
Notify | The Notify action sends an email or SMS to the end user, alerting them to the potential risk detected. Notify options differ depending on the risk indicator source as well as by email/SMS service used. Consult your Next Reason consultant to discuss specifics. |
Block | Block the request from proceeding altogether. The block action generates a form submission error message that is shown to the end users during the hosted screen sign-in page. The location and look of the message are not configurable, but the text can be configured by a customer if desired. Consult your Next Reason consultant to discuss options for messaging. |
To determine what actions are available (or configurable) for each risk signal indicator and source provider, please see the pages specific to each provider.
A note on legacy step-up authentication settings vs Threat Guard.
All new onboarding customers and applications will be encouraged to use the new Threat Guard service and actions by default. When in use, the action matrix will dictate the end-user authentication experience and will override any other two-step configurations in place at an application or user level. This means that even if an application had previously used two-step sign-in by default on all logins, with the dynamic threat guard actions, the users will only be presented with a challenge to login if needed based on threat indicators. This also applies to users who have opted in to two-step sign in on an individual level; if the application is using the dynamic threat guard feature, the user will only be challenged on login based on the threat indicators detected, and so may not be challenged for a second step on every login.
Threat Guard Risk Indicator Source Providers
Only one threat guard risk indicator source can be configured per customer at a global level. The Threat Guard service will not consume risk indicators from multiple sources. If support for an additional provider is needed for Threat Guard, please consult your Next Identity solution team to determine the feasibility of adding that provider as a risk indicator source.
IPQualityScore is the default source of Threat Guard Risk indication for Next Identity. Customers can utilize the IPQualityScore through Next Identity or independently procure a license for IPQualityScore.
All configuration, enablement, service contract, and capabilities of the Akamai Edge and the Account Protector service are between Akamai and the customer. Next Identity is not responsible for Akamai Edge services.
Configuration
How to configure Threat Guard
Threat Guard is configured by Next Reason. Contact your Next Reason Solutions Architect to discuss your security requirements.
FAQ
Q: Are mobile-based able to configure notifications for new devices?
A: This depends on the source of the risk information and the providers used for notifications.
For IPQualityScore as the source, there will be no SMS notification. Only applications that store email addresses can enable this functionality. However, mobile device information will still be captured and stored.
Akamai Edge Account Protector allows SMS notifications, but deliverability may be limited by country.
Please check with your Next Reason integration consultant for available options for SMS notifications.
Q: Which kind of integration is required?
A: Only applications that make use of Next Identity Unify's Journeys feature, including Register, Activation, and/or Login screens can use Threat Guard's risk engine features at this time.
Q: Can Threat Guard features be enabled by client?
A: Yes, Threat Guard's risk engine features can be configured by the client depending on requirements and global policies set by your service administrator.
Q: Is there any Personal Identifiable Information (PII) data that will be stored
A: No. Only non-PII metadata that is obtained publicly will be stored.
Q: Is there a dependency from a third party?
A: Yes, a third-party provider is leveraged to collect user data, and a second provider to send the emails.
Updated about 1 year ago