integrations.microsoft_sentinel_network_logs — version 1.0

Source: presets/integrations/microsoft-sentinel-network-logs.satz

Purpose

The four network log streams, on their way to Microsoft Sentinel.

NEEDS presets/integrations/microsoft-sentinel.satz: the connector reads as the account that file creates. Used without it, the compile stops with unknown param 'sentinel_project_id'.

WHY ALL FOUR, AND WHY ON BY DEFAULT. VPC flow logs, firewall rules logging, DNS query logging and Cloud NAT logging are separate log streams, not filters over the audit log, and each one is EMPTY until somebody enables that feature — flow logs per subnet, firewall logging per rule, DNS logging per policy, NAT logging per gateway. Cloud Logging charges nothing to route log entries and an idle subscription moves no bytes, so a sink for a feature nobody enabled costs nothing. What switching these off buys is therefore nothing; what it costs is the day somebody enables flow logs and finds that Sentinel was not watching. The volume once a feature IS on is real, and it lands on Sentinel's ingestion bill rather than on Google's routing — an estate that wants one stream out uses suppress on that sink, topic and subscription.

FIVE RESOURCES PER STREAM, and the two grants are the ones that get forgotten: the organisation sink (include_children, so a project created tomorrow is covered), its topic, the subscription Sentinel pulls from, roles/pubsub.publisher for the sink's own writer identity — without which the sink exists and delivers nothing — and roles/pubsub.subscriber for the connector on that one subscription.

EACH FILTER SELECTS ONE STREAM AND NOTHING ELSE — log_id where Google publishes the log name (flow logs, firewall, NAT) and the documented resource type for DNS queries, whose log name Google does not publish. Microsoft's published configurations mix each stream with the audit records of the same service (protoPayload.serviceName=…) — those records already leave through microsoft-sentinel-auditlogs.satz, so carrying them again would export and bill the same entries twice.

SUBSCRIPTION NAMES ARE MICROSOFT'S, because the Sentinel connector is configured with them on the Azure side. The TOPIC names are not: Microsoft's firewall setup names its topic sentinel-topic, the same name its audit setup creates, and two setups creating one topic is a collision. Each stream here has its own topic.

NO CLAIM. A copy of a log leaving the organisation satisfies no control; the archive (monitoring/organization-audit-logsink.satz) is what claims the logging controls. Note also that nothing here ENABLES flow logs, firewall logging, DNS logging or NAT logging — this carries them once they are on. Enforcing them is a separate decision.

Use it

params {
  // the pack's own defaults — copy only the lines you change
  sentinel_network_retention = "604800s"
  sentinel_network_ack_deadline_seconds = 60
}

use "presets/integrations/microsoft-sentinel-network-logs.satz"

Needs from outside the pack:

• customer_organization_id — declared by estate_core; use one of them alongside, or declare it in the estate.
• sentinel_project_id — declared by integrations.microsoft_sentinel; use one of them alongside, or declare it in the estate.

Params

Contributes

Claims

None — this pack proves no control by itself.

History

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

No notes yet.