Custom policy

Traceable's Custom policy provides you the ability to create policies for granular control on API protection strategy. The various custom policies effectively build a zero-trust policy to protect your data from misuse. You can configure policies to protect your APIs based on the traffic's source, specific traffic patterns, whether it is carrying any sensitive data, or the rate at which the API is being accessed. The Custom Policy is separated into the following categories: 

• Malicious Source – Configure custom policies to protect your APIs from known malicious sources such as suspicious users, Traceable detected, IPs with poor reputation, sanctioned countries, Tor and so on. 

• Custom Signatures – Configure additional custom rules based on patterns that you would like to be used in detection. This feature is especially useful if you are migrating to Traceable from a legacy WAF and have created custom rules that you would like to continue using. The rules can be configured for detection and blocking (optional).

• Rate Limiting - The rate-limiting policy enables you to control the incoming traffic to an API by limiting the number of requests the API can receive within a given period. After the limit is reached, the policy rejects all requests, thereby avoiding any additional load on the backend API.

• Data Loss Prevention (DLP) - The DLP policy enables you to control access patterns for sensitive data to an API within a given period of time. Sensitive data access is tracked per source type for sensitive data sets and types for specified APIs. After the data access limit is reached, the policy rejects all requests by that user, thereby avoiding any exfiltrating attempts of sensitive data.

• Enumeration - The Enumeration policy enables you to look for specific data in request parameters, path parameters, or sensitive data being enumerated within a given period of time. This can be used for credential stuffing attempts, gift card fraud, and so on by selecting relevant APIs. After the limit is reached, the policy rejects all requests, thereby protecting the API from enumeration-based attacks.

The following sections detail each type of custom policy. Navigate to Protection → Settings → Custom Policy and click on a tab to create the required policy. Creating any policy involves the following three steps:

1. Select the custom policy's criteria.

2. Configure the action to be taken.

3. Review the policy and save.

Blocking or allowing priority

Traceable follows a priority for blocking or allowing user requests. It is recommended to understand this priority list as it would help in configuring the policies with the correct set of options. In Traceable, a threat actor can be blocked by manually moving it to deny or suspend list, by rate-limiting policies, DLP policies, enumeration policies, malicious source policies, or auto-blocking. In case of a conflict, the following order of blocking preference is followed in descending order. Allow rules to have a higher property than blocking rules:

IP address allowlist

Make a note of the following when you create custom policies. If you are going to create a Malicious source policy of the type IP range with Allow action, then:

• If you have other policies with an action to block requests, then the Allow action of Malicious source policy overrides, and no request is blocked.

• If you have configured rate limiting, DLP, and enumeration policies with a block or alert action, then the Allow action of Malicious source policy overrides, and no request is blocked, nor are any alerts sent.

The above-mentioned Malicious source policy configuration has no effect on Custom signature policies. The Out-of-the-box detections that is, the detections enabled from Protection → Settings → Detection policy, would continue to happen. If you wish to allow IP addresses from such detection, click on the Exclusions tab to create an exclusions rule.

Malicious Sources

You can configure a custom policy to protect your APIs from Traceable-detected malicious sources, such as suspicious users, IP addresses with poor reputations, sanctioned countries, Tor, and so on. Click on the Malicious Sources tab to start creating a policy. 

Step 1 - Set the criteria

As part of step 1, decide whether you want to create a policy based on:

• IP range  - An IP address or a range of IP addresses.

• Region - Based on a region. 

• Emails - Choose at least one option from emails that are sent from a disposable domain or emails that have been part of data leaks. You can also specify a regular expression to match certain email addresses. Make sure that you hit the Enter button after you have added the regular expression. Emails can also be identified based on the email fraud score of high or critical.

• IP type - Choose one or more than one type of IP address to create a policy based on IP type. You can choose from:

  • Anonymous VPN

  • Hosting provider

  • Public proxy

  • Tor exit node

  • Bot

You can create multiple policies for the same environment, each with a different criterion. For example, you can decide to block the Afghanistan region across all environments or have a policy based on IP types for all environments. Click on Next when you have completed setting the criteria.

Step 2 - Configure the action

Traceable provides the following three options for action regarding the event generated by the custom policy: 

• Block request – Choose this option if you want to block all the requests from the configured IP address(s) or region.

• Block all, except this – Choose this option if you wish to allow requests only from the configured IP address(s) or the region.

  Note

  Traceable allows only one custom policy per source criteria, one for IP range and one for region for Block all, except this action.

• Alert only, no blocking – Choose this option if you wish to be only alerted when a request matches the configured criteria. In this case, no requests are blocked.

You can also configure the severity of the generated event from low, medium, high, or critical. Select the time for which the rule should apply and click on Next.

The following table lists the different action options available for each criterion.

Step 3 - Review and Submit

In the final step, review and submit the policy. If you wish to edit any criteria during the review, click the edit button, as shown in the screenshot below.

Custom signatures

You can configure custom signatures that you can use in detection.  The custom signature rule helps in fine-tuning the protection strategy by having granular control over the types of events generated and requests blocked. These rules apply globally to all the APIs. You can create custom rules for different parts of a request and response, for example:

• URL 

• Header name and value 

• Parameter name and value 

• HTTP method 

• User-agent 

• Host

• Header

• Body
  

• Parameter

Click on the Custom Signatures tab to create a custom signature policy after clicking Add Policy.

Step 1 - Set the criteria

You can create a custom signature rule on one or more than one part of the request. Traceable provides different preset operations for each part of the request. For example, if you choose to create a rule on URL, you can have a rule with any one of the following operations:

• Matches exactly

• Does not match exactly

• Contains string

• Does not contain a string

• Matches pattern

• Does not match a pattern

You can also decide to add more conditions in the same rule for different or the same parts of the request. For example, you can create a custom rule with a condition on a URL and header name and value. Traceable carries out an AND operation on all the conditions defined in the rule.

Step 2 - Configure the action

Traceable provides the following options for the action you can take for the event generated by the custom signature rule. The options let you verify your custom signature rule, observe the generated events, and finally use them to block the requests.

• Block requests – Use this option to block requests based on the criteria that you have set.

• Allow requests – Use this option to allow requests based on the criteria that you have set. For example, in the above screenshot, if the request does not match the pattern, that is, the request has HTTP methods besides GET, PUT, or POST, then allow such requests.

• Alert only, no blocking – Use this option to only generate an alert.

• Mark for testing – Use this option when you want to test your custom signature rule before applying it to production data.  All the generated events are of low severity, and Traceable does not generate any notifications for such events (if such events violate any configured rule). You can view the testing events by navigating to Protection → Threat Activity and applying the Show Testing filter as shown below.

  

Step 3 - Review and Submit

In the final step, review and submit the policy. If you wish to edit any criteria during the review, click the edit button, as shown in the screenshot below.

Rate limiting

Rate limiting an API protects the API Endpoints and other services from brute-force attacks. You can create multiple rules based on your requirements or add multiple criteria to the same rule. 

Step 1 - Set criteria

The criteria define how you choose different sources and attributes based on which rate-limiting policy is created.  You can select one or more than one API to which the rule would apply. Or, you can select a label. When you select a label, the rule applies to all the APIs on which the label is applied. Following is a list of different configuration options to create a data protection or zero trust policy:

• Environment - Environment(s) to which the policy applies.

• Source

  • IP addresses (optional) - IP addresses that should be part of the data protection policy.

  • IP type(optional) - Type of IP address to monitor using the policy:

    • Hosting provider

    • Public proxy

    • Anonymous VPN

    • Tor exit node

    • Bot

  • Regex for email (optional) - You can add a regular expression to match the email domain. All requests from email domains matching the regex would be allowed or blocked per the access policy's conditions.
    

  • User ID (optional) - You can pick one or more user IDs to whom this policy should apply. Alternatively, you can specify a regex for the user ID. For example, you can specify a domain name (abc.com) in the regex so that all the users from this domain would have access to data as defined in the policy. This is a way to enforce your zero-trust policy.

  • Regex for user agent (optional) - You can add a regular expression to capture a specific set of user agents. For example, you can have a regex that allows data access from a specific browser.

  • Connection type (optional) - Select the type of connection from where you would like to allow data access. You can choose one or more than one type of connection type from:

    • Residential

    • Mobile

    • Corporate

    • Datacenter

    • Education

  • Minimum IP reputation (optional) - Choose the type of IP address based on their reputation from where you would allow data access.

  • Region (optional)  - The countries to be monitored.

• Attributes - Data sets or data types to be monitored, for example, a few of the inbuilt data sets like GDPR, HIPAA, AWS Auth, Azure Auth, GCP Auth, and so on.

• Target: The API endpoints that need to be monitored as part of the policy. When you click on Add Endpoints, the entire catalog of APIs is presented to you. You can choose the API endpoints that you want to be part of the policy. 

Step 2 - Configure action

To complete the rate-limiting policy, you need to set static or dynamic rate-limiting rules. These rules define the numerical limits after which the rule triggers. Dynamic conditions help you adjust the rate limit intelligently based on the baseline traffic calculated based on the number of days you have configured. The baseline is calculated by default based on the traffic received in the past day. You can have both the static and dynamic conditions work together. For example, you would use the static condition in case of an account takeover, where you would want to block the access immediately. 

The static compute condition for the numerical value is a combination of whether the value applies to:

• Per user and per selected endpoint: If a user exceeds the set limit for an API endpoint, then the chosen action will be implemented.

• Per user across all the selected API Endpoints - This means that if a user violates a rule, then the rule is applied across all the endpoints for that user.

• Total requests across all users for an API Endpoint - This means that if you have set a limit of 100 requests in 1 minute. For example, if there are 5 users and if each user sends 20 or more requests in a minute, then access to the API Endpoint would be blocked or allowed as per the chosen action.

• Total requests across all users across all the selected API Endpoints - The rule would trigger if all the users cumulatively exceed the set limit across all the selected API Endpoints.

Step 3 - Configure actions

Configure the severity of the generated event when a rule is triggered. These events can be of low, medium, high, or critical severity. Finally, you need to configure the action that you wish to take when a rule is triggered. You can take the following three actions:

• Block the user indefinitely

• Block the user for a limited period of time

• Send an alert that the rule was triggered; however, do not block the user.

Data Loss Prevention (DLP)

A DLP policy allows you granular control over data access. A DLP policy or a zero trust policy can define who can access data, what kind of data can be accessed, and at what rate the data can be accessed, among many other options. The DLP policy provides many granular options to configure, for example, source of traffic, IP addresses, type of IP (bot, VPN, and so on), user ID, region, attributes, and so on. A detailed explanation of how to use the DLP policy is available in the Data protection topic.

Enumeration

Enumeration attacks are a type of cyberattack that involves systematically probing a network or system to identify and gather information about potential targets for further exploitation. An enumeration attack aims to obtain a comprehensive list of network resources, user accounts, and other sensitive information that can be used to launch further attacks or gain unauthorized access.

Step 1 - Set the criteria

Set the criteria for enumeration policy by configuring the source, attributes, and API endpoints section. The source, attributes, and API endpoint options are similar, as explained in the rate-limiting policy section. See the Data Classification topic for more information on Datasets and Data types in the attributes section.

Step 2 - Configure the conditions

Set the conditions for the policy by configuring a unique number of values for rate-limiting conditions. A unique value, for example, would be a user trying different social security numbers, credit card numbers, or other types of data within a set time duration. You can configure such unique values for sensitive parameters, request body, or path parameters.

Step 3 - Configure action

As explained in the rate-limiting section, you can take the same actions when a rule is triggered.