Custom Policies

Custom Signatures are signature-based attacks that operate on traffic signatures generated by your application. You can configure a custom signature rule to fine-tune your API protection strategy by providing granular control over the event types generated and the requests blocked. These rules apply globally to all the APIs. You can create custom rules for different components of a request and response, such as header name and value, body, and Cookie. You can also create these rules on one or more request components. Traceable provides different preset operations for each part of the request. Traceable lets you choose the rule evaluation points based on the tracing agents used in your deployment. For more information, see Tracing Agents Rule Evaluation for Protection.

To create a rule, navigate to the Custom Signatures tab and click + Add Rule in the tab’s top right corner. Complete the following steps to create the rule:

Step 1 — Define the intent

To define the intent, you must complete the following steps:

1. Specify an identifiable and unique Rule Name that you can use to search the rule under the Custom Signatures tab, for example, Custom_signature_allow_rule.

2. (Optional) Specify a Description for the rule, for example, the type of protection strategy it implements.

3. Specify the appropriate Environment for which you want Traceable to apply the rule.

4. Select one of the radio buttons to Define action to be taken for this rule. You can choose from one of the following options:

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

   • Allow — Allows all threat actors that match the configured criteria.

     • Allow indefinitely — Select this option to allow requests matching the configured criteria indefinitely.

     • Allow user for a period of time  — Select the duration for which allowing should apply on the rule in terms of hours, days, or minutes.

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

   • Monitor and Block — Blocks all requests that match the configured criteria.

     • Block indefinitely — Select this option to block requests that match the configured criteria indefinitely.

     • Block user for a period of time — Select the duration for which blocking should apply on the rule in terms of hours, days, or minutes.

   The following table highlights the availability of the configurations below based on the action you select above:

   Actions →	Mark for Testing	Allow	Monitor only	Monitor and block
   Configurations ↓
   Severity of the event generated	X	X	✔️	✔️
   Inject data in request	✔️	X	✔️	X
   Rule Evaluation Point (The Inline Tracing Agent is selected by default)	✔️	✔️	✔️	✔️

5. What is the severity of the generated event — Select the severity that Traceable should assign to the event generated by the Custom Signature rule, such as Low, High, Medium, or Critical.

6. Select the Advanced Configuration from the following:

   • Inject Data In Request? — Enable the toggle and add one or more headers (Header Key and Header Value) you wish to include in the request. You can use this data for monitoring to highlight any anomalies in the request. If you have selected Mark for testing or Monitor only, the rule is evaluated at the platform level and does not modify live traffic, so header injection is not applicable. For other actions (Allow, Monitor and block), you can enable the toggle and select the appropriate rule evaluation point(s). Header injection is supported only at the Inline Tracing Agent or Traceable Edge, where traffic can be modified.

   • Rule Evaluation Points — Select the evaluation point(s) where Traceable should evaluate the rule, depending on your initial deployment setup:

     • Inline Tracing Agent — It runs within your application path and enforces security rules in real time. This rule evaluation point is selected by default.

     • Traceable Edge — It operates at the API gateway or ingress layer to inspect traffic and apply security controls before it reaches your services.

7. Once you have defined the intent, Next is enabled, click Next.

Step 2 — Set the criteria

To set the criteria, complete the following steps:

Note

The availability of the criteria (Source, Payload, and Target) below depends on the configurations you selected in Step 1 above.

1. Specify 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 custom signature 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 email domains or a range of email domains, for example, ones belonging to a particular organization.

   • User ID — Manage traffic based on unique user IDs or regular expressions (regex) for user IDs.

   • User Agent — Limit requests based on a 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.

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

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

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

   • IP Reputation — Limit data coming from IPs with a poor reputation, such as those 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.

2. Specify the Payload or the type of API component on which you want to apply the rule. You can create the rule based on the following:

   • Request/Response Payload — It helps evaluate specific components such as URL, host, or parameter values in the request body using defined operators and values. Under this, we have the following:

     • Host — One or more components, such as URL, Host, Parameter Name, Parameter Value.

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

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

   • Attribute — The metadata that 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 to 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 criterion 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.

3. Specify the Target — The API endpoints you want Traceable to monitor as part of the rule. You can select one or more APIs or the scope to which the rules should apply. The rule applies to all the underlying APIs and Services. Target has the following sub-sections:

   1. Specify the Scope. You can choose from the following:

      • All Services — Select this option when you want to target the rule for all the services.

      • Services — Select this option when you want to target the rule for any particular service. You can filter or search for any service according to your requirements.

      • All Endpoints — Select this option when you want to target the rule for all the endpoints.

      • API Endpoints — Select this option when you want to target the rule for all the API endpoints.

      • Endpoint Labels — Select this option when you want to target the rule for all the API endpoints labels.

   2. (Optional) Specify URL Regexes, for example, /login.

4. Once you have configured the above criteria, click Next.

Step 3 — Review and Submit

In the final step, you can review the selections and create the rule. If you wish to edit any intent or 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. Complete the following steps to create a rule:

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 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 type of data can be accessed, and at what rate the data can be accessed, among many other options. The DLP rule offers numerous granular options for configuration, including the source of traffic, IP addresses, IP type (such as bot, VPN, and others), user ID, region, attributes, and more.

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. Complete the following steps to create a rule:

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 a 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 indicate 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 those 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 to 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 for handling the event generated by the enumeration rule. The options allow you to verify your rule, observe the generated events, and then use them to block requests as needed.

  • 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.