Custom policy

Traceable's Custom policy provides you the ability to create policies for granular control on API protection strategy. The various custom policies provide an effective way to build a zero trust policy to protect your data from misuse. You can configure policies to protect your APIs based on the source of the traffic, specific patterns in the traffic, 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 custom rules you have created 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 that the API can receive within a given period of time. After the limit is reached, the policy rejects all requests, thereby avoiding any additional load on the backend API.
  
• Data access - The data access 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 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, data access 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 have a higher property than blocking rules:

Malicious Behavior

You can configure a custom policy to protect your APIs from Traceable detected known malicious sources such as suspicious users, IP addresses with poor reputation, sanctioned countries, Tor and so on. Click on Malicious Behavior 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 a certain set of 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 the environments, or you can have a policy for all environment which is based on IP types. Click on Next when you have completed setting the criteria.

Step 2 - Configure the action

Traceable provides the following three options for the action you can take for 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 request only from the configured IP address(s) or the region.
• 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 decide to configure the Severity of the generated event from low, medium, high, and 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 during the review, you wish to edit any criteria, you can do so by clicking on 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 Custom signatures tab after clicking on Add Policy to start creating a custom signature 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 go through a process of verifying your custom signature rule, observing the generated events, and finally using 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 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 during the review, you wish to edit any criteria, you can do so by clicking on 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 defines how you choose different source 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 email domain. All requests coming from email domain matching the regex would be allowed or blocked as per conditions of access policy.
    
  • User ID (optional) - You can pick one or more user IDs to whom this policy should apply. Alternatively, you can specify a regex for user ID. For example, you can specify a domain name (abc.com) in the regex such that all the users coming 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
    • Data center
    • 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 that is calculated based on the number of days that you have configured. By default, the baseline is calculated based on the traffic received in the past one day. You can have both, the static and dynamic conditions work together. For example, you would use the static condition in case of account take over, 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 - This means that if a user exceeds the set limit for an API Endpoint, then the chosen action would 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 access

A data access policy allows you granular control over data access. A data access 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 data access policy gives 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 on how to use data access 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. The goal of an enumeration attack is 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. For more information on Datasets and Data types in the attributes section, see the Data Classification topic.

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 or credit cards numbers or other type 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

The actions that you can take when a rule is triggered are the same as explained in the rate-limiting section.