Reviewing risk evaluations - PingOne - PingOne Services - PingOne Cloud Platform

PingOne Cloud Platform
bundle
pingone
ft:publication_title
PingOne Cloud Platform
Product_Version_ce
PingOne
PingOne Cloud Platform
category
Administratorguide
ContentType
Guide
Product
Productdocumentation
p1
p1cloudplatform
ContentType_ce
Guide
Guide > Administrator Guide
Product documentation

Depending on your organization’s goals and use cases, you should review and analyze risk evaluations to fine-tune your risk policy.

To review a risk evaluation:

  1. View a risk evaluation.
    • Using the API: To create a risk evaluation, see the PingOne Protect API documentation.
    • Using the PingOne admin console:
      1. In the PingOne admin console, go to Monitoring > Audit.
      2. Edit the Time Range and Within fields as needed.
      3. For Filter Type, select Event Type.
      4. For Filter, select Risk Evaluation Created and Risk Evaluation Updated.
        Note:

        You can enter risk in the Search Filter Type field to view only risk-related event types.

        For more information, see Event types.

        A screen capture of the Audit Parameters page with "risk" entered in the Filter field.
      5. Click Run.
      6. To view the specific data and scores from an event, click View in the Details column in the report summary.

    The following is an example response result from a risk evaluation:

    "result": {
	"level": "HIGH",
	"score": 80.0,
	"source": "AGGREGATED_SCORES",
	"recommendedAction": "BOT_MITIGATION",
	"type": "VALUE"
}
  2. In the response result section, review the following attributes in this order:
    1. result.recommendedAction: BOT_MITIGATION

      If this attribute is included in the result, a bot was detected, and your policy’s risk level returned HIGH. In this case, you should halt the user flow or route the user to an additional bot mitigation tool.

      Note:

      Make sure to set the bot detection predictor score higher than the overall High risk threshold in the risk policy. If the bot detection predictor score is not set higher than the High risk threshold, the risk policy result will not include the recommendedAction: BOT_MITIGATION attribute. Using this attribute allows you to test your risk policy or control the response from the risk policy instead of modifying the flow or code at the app level.

    2. result.value

      This attribute is included in the result when a risk policy has an override configured, and the Notes field of the override rule has free text entered.

      Check the value returned in the result against the Notes text entered in the override rule. If you don’t use overrides for blocking events, you do not need to check this attribute.

      A screen capture of the Add Override panel.
    3. result.level

      This attribute is always included in the response as one of three levels and affects the user flow as follows:

      • LOW: Continue the user flow without additional friction.
      • MEDIUM: Challenge the user with multi-factor authentication (MFA)multi-factor authentication (MFA)MFA An electronic authentication method where a user is granted access only after presenting two or more verification factors for authentication..

        You can decide to continue the user flow without challenging the user, depending on your use case, the user flow type, and how your risk policy is configured.

      • HIGH: Challenge the user with restrictive MFA.

        The specific method you employ to challenge the user in a high-risk event depends on your use case and the type of MFA available to your users. It is not recommended to use the standard push MFA mechanism or block the user in this case.

    4. result.score

      This numeric attribute is tied to result.level and can be used instead of or in conjunction with result.level for additional granularity.

      Example 1: You might decide to block based on the risk score, such as if result.score is greater than 250. Before making such a decision, review the Protect dashboard production data to see how your risk policy is currently performing.

      Note:

      If you want to block based on risk scores, check result.score before result.level.

      The following is an example user flow using result.score in conjunction with result.level:

      • If result.score is greater than 300, then block.
      • If result.level is HIGH, then restrictive challenge with MFA, such as with one-time passcode (OTP)one-time passcode (OTP)OTP A passcode valid for only one sign on or transaction on a computer system or other digital device. Also known as a one-time password, one-time PIN, or dynamic password. or FIDOFIDO (Fast IDentity Online) A set of open technical specifications developed by the FIDO Alliance for strong authentication..
      • If result.level is MEDIUM, then challenge with MFA.
      • If result.level is LOW, then allow.
  3. Analyze the response results to determine if the desired outcome occurs for various events and risk levels.

After reviewing risk evaluations, you might need to fine-tune your risk policy, including how the various predictors are configured, the weights or scores assigned to the predictors, any override rules, and how the thresholds for the final risk level are set.

You can also create a staging policy to test changes to your risk policy before putting them into production. For more information, see Creating and managing staging policies.