Custom Signatures

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 application and 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 the header name and value, the body, and the 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.

What will you learn in this topic?

By the end of this topic, you will be able to:

• Understand the need for Custom Signature rules.

• Understand the steps to create a rule.

• The actions that you can take on the created rules.

Before you begin

Before you proceed to create the rules, make a note of the following:

• Make sure you have the Settings RBAC permissions under Module Level Access → API Protection to create the rules. For more information, see RBAC.

• Make sure you understand how payload matching works. For more information, see Understand payload match.

Understand Custom Signatures

Before you configure Custom Signature rules , it is important to understand how they translate your application’s security requirements into enforceable detection logic. The table below explains when to use Custom Signatures, why they are critical for closing protection gaps that generic detections cannot cover, and how you can strategically implement them to strengthen your API security posture with clarity and control.

Steps to create a rule

To create a custom rule in Traceable, navigate to Protection → Settings → Policies → Custom Policies, select the appropriate rule type, and click + Add Rule. 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. Create the rule using the following three steps:

1. Define the intent — Specify the rule name, environment, enforcement action, and rule evaluation point to determine how Traceable processes match traffic.

2. Set the criteria — Configure the conditions the traffic must meet, including source, payload components, and target scope.

3. Review and submit — Validate the configured settings and submit the rule for activation.

Step 1 — Define the intent

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

1. Rule Name — A unique and identifiable name for the rule, for example, custom signature allow rule.

2. (Optional) Description — A summary of the rule’s purpose or the type of traffic it controls.

3. Environment — The environment in which Traceable should apply the rule.

4. Action — The action Traceable should take when the rule conditions are met. Choose one of the available options from the table below:

   Action	Description	Configuration
   Mark for testing	Tests the custom signature rule before applying it to production data. Events generated by the rule appear with low severity, and Traceable does not send notifications for them. You can view these events by navigating to Protection → Threat Activity and selecting Testing in the Activity Status filter.	Not applicable
   Allow	Allows all requests that match the configured criteria.	Allow indefinitely — Allows matching requests permanently. Allow user for a period of time — Allows matching requests for a specified duration in minutes, hours, or days.
   Monitor only	Monitors traffic for requests that match the configured criteria. No requests are blocked.	Not applicable
   Monitor and Block	Blocks requests that match the configured criteria.	Block indefinitely — Blocks matching requests permanently. Block user for a period of time —Blocks matching requests for a specified duration in minutes, hours, or days.

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

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

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

6. Under the Advanced Configuration, you can configure 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 traffic path and enforces security rules as requests pass through your system. This evaluation point is selected by default.

     • Traceable Edge — It routes traffic through Traceable’s cloud, where requests are inspected, and security controls are applied before they reach your services, without requiring internal deployment.

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 you want to apply the rule to. For example, IP Addresses → All External IPs. Traceable supports the following sources for creating a custom signature rule:

   Source	Description
   IP Address	Restrict or allow traffic from specific internal or external IP addresses.
   IP Type	Control traffic based on IP type, such as Anonymous VPNs, bots, or scanners.
   Scanner	Manage traffic originating from automated scanning and testing tools, such as Traceable AST and similar security scanners.
   Email Domain	Limit requests originating from specific email domains or domain ranges associated with an organization.
   User ID	Manage traffic using specific user IDs or user ID patterns defined through regular expressions (regex).
   User Agent	Restrict requests based on user-agent patterns that identify automated clients, scripts, or bots.
   IP Organization	Control traffic from known organizations or entities that commonly generate high API request volumes.
   Connection Type	Enforce limits based on the connection source, such as corporate networks or data centers.
   IP ASN	Restrict traffic from specific Autonomous System Numbers (ASNs) representing network providers.
   IP Abuse Velocity	Limit requests from IPs exhibiting unusually high or abusive API request rates.
   IP Reputation	Control traffic from IPs flagged as high risk by threat intelligence sources.
   Region	Apply limits based on geographic location to manage region-specific traffic patterns.

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/Attribute Criteria — This option allows you to evaluate specific components from the Request, Response, or Attributes using defined operators and values. You can use it to build conditions based on URLs, headers, parameters, and payload fields. For more information, see Understand payload match.

     • Static Payload Match (Default) — By default, Traceable compares a static component against a static value.

     • Dynamic Payload Match — If you enable the Dynamic toggle, it compares two attributes from the request, response, or extracted attributes, allowing Traceable to evaluate their relationship rather than matching against a fixed value.

       Note

       The Dynamic toggle is only visible if you select Monitor only and Mark for testing actions in the Step 1 — Define the Intent above.

   • Sec Rule — It helps you define security rules to analyze data as it passes 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.

3. You can add one or more criteria for the same or different payloads. Traceable performs an AND operation across all the conditions defined in the rule.

4. Target — The API endpoints you want Traceable to monitor under this 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. The following table describes the different targets and their corresponding descriptions:

   Targets	Description
   All Services	Apply the rule across all services that Traceable discovers and monitors.
   Services	Apply the rule to one or more specific services. You can search or filter services based on your requirements.
   All Endpoints	Apply the rule to all endpoints within the selected service(s).
   API Endpoints	Apply the rule to specific API endpoints. This allows granular control at the endpoint level.
   Endpoint Labels	Apply the rule to endpoints associated with specific labels, enabling logical grouping and reuse across APIs.
   URL Regex (Optional)	Further restrict rule scope by matching endpoint URLs using regular expressions for example, /login.

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

Actions available for a rule

After you add a rule, you can perform the following actions using the Ellipse () icon corresponding to a row:

• Enable or Disable Toggle — Use the toggle( ) corresponding to a row to perform this action. It updates the status as active or inactive based on the enable or disable action, respectively.

• Edit — Add or remove attributes as needed.

• View — View a rule after you have created it.

• Clone — Clone a rule to create a copy of an existing rule with the same values as the existing rule.

• Delete — Delete the rule.

• Change Logs — Log the changes of each activity occurring within the rule created.