SIEM logging: the feed that stopped

An investigation into a former contractor’s account needs the CRM’s admin logs for the second week of March. The SIEM has February and it has April. The CRM’s log feed broke when its API token expired in early March, and it started again in April, after someone noticed a different problem.

Nothing alerted on the gap. To the SIEM, a feed that has stopped looks the same as a quiet one.

Log collection is the first part of security operations. Every detection and every investigation after it can only use the events that arrived.

What is SIEM logging?

SIEM logging collects sign-in, admin and audit events from every system the company runs and delivers them to the SIEM in one consistent format, minutes after they happen. For SaaS apps, that usually means pulling each app’s audit log through its API, because there’s no server to install an agent on.

Why SIEM logs have gaps

1. Feeds fail without an error. A token expires or an API changes, and the feed returns nothing instead of failing.
2. Every app logs in its own shape. Field names, timestamps and user IDs differ, so a search across apps misses events.
3. New apps never get a feed. A team buys a tool, and nobody tells security it holds company data.
4. Logs arrive late. Some APIs are polled once a day, so detections run on yesterday’s events.
5. Sensitive values reach the SIEM. Tokens and personal data inside log lines end up stored where many people can search them.

What it costs

Gaps stay hidden until the day they matter, in an incident or an audit. Then the team can’t say what happened in that window. Late logs slow every detection built on them, and unmasked secrets in logs become a risk of their own.

What to fix first

1. Watch every feed’s volume. A feed that drops below its normal level for an hour raises an alert.
2. Map events to one schema on the way in. User, action, target and time mean the same thing in every source.
3. Add a feed when an app is approved. Make the log feed a step in supplier review and app onboarding.
4. Pull as often as each API allows. Sign-in and admin events should arrive in minutes, not days.
5. Mask sensitive values before they’re stored. Replace tokens, passwords and personal data before the event reaches the SIEM.

The guide to building SaaS security log collection has the prompts for each step. For the masking step, see masking sensitive data in logs.

Where it fits

Every later part of security operations depends on it. Alert triage can only enrich alerts with the events that arrived, and account takeover response relies on fresh sign-in logs to spot a risky session. New apps reach the list through vendor risk assessment. The platform that runs your workflows belongs on the list too. Tray.ai logs every action on its platform, and those logs can stream to your SIEM like any other source. See the trust page.

For every part of security operations, from first alert to shipped fix, see SOC automation.