fbpx

FAQ

Detections

What will it take to tune the detection policies? Can alerts be tuned? Can anomalies be tuned? Whitelist processes? How easy is to filter out false positive behaviors from the tool?
Security events that are detected falsely or are unimportant can be excluded from detection. (Under security events, select the event to be excluded.)

  • ‍Note these rules will only be muted for those specific parameters (specific to the endpoint) from where the alerts were generated. It will not be muted across the entire infrastructure. (Yes, you do have the option to mute for the entire infrastructure as well, although this is not recommended.) 
  • Specific endpoints can be tagged to be critical. Violations or abuse reported against these endpoints are highlighted and can be prioritized. As a result, rules can be adapted for specific parts of the infrastructure: dev, test, staging and prod.
    ‍
  • Rulesets can be customized to exclude specific categories of anomalies. Security administrators can invoke these customizations through the UI.
There are certain times that I would like to mute alerting since we will be doing operations like system updates or pen testing. How can I do that?

By default, no alerts are generated for individual events. If you know of specific activities and users who will be engaging in activities that appear suspicious, they can be added to the Allow list or time-limited Snooze list. Their activity will be ignored during that time.

How quickly can Traceable detect attacks?
Some attacks can be detected immediately. In well known patterns like SQLi, the attack may be detected as soon as the solution is deployed.

  • Detecting advanced zero-day exploits requires baselining of normal behavior. This can take dozens to hundreds of requests to complete over a couple of hours to a few days.
How long does it take to baseline normal behavior, train the models, and minimize the number of false positives?
The platform uses the foundational approach of distributed tracing to track, trace, and baseline API traffic that passes from users, through the APIs, and to the backend. Here are several things to remember:

  • Activities are attributed to users rather than to transient properties like IPs  or device IDs.
  • The platform is able to trace transactions all the way from edge APIs to backend services and databases.
  • The platform reverse-engineers the predictive nature of API traffic to automatically learn the schema.

The platform builds a comprehensive baseline of things related to (but not limited to):

  • Traffic patterns in and out of the APIs.
  • API interactions.
  • The sequence of API calls.
  • Parameters exchanged.

Based on the above, the platform identifies deviations/outliers/series of deviations. A simplified version of the detection algorithm is described below:

  • In each of the API requests and responses, we check that the parameter value matches the baseline seen for that specific request. If it doesn’t match, the anomaly is identified as a possible security event. The anomaly can be further analyzed for known security patterns.

The platform attempts to answer questions such as:

  • Is it exploiting a backend vulnerability?
  • Is it an isolated attempt?
  • How many attempts have been made?
  • Do we see a pattern of behavior?

While the platform specializes in the detection of OWASP API Top 10 risks, it can also detect traditional attacks included on that list such as SQLi and Cross-Site Scripting.

How does Traceable identify malicious activities? How do you differentiate normal activities versus those that are unknown, outliers, or nefarious?
The platform uses the foundational approach of distributed tracing to track, trace, and baseline API traffic that passes from users, through the APIs, and to the backend. Here are several things to remember:

  • Activities are attributed to users rather than to transient properties like IPs  or device IDs.
  • The platform is able to trace transactions all the way from edge APIs to backend services and databases.
  • The platform reverse-engineers the predictive nature of API traffic to automatically learn the schema.

The platform builds a comprehensive baseline of things related to (but not limited to):

  • Traffic patterns in and out of the APIs.
  • API interactions.
  • The sequence of API calls.
  • Parameters exchanged.

Based on the above, the platform identifies deviations/outliers/series of deviations. A simplified version of the detection algorithm is described below:

  • In each of the API requests and responses, we check that the parameter value matches the baseline seen for that specific request. If it doesn’t match, the anomaly is identified as a possible security event. The anomaly can be further analyzed for known security patterns.

The platform attempts to answer questions such as:

  • Is it exploiting a backend vulnerability?
  • Is it an isolated attempt?
  • How many attempts have been made?
  • Do we see a pattern of behavior?

While the platform specializes in the detection of OWASP API Top 10 risks, it can also detect traditional attacks included on that list such as SQLi and Cross-Site Scripting.