Docs / Investigation guides

Security logs

Ask about security in plain words with Splunk or Elasticsearch attached: any suspicious logons in the last 24 hours?, did anyone clear an audit log this week? Verbiqo reads the events, counts them per host and account, and works out what they mean together before the model writes anything.

What it works out for you

Each comes with the events that prove it, and every event is on the timeline with your databases, metrics and other logs.

Events it recognises

Windows events are read in their classic text, XML or ECS form, so Splunk’s Windows add-on, Winlogbeat and Elastic Agent all work. Secrets in logged commands (passwords, tokens) are masked in everything shown.

With Splunk

Nothing to set up beyond the Splunk connection, with one condition: Verbiqo searches only the indexes the account’s role allows (srchIndexesAllowed, see the role it needs), so that list must include the indexes that hold the Windows Security logs, the Linux authentication logs and, with Enterprise Security, the notable index. Within them, Verbiqo recognises the three by their content, whatever the sourcetype is called, and says when a question needs an index it cannot see. Findings are numbered X1.1, X1.2 and so on.

With Elasticsearch or OpenSearch

Reading log documents is opt-in for each connection. Name the indices in Log indices on the connection form, or:

verbiqo es add siem --url https://es.example.com:9200 --auth apikey --secret-stdin \
  --log-indices "winlogbeat-*,logs-system.auth-*,.alerts-security.alerts-*"

Give the connection’s account read on those indices only:

POST _security/role/verbiqo_monitor
{
  "cluster": ["monitor", "monitor_snapshot", "read_ilm", "read_slm"],
  "indices": [
    {
      "names": [
        "winlogbeat-*",
        "logs-system.auth-*",
        ".alerts-security.alerts-*"
      ],
      "privileges": ["read", "view_index_metadata"]
    },
    {
      "names": ["*"],
      "privileges": ["monitor", "view_index_metadata"]
    }
  ]
}

• Verbiqo builds every search, never the model, which still cannot search at all.
• Each search is bounded in time, returns at most 200 documents and only the fields Verbiqo reads, with no scripts. Counts come from the cluster, exact over the period.
• Successful logons, far too many to read, are asked for only from the addresses that failed most.
• An index pattern for every index (*) is refused: name the log indices.

Credentials written into logs

Ask are any passwords or keys leaked in our logs? and Verbiqo looks through Splunk, or the Elasticsearch log indices, for:

• passwords in assignments (password=, pwd:);
• database and broker URLs that carry a password (postgres://user:pass@);
• AWS and Google cloud keys;
• private keys;
• bearer tokens, JWTs, and GitHub, Slack and Stripe tokens.

Each line is masked as it is read, so the secret itself never reaches a finding, the timeline, the model or the report. What you get is where it was written (host, sourcetype or index), how often and when, and the line around the masked value, which is what finds the code that logs it. Placeholders such as ****, [REDACTED] and ${DB_PASSWORD} are not reported.

Rotate the credential first, then stop the code logging it, then remove the lines from the index.

What to ask

• Any suspicious logons or attacks in the last 24 hours?
• Who was added to Domain Admins this week?
• Did anyone clear an audit log?
• Investigate the open alerts from last night.
• Are any passwords or API keys written in the application logs?

Every read is on the access record. An organization policy that lists features turns these hunts off unless it names security-logs (features).