When a scanning rule matches, Atatus attaches tags to the event before storing it. Those tags are how you find sensitive data across your logs without ever seeing the values themselves. This page covers searching for matches, building facets and dashboards, alerting, and what to check when you expect findings but do not see any.

​
The tags you search on

Every rule attaches two tags: In Logs these appear as two facets:
The search bar also accepts @sensitive_data_catagory, an older misspelling of the same key. Both forms return the same results, so existing saved searches and dashboards keep working. Use @sensitive_data_category in anything new.

​
Search for matched events

Open Logs and use the search bar. See Logs Search Syntax for the full query language. To find every event that any rule matched:
To find events where a specific format was detected:
To find everything in a category:
To narrow to a service as well:
You can also click the Sensitive Data and SDC Category facets in the logs sidebar instead of typing a query. The facet list doubles as a quick inventory of what your rules are finding.

​
What you see in a matched event

Open an event and you will see the masked value in place of the original, in the form your rule’s action produced:
Atatus never stores the original value for the masking actions, so there is no way to reveal it from the UI or the API. If you need the value for an investigation, get it from the source system.

​
Build a dashboard

The tags work like any other attribute, so you can chart them. A useful starting dashboard has:
  • A count of matched events over time, broken down by @sensitive_data_category. A sudden jump usually means a new code path started logging something it should not.
  • A top list by service, to show which services handle the most sensitive data.
  • A top list by @sensitive_data, to show which formats appear most often.

​
Alert on sensitive data

Because findings are ordinary tagged events, you can alert on them with a standard log alert. Two alerts that earn their keep:
  1. Sensitive data in an unexpected service. Alert when @sensitive_data:* matches a service that should never handle it. This catches data leaking across service boundaries.
  2. A spike in a category. Alert when the count of @sensitive_data_category:credit_card events rises well above its normal level, which usually points at a new logging statement.
See Logs Alerts for how to create and route these alerts.

​
When you expect findings but see none

Work through these in order:
  1. Check both toggles. The scanning group and the individual rules each have their own enabled state, and both are off when first created. A group with no enabled rules is skipped entirely. This is the most common cause.
  2. Check the scanning method. If the group’s scanning method for Logs is None, no log data is scanned no matter what the rules say.
  3. Check the sampling rate. At Sample with a low rate, most events are not scanned. Set the method to 100% to confirm the rule works, then lower it again if you need to.
  4. Check the filter. A group filter that does not match your traffic means the group never sees the events. Clear the filter temporarily to test.
  5. Check the timing. Configuration applies to newly received logs. Events stored before you enabled the rule are not rescanned, so search a time range that starts after you enabled it.
  6. Test the pattern. Open the rule for editing and paste a real log line into the evaluator. If it shows no matches there, the problem is the pattern or its proximity keywords, not the pipeline.
  7. Check the keywords. If the rule has included keywords, a match is only kept when one of those words appears within the Characters before match window. Widen the window or remove a keyword to test.

​
Next steps