PingOne

Best practices for PingOne Protect

Follow these recommendations to get the most out of PingOne Protect.

Risk policies

  • When you add the PingOne Protect service to a PingOne environment, it includes a default risk policy. You should use this policy for your initial testing of risk evaluations. After you’ve seen how this default policy affects the flow experience for your users, you can go back and fine-tune it by customizing individual predictors. You can also create multiple risk policies.

  • Train risk models with production data for 1-3 weeks for workforce usage or 2-4 weeks for customer usage. This should be done with the default risk policy.

  • Use the PingOne Protect dashboards to analyze the risk evaluation results. Identify false positive results, meaning situations that are identified as High risk even though they are interactions with legitimate users.

    Identify the causes of these false positives. Adjust the scores for the different risk predictors in the risk policy to try to reduce the incidence of false positives.

  • Use score-based policies rather than weight-based policies. Score-based policies provide more control over the overall calculation because you can specify an exact numerical score that should be assigned when PingOne Protect determines that there is a medium or high-risk level for a predictor.

    Weights in risk policies have been deprecated for new PingOne environments but can still be used in existing environments.

  • Before modifying an existing risk policy that is in use, use a staging policy to test how the changes will affect risk evaluations.

Risk evaluation results

When a risk evaluation is performed, the PingOne API returns detailed information in addition to the overall risk level that was calculated on the basis of the risk policy used. This information includes data about the event, the user and the device used, and the risk results for the individual predictors in the risk policy. You can take these supplemental details into account when determining how to proceed in the flow.

When deciding how a flow should proceed based on the risk evaluation response, consider:

  • The type of flow, such as initial registration, ordinary authentication to access an application, or authentication prior to a monetary transaction

  • The specific risk factors included in the risk policy that was used

  • The type of business need, such as security needs vs. need for less friction in the user experience, or the frequency of fraud instances

  • The various risk mitigation tools you have available, for example, MFA or knowledge-based authentication (KBA)

You can also use the detailed information in the response to better understand what led to the overall risk level and then fine-tune your risk policies.

The following are the key details returned in the response, ordered by level of importance.

Response detail Recommendation

result.recommendedAction

In some cases, a specific course of action is recommended. For example, when the calculated risk level is HIGH and a bot is suspected, there is a recommendation to carry out the additional bot mitigation steps that your organization has available.

result.value

This field has a value only if you defined an override in your policy and included text in the Notes section.

result.level

The overall risk level calculated.

  • When the risk level is equal to LOW, the flow should probably continue without providing any additional friction for the user.

  • When the risk level is equal to MEDIUM, an MFA challenge should probably be issued, although in some scenarios, you may decide that even at this level there is no need for any additional friction.

  • When the risk level is equal to HIGH, you should present a challenge stronger than an ordinary MFA push.

Because there are conditions where a HIGH risk level will be returned even for legitimate users, you should probably not block a user completely in such situations.

result.score

The raw risk score before the conversion to the LOW/MEDIUM/HIGH risk level. This provides a higher degree of granularity, and you can check how much the score exceeds the thresholds used for converting to risk level.

Predictors

  • Ordinarily, you do not need to have more than one predictor of each type, for example User Location Anomaly. However, when you have different types of users, you might want to have multiple versions of the predictor so that you can use different versions in different risk policies.

    For example, if you have users who travel frequently, you could create one User Location Anomaly predictor that assigns a risk level of High if a user authenticates from outside the radius that you defined and create a second, more lenient User Location Anomaly predictor that can be applied to the users who travel frequently.

  • If you use composite predictors, it will usually be to combine multiple types of predictors when you are interested in the interaction between them, such as assigning a risk level of High for authentications from an anonymous network only if there is also a user location anomaly.

    However, there are situations where you might want to combine multiple predictors of the same type. For example, a Geovelocity predictor allows you to compose an allow list of up to 400 IPs. To compose a larger list of allowed IPs, you can create a composite predictor that contains two different Geovelocity predictors.

Signals (Protect) SDK

  • Implement the Signals (Protect) SDK in your applications. Certain risk predictors, such as the New Device predictor, rely on the supplemental risk-related information that is supplied by the Signals SDK.

Flows in DaVinci

  • Each flow where you include a risk evaluation should include two different PingOne Protect connectors:

    • Add a connector with the Create Risk Evaluation capability at a point in the flow where you want to base the next action on the risk score assigned. For example, show an MFA prompt for MEDIUM or HIGH, but automatically grant access if the risk is deemed LOW.

    • Add a connector with the Update Risk Evaluation capability at a point in the flow after authentication has been completed. This capability represents the system’s ability to learn over time in order to improve results. Always include an update connector in your flows because the learning mechanism is essential for risk evaluation precision.

  • Use the skrisk component in your flow to automatically obtain the information from the Signals SDK.

    This approach can only be used for web applications. For iOS or Android apps, you must manually implement the steps described in the SDK documentation, and then include in your flow a variable that represents the data obtained from the SDK.

  • In the HTTP connector that you add before the connector that creates the risk evaluation, make sure that the skrisk component is at the beginning of the HTML template. All HTML tags that you add should be below the skrisk component in the HTML Template field.