Custom Policy

Custom Signatures are signature-based attacks that operate on the traffic signature received from your application. You can configure a custom signature rule to help fine-tune your API protection strategy by having granular control over the event types generated and requests blocked. These rules apply globally to all the APIs. You can create custom rules for different components of a request and response, for example, header name and value, body, cookie, etc. You can also create these rules on one or more request components. Traceable provides different preset operations for each part of the request.

Navigate to the Custom Signatures tab and click + Add Rule in the tab’s top right corner to start creating a rule. The following demo shows how you can create a rule while the below steps describe each field during rule creation.

Step 1 — Set the criteria

As part of setting up the criteria, you must complete the following:

• Rule Name —  The name of the custom signature rule. Traceable shows the rule under the Custom Signatures tab using this name.

• (Optional) Description — Some basic information about the rule, for example, type of protection strategy it implements.

• Environment — The environment in which you want Traceable to apply the rule.

• Payload — The type of API component on which you want to apply the rule. You can create the rule based on the following:

  • Request/Response Criteria —

    • API interaction — The API interaction type(request or response) on which you want to apply the rule.

    • Component — One or more API components to create a rule, such as URL.

    • Operator — The type of comparison to evaluate the component against the specified value, such as Contains string.

    • Value — The value for the above component, for example, accounts.

  • Attribute — The metadata the Traceable agent provides after observing the API traffic.

    • Key — The operator and attribute name based on which Traceable should apply the rule. For example, operator as Matching exactly and key as authorization.

    • Value — The operator and value (if applicable) corresponding to the above key. By default, Traceable selects Any Values as the operator, however, you can select a different one from the drop-down and specify the value accordingly.

  • Sec Rule — Define security rules to analyze data passing through APIs. These rules are based on the OWASP ModSecurity CRS which helps detect and block malicious patterns in API traffic. By using this feature, you can create rules that match specific patterns or behaviors in the payload, enhancing API security and automatically blocking or alerting any suspicious activity. Traceable validates the Sec Rule during rule submission to ensure that it is valid for successful rule creation.

    Note

    • You can add one Sec Rule per custom signature rule.

    • A Sec Rule must contain the id field.

    • A Sec Rule that includes the msg field must also have the logdata field. Conversely, if the Sec Rule contains the logdata field, the msg field is optional. If the Sec Rule does not include the logdata field, the msg field should be omitted. This applies to all parent and child Sec Rule chains.

You can add one or more criteria for the same or different payloads. For example, you can set a criteria with one payload as request/response and the other as an attribute. Traceable carries out an AND operation on all the conditions defined in the rule.

Once you have set the above criteria, click Next.

Step 2 — Configure the action

As part of configuring the action, you must complete the following:

Note

The availability of the below options depends on the criteria you configure in Step 1 above.

• Event Handling — Traceable provides the following options on how the event generated by the custom signature rule should be handled. The options let you verify your custom signature rule, observe the generated events, and finally use them to block requests.

  • Block requests — Blocks all requests matching the criteria configured in Step 1 above.

  • Allow requests — Allows all requests matching the criteria configured in Step 1 above.

  • Monitor only, No blocking — Monitors the traffic matching the configured criteria. In this case, no requests are blocked.

  • Mark for testing — Test your custom signature rule before applying it to production data. All the events generated as part of the configured rule are of low severity, and Traceable does not generate any notifications for such events. You can view the testing events by navigating to the Protection → Threat Activity → Filter pane and applying the Testing filter under Status.

• Event Severity — Select the severity that Traceable should assign to the event generated by the Custom Signature rule.

  Note

  This option is available only when you select the Block requests or Monitor only, No blocking options.

• Blocking Applicability — Select the duration for which blocking should apply, Indefinitely or a specific duration.

  Note

  This option is available only when you select the Block requests or Allow Requests options.

• Data Injection — Add the header you wish to include in the request. You can use this data for monitoring where it can highlight an anomaly in the request.

  Note

  This option is available only when you select the Monitor only, No blocking or Mark for testing options.

Once you have configured the above, click Next.

Step 3 — Review and Submit

In the final step, review and submit the rule. If you wish to edit any criteria during the review, click the Edit () icon corresponding to a section.

You can configure a custom rate limiting rule to protect your applications from brute-force attacks. Using this rule, you can control the number of incoming requests from a user within a period. Traceable blocks that user as soon as the limit is exhausted.

Note

Traceable recommends that you configure the user attribution according to your requirements before setting up a rate limiting rule. For more information, see User Attribution.

Navigate to the Rate Limiting tab and click + Add Rule in the top right corner to start creating a rule. The following demo shows how you can create a rule while the steps below describe each field during rule creation.

Step 1 — Set the criteria

As part of setting up the criteria, you must complete the following:

• Rule Name —  The name of the rate limiting rule. Traceable shows the rule under the Rate Limiting tab using this name.

• (Optional) Description — Some basic information about the rule, for example, the type of threat it is blocking.

• Environment — The environment in which you want Traceable to apply the rule.

• Source — The source criteria on which you want to apply the rule. For example, IP Addresses → All External IPs.
  Traceable supports the following sources for creating a rate-limiting rule:

  • IP Address — Limit data from specific, internal, or external IPs.

  • IP Type — Control usage based on IP types, such as Anonymous VPN, Bot, Scanner, etc.

  • Email Domain — Limit requests from specific or a range of email domains, for example, ones belonging to a specific organization.

  • User ID — Manage traffic based on unique user IDs or regex for user IDs.

  • User Agent — Limit requests based on user-agent regex that indicates the type of client, such as a bot, or scripts making requests.

  • IP Organization — Manage traffic from specific entities known for spiking API request traffic.

  • IP ASN — Limit traffic from ASNs, which indicates the network provider from where the traffic originates.

  • Connection Type —  Control data incoming from a specific connection type, such as Corporate, or Data Center.

  • IP Abuse Velocity — Limit requests from IPs showing a high API abuse rate.

  • IP Reputation — Limit data coming from IPs having a poor reputation, such as the ones identified by threat intelligence.

  • Region — Enforce limits based on geographic regions, addressing location-based traffic patterns.

  • Scanner — Manage traffic coming from automated testing tools, such as Traceable’s AST, etc.

  Note

  All Sources except IP Abuse Velocity and IP Reputation have an Exclude check-box corresponding to their value field. When you select that check-box, Traceable applies the policy on all values except the ones you choose.

• Payload — The API component on which you want to apply the rule. You can create the rule based on the following:

  • Request/Response Criteria —

    • API interaction — The API interaction type (request or response) on which you want to apply the rule.

    • Component — One or more API components to create a rule, such as URL.

    • Operator — The type of comparison to evaluate the component against the specified value, such as Contains string.

    • Value — The value for the above component, for example, accounts.

  • Attribute — The metadata the Traceable agent provides after observing the API traffic.

    • Key — The operator and attribute name based on which Traceable should apply the rule. For example, operator as Matching exactly and key as authorization.

    • Value — The operator and value (if applicable) corresponding to the above key. By default, Traceable selects Any Values as the operator, however, you can select a different one from the drop-down and specify the value accordingly.

• Target — The API endpoints you want Traceable to monitor as part of the rule. You can select one or more APIs, or labels to which the rules should apply. The rule applies to all the underlying APIs when you select a label.

Once you have set the above criteria, click Next.

Step 2 — Configure the conditions

Traceable provides the following options for configuring policy conditions. These conditions define the numerical limits after which the rule triggers.

• Static Condition — The fixed values based on which Traceable should limit the API requests. This condition consists of the following parameters:

  • Access Exceed — The number of API requests after which Traceable should block the user. For example, 50 requests.

  • Time Range — The duration for which the limit should apply. For example, a 5-minute time range means the API(s) can receive up to 50 requests within this 5-minute window. Once this limit is reached, Traceable blocks the user.

  • Compute Condition — A combination of conditions on which the above limits should apply:

    • Per user and Per selected endpoints — If a user exceeds the above set limit for an API endpoint, Traceable implements the action you select in Step 3 below.

    • Per user and Across all selected endpoints — If a user exceeds the above set limit across all selected API endpoints, Traceable implements the action you select in Step 3 below.

    • By total requests across all users, and Per selected endpoints — If all users collectively exceed the above set limit for an API endpoint, Traceable implements the action you select in Step 3 below for all users. For example, you configure a rule to limit requests to 100 in 1 minute for an API. Then, if there are 5 users, and each user sends 20 or more requests per minute to that API, Traceable implements the action you select below.

    • By total requests across all users, and Across all selected endpoints — If all users collectively exceed the above set limit across all selected API endpoints, Traceable implements the action you select in Step 3 below for all users.

• Dynamic Condition — Adjust the rate limit intelligently based on the baseline traffic calculated according to the number of days you configure. Traceable calculates the baseline by default according to the traffic received by an API in the past day. This condition consists of the following parameters:

  • Access rate exceeds mean by — The percentage of requests exceeding the baseline after which Traceable should block the user. For example, 20%.

  • Time Range — The duration for which the rate limit should apply. For example, a 5-minute time range and 100 baseline value means that the API can receive up to 120 requests within this 5-minute window. Once this limit is reached, Traceable blocks the user.

  • Time Range (Baseline) — The period over which Traceable should calculate the baseline value. For example, a 5-day time range means that the mean value is derived from the ratio of the total number of calls to an API endpoint to the total number of unique users accessing that API within the 5 days.

You can have one or more static and dynamic conditions working together. For example, you can use the static condition to limit requests to 1000 per hour and use the dynamic condition to prevent sudden traffic spikes, ensuring steady API usage along with attack prevention.

Step 3 — Configure actions

As part of configuring the action, you must complete the following:

Note

The availability of the below options depend on the configurations in the above steps.

• Event Handling — Traceable provides the following options on how the event generated by the rate limiting rule should be handled. The options let you verify your rule, observe the generated events, and finally use them to block requests, as required.

  • Block —

    • Block the user indefinitely — If a user meets the above criteria, Traceable blocks them indefinitely, preventing any further API requests.

    • Block for a period of time — If a user meets the above criteria, Traceable blocks them from making API requests for the duration you define.

    • Block user for a duration that matches the conditions — If a user meets the above criteria, Traceable blocks them from making API requests for the time range defined in the Step 2 above.

  • Do not block, monitor only — If a user meets the above criteria, Traceable does not block them, but monitors it indefinitely.

  • Mark for Testing — Test your rate limiting rule before applying it to production data. All the events generated as part of the configured rule are of low severity, and Traceable does not generate any notifications for such events. You can view the testing events by navigating to the Protection → Threat Activity → Filter pane and applying the Testing filter under Status.

• Event Severity — Select the severity that Traceable should assign to the event generated by the Rate Limiting rule.

  Note

  This option is available for all options except Mark for Testing above.

• Data Injection — Add the header you wish to include in the request. You can use this data for monitoring where it can highlight an anomaly in the request.

  Note

  This option is available only when you select the Do not block, monitor only or Mark for Testing options above.

Once you have configured the above, click Next.

Step 4 — Review and Submit

In the final step, review and submit the rule. If you wish to edit any criteria during the review, click the Edit () icon corresponding to a section.

A DLP rule allows you granular control over data access. A DLP rule or a zero trust rule 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 rule provides many granular options to configure, for example, source of traffic, IP addresses, IP type (bot, VPN, and so on), user ID, region, attributes, and so on.

For the steps to create a DLP rule, see Data Protection.

You can configure an enumeration rule to prevent enumeration attacks and block systematic probing of sensitive data by monitoring the API activity. It helps prevent data leaks and unauthorized access to credentials.

Navigate to the Enumeration tab and click + Add Rule in the tab’s top right corner to start creating a rule. The following demo shows how you can create a rule while the below steps describe each field during rule creation.

Step 1 — Set the criteria

As part of setting up the criteria, you must complete the following:

• Rule Name —  The name of the enumeration rule. Traceable shows the rule under the Enumeration tab using this name.

• (Optional) Description — Some basic information about the rule, for example, the type of threat it is blocking.

• Environment — The environment in which you want Traceable to apply the rule.

• Source — The source criteria on which you want to apply the rule. For example, Region → Afghanistan.

  Traceable supports the following sources for creating an enumeration rule:

  • IP Address — Limit data from specific, internal, or external IPs.

  • IP Type — Control usage based on IP types, such as Anonymous VPN, Bot, Scanner, etc.

  • Email Domain — Limit requests from specific or a range of email domains, for example, ones belonging to a specific organization.

  • User ID — Manage traffic based on unique user IDs or regex for user IDs.

  • User Agent — Limit requests based on user-agent regex that indicates the type of client, such as a bot, or scripts making requests.

  • IP Organization — Manage traffic from specific entities known for spiking API request traffic.

  • IP ASN — Limit traffic from ASNs, which indicates the network provider from where the traffic originates.

  • Connection Type —  Control data incoming from a specific connection type, such as Corporate, or Data Center.

  • IP Abuse Velocity — Limit requests from IPs showing a high API abuse rate.

  • IP Reputation — Limit data coming from IPs having a poor reputation, such as the ones identified by threat intelligence.

  • Scanner — Manage traffic coming from automated testing tools, such as Traceable’s AST, etc.

  • Region — Enforce limits based on geographic regions, addressing location-based traffic patterns.

  Note

  All Sources except IP Abuse Velocity and IP Reputation have an Exclude check-box corresponding to their value field. When you select that check-box, Traceable applies the policy on all values except the ones you choose.

• Payload — The API component on which you want to apply the rule. You can create the rule based on the following:

  • Request/Response Criteria —

    • API interaction — The API interaction type(request or response) on which you want to apply the rule.

    • Component — One or more API components to create a rule, such as URL.

    • Operator — The type of comparison to evaluate the component against the specified value, such as Contains string.

    • Value — The value for the above component, for example, accounts.

  • Attribute — The metadata the Traceable agent provides after observing the API traffic.

    • Key — The operator and attribute name based on which Traceable should apply the rule. For example, operator as Matching exactly and key as authorization.

    • Value — The operator and value (if applicable) corresponding to the above key. By default, Traceable selects Any Values as the operator, however, you can select a different one from the drop-down and specify the value accordingly.

  • Data Sets/Data Types —

    • Data Location — The location at which Traceable can find the datatype or dataset.

    • Datasets/Datatypes — The datasets or datatypes to which the rule should apply. For more information, see Data Classification.

• Target — The API endpoints you want Traceable to monitor as part of the rule. You can select one or more APIs, or labels to which the rules should apply. The rule applies to all the underlying APIs when you select a label.

Once you have set the above criteria, click Next.

Step 2 — Configure the condition

Traceable provides the following options for configuring rule conditions. These conditions define the numerical limits after which the rule triggers.

• Unique Values Exceed — The maximum number of unique values, such as usernames, email addresses, etc. in an API request after which Traceable should perform the action configured in Step 3 below. For example, 10 unique values.

• Time Range — The time window over which Traceable counts the number of unique values. For example, a 5-minute time range means that Traceable monitors the API requests for enumeration attacks within this 5-minute window.

• Compute Condition — A combination of conditions on which the above limits should apply:

  • Per user and Per selected endpoints — If a user exceeds the set limit for an API endpoint, Traceable implements the action you select in Step 3 below.

  • Per user and Across all selected endpoints — If a user exceeds the set limit across all selected API endpoints, Traceable implements the action you select in Step 3 below.

  • By total requests across all users, and Per selected endpoints — If all users collectively exceed the above set limit for an API endpoint, Traceable implements the action you select in Step 3 below for all users. For example, you configure a rule to limit unique values to 100 in 1 minute for an API. Then, if there are 5 users, and each user sends 20 or more unique values per minute to that API, Traceable implements the action you select below.

  • By total requests across all users, and Across all selected endpoints — If all users collectively exceed the above set limit across all selected API endpoints, Traceable implements the action you select in Step 3 below for all users.

You can configure the above conditions to apply on one or more of the following parts of a request:

• Request Body

• Path Parameters

• Sensitive Parameters

Step 3 — Configure the action

As part of configuring the action, you must complete the following:

• Event Handling — Traceable provides the following options on how the event generated by the enumeration rule should be handled. The options let you verify your rule, observe the generated events, and finally use them to block requests, as required.

  • Block —

    • Block the user indefinitely — If a user meets the above criteria, Traceable blocks them indefinitely, preventing any further API requests.

    • Block for a period of time — If a user meets the above criteria, Traceable blocks them from making API requests for the duration you define.

    • Block user for a duration that matches the conditions — If a user meets the above criteria, Traceable blocks them from making API requests for the duration defined in the conditions above.

  • Do not block, monitor only — If a user meets the above criteria, Traceable does not block them, but monitors it indefinitely.

  • Mark for Testing — Test your enumeration rule before applying it to production data. All the events generated as part of the configured rule are of low severity, and Traceable does not generate any notifications for such events. You can view the testing events by navigating to the Protection → Threat Activity → Filter pane and applying the Testing filter under Status.

• Event Severity — Select the severity that Traceable should assign to the event generated by the Enumeration rule.

  Note

  This option is available for all options except Mark for Testing above.

• Data Injection — Add the header you wish to include in the request. You can use this data for monitoring where it can highlight an anomaly in the request.

  Note

  This option is available only when you select the Do not block, monitor only or Mark for Testing options above.

Once you have configured the above, click Next.

Step 4 — Review and Submit

In the final step, review and submit the rule. If you wish to edit any criteria during the review, click the Edit () icon corresponding to a section.