# Customizing Checks ## Overview Each organization has a unique way of working - from different user onboarding/offboarding processes to tailor-made security policies and risk tolerances to approved workplace tools. What may be very concerning behavior to one company may be typical behavior for another, because of industry, size, maturity level, past experience, etc. \ \ Identity Intelligence knows that identity security does not have a 'one-size fits all' solution, which is why most checks can be tuned and customized to better align to your organization's way of working so you can focus on what matters most to your team. On the right hand side of the Check Results page, next to the Check Details block, you will find a **Check Settings** block, that is collapsed by default. Click the down-arrow in the top right of this widget to expand it so that you can review or modify the check's settings. This article will describe the different types of check settings available, and how you can best utilize them.
### **Custom Detection Settings** Many checks in Identity Intelligence can be tuned via the **Custom Detection Settings** to better align with your organization's risk tolerance, policies, and/or procedures. These settings could be numerical values that you increase or decrease to make the check evaluation criteria more or less strict, or it could be toggles to include or exclude event types, groups of known IP addresses, etc. All custom detection settings will have a default value configured that can be modified as needed. To change a check's settings: 1. Open the Check Settings widget by selecting the down arrow to expand the widget 2. Select the **Edit** button in the **Custom Detection Settings** section of the Check Settings widget to open a settings modal where you can make the desired changes 1. **Note**: If this section does not exist, it means the check does not have configurable settings available 3. Once you are done, select **Save changes** within the modal. The modal will then close
If you would ever like to revert back to the default settings - follow Steps 1 and 2 above. From within the settings modal, select the **Restore Default** button and then select **Save changes** ### List Settings Like Custom Detection Settings, **List Settings** should be used to better align check detections to your organization's risk tolerance, policies, and/or procedure based on what is and isn't allowed. There are several checks in Identity Intelligence that have the option to configure List Settings. All List Settings work as allow or block lists, although they are sometimes called differently (e.g: Ignore List, Include list, etc). What can be added to an allow or block list will vary depending on the context of the check. For example, in some checks you can allow or block specific countries, whereas in other checks you may be able to allow or block certain applications, domains, etc.\ \ Many checks have a default allow and/or block list that can be modified as needed. If two list options are visible on a check (Allow/Block, Include/Exclude, etc), Identity Intelligence can only use one of the two options to impact the detection logic (ie: cannot allow certain items AND block other items). To modify the list: 1. Open the Check Settings widget by selecting the down arrow to expand the widget. \ If a List already has values configured, you will see a count of values under the List name (ie: 10 items). Select the down arrow next to the count of items to see what values are already configured \ **Note**: If this section does not exist, it means the check does not have configurable list settings available 2. Select the **Edit** button in the **List Setting** section of the Check Settings widget to open the list where you can make changes. \ **Note**: If there is more than one List type available (ie: Allow **and** Block), be sure to select the **Edit b**utton that corresponds to the section you would like to modify. Remember that Identity Intelligence can only use **one** list so make sure there are only settings configured under one of the 2 list types 3. To add a new item to a list, select the **Add** button to open a modal where you can either select from a dropdown of existing options, or enter free text values 4. To remove an existing item from a list, find the item you'd like to remove within the list and select the **Garbage** can icon next to the given value 5. Once you are done making changes to a given list, select **Save**. You can only edit one list type at a time, so if needed - navigate to the next list type to make any changes in the same way If custom items have been added to a list, these will be denoted with an icon and a tooltip (visible on hover) as shown in the screenshots below. If an item does not have an icon, this indicate that this item was part of the default settings. If an admin removes a a default item, and manually re-adds it, it will also appear as a custom setting. {% columns %} {% column width="50%" %}
{% endcolumn %} {% column width="50%" %}
{% endcolumn %} {% endcolumns %} If you would ever like to revert back to the default settings - follow Steps 1 and 2 above, select the **Restore Default** button and then select **Save.**
### **Why does the number of failing users stay the same after I change a check's settings?** When you modify a check's custom detection settings or list settings, the user failure results for the check will not update immediately. When the tenant's next data collection runs, the results for most checks will update automatically. If needed, you can trigger a manual data collection for each integration on the **Integrations** page to see updated results for [state based checks](/understanding-check-failures.md#different-types-of-checks). You may also notice after making a change to the custom detection or list settings of event based checks, that there are still users failing based on previous check settings. This is because of Identity Intelligence's data processing mechanisms and because users failing event based checks will continue to fail for 7 days, until no new observations are noted. If there are users failing a check based on previous settings, and not new settings, you can remove these users from the list with the [Mark as normal behavior triage action](/understanding-your-users/remediation-actions.md#mark-as-interesting-mark-as-normal-behavior). ### Notification Settings Every check in Identity Intelligence will have a **Notification Settings** area in the Check Settings widget. We highly recommend utilizing check notifications to closely monitor the user failures for the checks that are most critical to your organization to ensure that you are not missing anything critical, and so that you do not need to log into the Identity Intelligence platform daily to review new check failures. Advice on how to adopt and incorporate Notifications can be found below, under the [Best Practices for Notifications](#best-practices-for-notifications) header
Once you have configured at least one [notification target](/integrations.md#notification-targets), you can use the notification settings to **Send failure reports to** the desired notification target by selecting your desired notification target. You can select more than one notification target for a given check if needed. Certain checks can also be configured to **Send direct messages on failures** to end users, and/or end user managers (if manager data is available). If you do not see an area to **Send direct messages on failures** in the Notifications Settings section, it means this functionality is not available for the given check. \ \ Use the **Customize messages** button to open a modal where you can write custom check descriptions or recommended actions that will be included in the admin notifications, or custom messages to send to failing end users and/or managers. You can also use this modal to **Test** both notification types to ensure that your custom message looks and works as intended.
#### **Best Practices for Notifications** Notification targets should be configured based on where you and your team work together - whether that be shared channels in Slack, Webex, Teams or distribution lists via email. When first starting out with Identity Intelligence, we highly recommend setting up failure report notifications for a small handful of checks *only* to start (3-5 checks), so that you and your team can get used to receiving the alerts, get comfortable with the amount of alerts sent, and start developing investigation and/or mitigation operationalization processes for the check failure reports. Once you are comfortable, you can begin to add notification targets to additional checks where needed. \ \ Typically, we also recommend starting with notifications for [Threat based checks](/understanding-check-failures.md#different-types-of-checks) that your organization is concerned about and would like to monitor/investigate failures regularly. \ If there are [Posture based checks](/understanding-check-failures.md#different-types-of-checks) you are interested in monitoring - be sure that the number of currently failing users is reasonable and actionable before configuring notification settings or you will overwhelm yourself with alerts. For example, if you have 200 users failing the `Inactive Users` check, we'd first recommend cleaning up these users as much as possible (ideally 10-20 users still failing). Once there are only a few users left failing the check, only should you turn on the notifications for this check to ensure that the number of failing users does not slowly increase to a point where clean up needs to become a bigger project. If you would like to utilize end user notifications, be sure to inform end users/managers that they may be receiving these alerts and where they can find out more information or support if needed. If you would like these notifications to come from your own domain, which can reduce some end user confusion, you can do so with our [Mailgun](/integrations/mailgun-integration.md) or [SendGrid ](/integrations/sendgrid-integration.md)integrations. ### Disable checks If there are checks that your organization does not care about, you can "turn off", or disable, the check entirely to stop evaluating all users against this check. The **Disable Check** toggle can be found in two places: * The Check results page, right next to the check name * The Failing Checks page, in the furthest right column of each row To disable a check, switch the toggle to **Disable.** Once a check is disabled, the toggle will be grey. To enable a check, switch the toggle to **Enable.** Once a check is enabled, the toggle will be blue. Disabling or enabling a check will go into effect immediately.
### Unprotected users failing Another way you can adjust checks is through the [**Protected Population**](/oort-tenant-settings-overview.md#protected-population). This is a drastic measure, as adjusting the groups that are or are not included in the Protected Population will impact **ALL** of your checks. By default, tenants do not have a protected population configured. Click the link above to read our documentation about setting and modifying your protected population. You can see how many unprotected users are failing a specific check in a widget on the left of the Check Results page. This data can be useful to determine if your protected population may be configured in way that is leading to unintended results.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.oort.io/understanding-check-failures/customizing-checks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.