Risk policies - PingOne Services - PingOne Risk - PingOne - PingOne Cloud Platform

After you have defined risk policies, they can be used as part of the integration with PingFederate, part of a flow designed with PingOne DaVinci, or part of an authentication flow built with the PingOne API.

You build risk policies on the Risk Policies page, which is accessed from the Experiences menu.

When you build a risk policy, you make decisions about the following:

• Which of the predictor types should be included when calculating the overall risk

  When you create a new risk policy, it includes by default the following subset of the predictor types that PingOne supports:

  • Anonymous network detection
  • Geovelocity anomaly
  • IP reputation
  • IP velocity
  • New device
  • User velocity
  • User-based risk behavior (UEBA - individual user)
  • User location anomaly

  The scores assigned to the various predictors in the default risk policy are not uniform. The risk predictors that are not related to the detected IP are given a higher score because they are a better indication of serious risk.

  You can also create custom risk predictors that analyze data that you provide. For more information, see Risk predictors

  Note: The default risk policy includes a New Device predictor. To have this predictor included in the actual risk evaluation, your authentication flow must provide information that can be used to identify individual devices. The best way to do this is to bring the information from the PingOne Risk SDK. This can also be done by providing a persistent cookie as input.
• For each predictor type included, whether you want to use the default predictor or one that you have customized

  Predictors can be customized on the Predictors page.

• The method to use to adjust the degree to which each included predictor should be taken into account when calculating the overall risk score
  There are two methods of combining the predictors (controlled with the switch at the top of the page):

  Weights

  When you use the weights approach, you are determining relative weights that should be used when calculating the individual risk score for each predictor.

  Scores

  When you use the Scores approach, you can exercise more control over the overall calculation because you can specify an exact numerical score that should be assigned when PingOne Risk determines that there is a medium or high risk level for a predictor.

• The specific weight or score that should be assigned to each of the predictors included in the policy

  This is relevant for both the weights and scores approaches, although the UI differs slightly between them.

• How the aggregated risk score that was calculated should be translated into a final risk level

  Controls are provided on the Risk Policies page to map the aggregated risk score to the three categories that represent the final result of the risk analysis: low, medium, and high.

• Whether or not to use overrides

  You can define overrides that assign a specific final risk level (low, medium, or high) based on a specific criterion, regardless of what the overall calculated risk score was. For example, you can define an override that states that if a geovelocity anomaly is detected, the final risk evaluation should be High, regardless of what the overall risk calculation score was.

  Note:

  If you enter text in the Note field for overrides, the text will be returned in the API response.

Staging policies

To test risk policy changes before actually putting them into production, you can create a staging policy that is associated with the risk policy that you are currently using.

When an evaluation event occurs for the production risk policy, the incoming risk data is also passed through the staging policy affiliated with the production policy, creating two sets of risk evaluation data, one for the production policy and one for its associated staging policy.

To create a staging policy, click the More Options (⋮) icon for the policy, and select Create staging policy. A policy editing window is displayed, and you can make the changes that you want to test.

Staging policies are set to expire after 3 months, and the expiration date is displayed alongside the risk policy name.

When a staging policy expires, incoming risk data is no longer passed through the staging policy for evaluation.

To promote the staging policy configuration to production, click the More Options (⋮) icon for the policy, and select Promote to production. When you promote the staging configuration to production:

• The settings in the staging policy are copied to production and replace the production policy settings. The policy name and ID remain the same.
• The staging policy is unlinked from the production policy and remains in the Risk Policies list.

Note:

A staging policy can be promoted to production even if it has expired, as long as it is still linked to the production policy.

To unlink a staging policy without promoting it to production, click the More Options (⋮) icon and select Unlink. The link to the associated policy is removed, and the staging policy changes to a regular risk policy.