> This page is for Applications Protection.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.humansecurity.com/llms.txt.

# Create Account policy rules

You can create Sightline policy rules from the **Policy Rules** page. Policy rules let you dictate specific logic and conditions to fully control how Sightline handles account takeover or fake account attacks on your application. You can also configure **actions** in a Policy Rule, which are measures Sightline takes after it detects an attack that matches your rule’s conditions. These include adding the attack to the dashboard, sending notifications to your team, or sending mitigating emails to your users.

You can learn how to create policy rules in this article.

## Prerequisites

* To create or make changes to policy rules, you need at least an **Admin** role.
* Certain **actions** need additional setup to work with Policy Rules. See [Custom action settings](/applications/mitigation-actions) for more information.

## Create custom policy rules

To make a new rule:

1. Navigate to **Sightline Cyberfraud Defense > Policies > Account Policies.**
2. Click **Create new rule.**
3. Choose the type of rule you’d like to create. You can create a rule for a single or network attack for Account Takeover or Fake Account attack types.
4. Enter a **Name** and **Description** for your rule, then select **Next.** This opens a new **Rule structure** panel with a **Conditions** and **Actions** menu.
5. Select the **Conditions** menu. Then, click and drag the first condition you want to use into the **IF > THIS()** field.

> **Note**
>
> The **Attack Patterns** condition refers to specific attack scenarios identified by Sightline that you can target. Available Patterns are based off of your sensitive routes and unique use cases. See [Risk Triggers & Attack Patterns](/applications/risk-triggers-and-attack-patterns) for more information.

6. Complete the logic for that condition by selecting an **operator,** such as **in, is, exists,** or **does not exist,** and a **value**.
7. If you want to add **nested conditions** to work with the one you just created, then repeat **Steps 5 and 6** for each condition. Be sure to also specify the **operator,** either **AND** or **OR,** on how the conditions will work together as well. Note that the chosen operator **persists** within the nested condition. In other words, you can’t have a second nested condition use OR and a third one use AND.
8. If you want to add an **entirely new** condition, select the at the top of the section or drag a new condition towards the bottom of the section.
9. Specify how this condition will work with your first condition with either the **AND** or **OR** operators. Note that the chosen operator **persists** through the rule. In other words, you can’t have a second condition use OR and a third one use AND.
10. Repeat **Steps 5-7** for the new condition.
11. Repeat **Steps 8-10** for any additional conditions you want to include.
12. After you’ve made all the conditions you need, select the **Actions** menu. Then, click and drag the action you want to take into the **THEN > THIS** field. You can have multiple actions per rule.
13. Select **Before Saving - Simulate rule** and specify a **rule priority**. See [About rule priorities](/applications/account-policies#about-rule-priorities) for more information on how they’re applied.
14. Select **Simulate rule.** The simulation tests your rule using seven days of past Sightline data.
15. Review the simulation data to make sure your new rule is behaving as you expected. See [About rule comparison](#about-rule-comparison) to learn more about this view.
16. Close the rule comparison and select how you’d like to save your rule. By default, it saves as a draft, but you can choose to activate it as soon as you save it as well.

![](/_fern-img/11b15aae8a4253804cbd09d45065790c27ec708e6d312a17f2890db27e9ba1b8.webp)

17. Select **Save changes.**

You have created your new rule. Depending on how you chose to save it, it will appear in either your **Active** or **Draft** tabs.

### About Rule Comparison

The **Rule Comparison** view appears when you **simulate a policy rule.** Sightline takes the new policy rule changes you’ve created and applies them to up to seven days of data from your application. This way, you can make sure the rule behaves the way that you expect and adjust your rule as needed.

#### Rule matches over time

The **Rule Matches Over Time** graph displays the **Activities** or **Accounts** from the previous seven days that match your policy rule’s conditions. If you’re updating an existing rule, it also compares the updated rule to the current one. This is useful for understanding the volume of activities or accounts that the rule will affect.

![](/_fern-img/a57309409a9becda06076ccf1e60585eb052feed20743a5292d629211cc2e26b.webp)

#### Rule’s comparable identifiers

The **Rule’s comparable identifiers** show the top 10 most prevalent identifiers for activity or accounts from the previous seven days that match your policy rule. If you’re updating an existing rule, it also compares the updated rule’s identifiers to the current rule’s. This is useful for understanding the characteristics of activities or accounts your rule will affect.

![](/_fern-img/5191b1748fd3c64a3ba08f1b0a68694baaa4a452ffb08bc14ac643cee972ac5f.webp)

The available identifiers are:

* **ASNs:** The most prevalent autonomous system numbers (ASNs) that activity or accounts originated from.
* **User Agents:** The most prevalent user agents that activity or accounts had.
* **Sensitive Endpoints:** The most prevalent sensitive endpoints that activity was active on.
* **Reputation - IP Classification:** The most prevalent IP classifications that activity or accounts originated from.
* **Active Days:** The length of time accounts were active for.
* **Age Distribution:** The length of time since the accounts were created.
* **Countries:** The most prevalent regions that activity or accounts originated from. Regions are indicated by [country ISO codes.](https://www.iso.org/obp/ui/#search)

### Example rule

Below is a sample rule and an explanation of its logic. You can reference this if you’re having trouble understanding how policy rule logic works.

![](/_fern-img/1e114b900a41151d322d11e4211d8bcd634e699220656ad3bd439f21a4704131.webp)

This shows an example account takeover policy rule. In this rule, there are two sets of nested conditions and three actions to take. This rule’s logic dictates that:

* If the account takeover is on an account withdrawal path **AND** comes from the IP address 1.1.1.1, **AND**
* If the account takeover has a risk score over 90 **OR** the account’s age is at least a day old,
* **THEN** Sightline will Add the account to the ATO Dashboard **AND** Send a Slack notification **AND** Disable that account.

The **actions** are straightforward: if an account takeover matches the listed conditions, then according to this rule, Sightline will take the actions listed above.

The **conditions** logic can be more complicated. Let’s start with the first set of conditions:

* The **path** condition tells Sightline to look for account takeovers that are on the listed paths. In this case, that is the **Account Withdrawal** path.
* The **IP address** condition tells Sightline to look for account takeovers that are from the listed IPs. In this case, 1.1.1.1.
* The **AND** between the two conditions means that, for this first set, Sightline will apply the chosen actions if detected account takeovers match **both** of the conditions.

**To sum it up:** the first set of nested conditions tells Sightline to take action if the account takeover is detected **exactly** on the **Account Withdrawal** path **and** if the takeover’s IP address is **exactly** 1.1.1.1. In other words, takeovers on the account withdrawal path but with an IP of 2.2.2.2 won’t have action taken on them, and neither will takeovers on a different path like account payments but with an IP of 1.1.1.1.

Next, let’s look at the second set of conditions:

* The **Risk score** condition tells Sightline to look for account takeover attempts where the risk score is **at least** 90.
* The **Account age** condition tells Sightline to look for account takeover attempts on accounts that are **at least** one day old.
* The **OR** between the two conditions means that, for this second set, Sightline will take the specified actions if it detects an account takeover that matches **at least one** of these conditions.

**To sum it up**: the second set of nested conditions tells Sightline to take action if it finds an account takeover attempt where the **risk score** is **at least** 90 **or** if the attempt is on an account that is **at least** one day old. For example, Sightline will take action on account takeover attempts that have a 95 risk score even if the account is only one hour old. Similarly, it will take action if the risk score is 55, but the takeover attempt was on an account that is 30 days old.

To put all the logic together, we need to consider the operator **AND()** between the two nested conditions. This **AND()** means that Sightline will take action on the account takeover attempt if it matches **both** of the nested conditions.