Securing the SIEM itself: protect the platform that holds every log

A SIEM holds a copy of almost every security-relevant event in the organisation, so whoever controls it can read your secrets in transit, delete the evidence and switch off the alerts that would have caught them. The platform pulls logs through agents, collectors and API connectors that carry credentials into cloud tenants and SaaS applications, it stores data that often includes tokens and personal data, and it is frequently wired to automation that can act on other systems. That makes the SIEM a tier 0 asset in its own right. This guide is for SOC leads, detection engineers and platform owners who run a SIEM, cloud native or self-hosted. It covers admin roles and data access, the service accounts and tokens the platform uses, protecting the platform's own audit trail, detection content integrity, backup and the lifecycle through to decommissioning. It is vendor-neutral: confirm exact setting names in your vendor's documentation. For what a SIEM should detect and how to run one, see the SIEM Guide.

Key takeaways

• Treat the SIEM as tier 0. It sees authentication events for every tier and often holds connector credentials into your cloud and identity providers, so administer it like a domain controller.
• Separate platform admin from data access. The people who change ingestion, retention and roles should not automatically be able to search every index, and analysts should not be able to change retention or delete data.
• Give every collector and connector its own credential. One ingestion token or API key per source, scoped to write only into its own index, with an owner and an expiry.
• Keep a copy the SIEM administrators cannot touch. Send the platform's own audit log, and an archive of high-value raw logs, to a separate write-once store.
• Protect detection content like code. Rules, suppressions and parsers decide what you can see; version them, review changes and alert when a rule is disabled outside a change.

Why the SIEM is a target

The UK NCSC introduction to logging warns that an attacker may target the logging service to remove evidence of their actions, and advises limiting write permissions and making changes detectable. A SIEM concentrates that risk: one console controls collection, parsing, detection, retention and deletion for the whole estate. The NCSC secure system administration principles (trusted management devices, protected admin interfaces, tiered administration, privileged access management, and logging and audit of admin activity) apply directly. See the Tiered Administration and Enterprise Access Model Guide.

The component table reflects a common architecture and is NHI Mgmt Group's view, not a sourced description of any one product; your platform may name, merge or split these components differently.

Admin roles and data access

Most SIEMs separate who can configure the platform from who can search which data. Design both before onboarding sources, because roles are much harder to narrow once teams depend on broad access.

• Role design: define at least platform administrator (roles, retention, integrations, deletion), ingestion engineer (sources, parsers, pipelines), detection engineer (rules and suppressions), analyst (search and case work) and auditor (read-only access to the platform audit log). Keep full administrators to a handful.
• Data access by index or table: restrict sensitive indexes, such as HR, privileged access session data, email content and data loss prevention events, to the analysts who need them. NCSC advises restricting log access to the people who need to analyse logs. See the Privacy in Security Logging and Monitoring Guide.
• Destructive actions: deleting data, shortening retention, removing a source and changing role mappings should need a second approver. NIST SP 800-53 AU-9(4) limits management of audit logging to a defined subset of privileged users.
• Authentication: sign in through your identity provider with SSO and phishing-resistant MFA. The CISA and FBI Secure by Demand guide asks whether standards-based SSO is offered at no additional cost and whether MFA is on by default; use those as procurement questions. Keep one documented break-glass local account. See the Break-Glass Account Guide.
• Admin devices: administer the platform from privileged access workstations, not from analyst laptops used for email and browsing. See the Privileged Access Workstations Guide.
• Managed service providers: if an MSSP operates the SIEM, give its staff named accounts through your identity provider or a documented federation, limited to the tenants and roles in the contract, and review them every quarter (our recommendation).

Service accounts, tokens and connectors

A SIEM deployment typically creates dozens of non-human identities: ingestion tokens for collectors, API credentials for cloud and SaaS audit log connectors, accounts that read directory data for enrichment, and keys that SOAR and scripts use to run searches. These are often created in a hurry during onboarding and never revisited.

• Prefer federation: where the cloud provider supports it, use workload identity federation for connectors instead of static keys. See the Workload Identity Federation Guide.
• Token hygiene: store collector tokens in the host's secrets store or configuration management, not in images or scripts in source control. Rotate static tokens at least every 90 days where federation is not available (our recommendation). See the API Key Management Guide.
• Inventory: record each SIEM identity with owner, purpose, scope and expiry in your NHI inventory, and review it alongside source onboarding. See the Service Account Security Guide.
• Enforce transport security: collectors should send over TLS with certificate validation; NCSC also recommends transport encryption wherever possible.

Sensitive data inside the SIEM

Logs routinely contain things nobody intended to collect: bearer tokens in URLs, API keys in command lines, passwords typed into username fields, and personal data. The SIEM then becomes a searchable store of secrets.

• Mask at ingestion: add parser or pipeline rules that redact known secret patterns and authorisation headers before indexing. Test them with sample events.
• Hunt for secrets in your own logs: run scheduled searches for credential patterns, and treat any hit as a leaked secret to rotate at the source. See the Secrets Access Logging and Detection guide.
• Encrypt at rest: for self-hosted deployments, encrypt storage volumes and backups; for SaaS, decide deliberately whether customer-managed keys are worth the outage risk if the key is disabled by mistake.
• Control exports: limit who can export results, cap export size, and alert on large or unusual exports.
• Data residency and retention: record where each index is stored and for how long. See the Log Management and Retention Guide.

Protecting the SIEM's own audit trail

An attacker with SIEM admin rights will try to change what the SIEM sees before acting. The platform's audit log is how you notice, and it must live somewhere the SIEM administrators cannot alter.

• Write once, elsewhere: forward the platform audit log, and ideally a raw archive of identity and admin logs, to separate storage with object lock or equivalent immutability under a different administrative account. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system, and AC-6(9) covers logging privileged functions.
• One-way flow where it fits: NCSC suggests a one-way flow such as a data diode when sending logs across trust boundaries, to make stored logs harder to modify.
• Retention: NCSC advises keeping logs that can answer incident questions for at least six months. Secure by Demand asks SaaS providers to retain security logs for at least six months at no extra charge. Check what your contract gives you for the platform audit log, not only for your data.
• Time: synchronise every collector and the platform to an accurate time source and store timestamps in UTC, as NCSC advises (AU-8).

Detection content and log source health

Rules, suppressions and parsers are security configuration. A single suppression on the wrong service account can hide an intrusion for months.

1. Manage rules as code: keep detection rules, suppressions and parsers in a repository, deploy through a pipeline, and require review for changes. See the Detection as Code Guide.
2. Expire suppressions: every suppression or allow-list entry gets an owner, a reason and an expiry date; 90 days is our suggested default.
3. Reconcile the deployed state: compare the rules running in the platform with the repository daily and alert on drift, so a console edit outside the pipeline is visible.
4. Alert on silence: NCSC advises alerting when logs stop arriving centrally. Alert per source when volume drops well below its baseline, and route that alert to a channel that does not depend on the SIEM alone.
5. Test end to end: inject known test events for critical detections on a schedule and confirm an alert fires. See the SIEM Log Source Onboarding Checklist.

Response integrations and automation

When the SIEM or a connected SOAR platform can disable accounts, isolate hosts or block addresses, a compromised console becomes an attack tool. Keep the identities that act separate from those that read, scope them to defined targets, keep a protected list (break-glass accounts, the SIEM's own identities, domain controllers) that automation can never touch, cap actions per hour, and require a human approver for high-impact actions. Document a one-step way to pause all automation and test it twice a year (our recommendation). See the SOAR and Security Automation Guide.

Platform hardening, backup and lifecycle

Roll back a hardening change, such as narrowing a connector's permissions, by keeping the previous permission set documented and re-granting only the specific right a failing feature reports as missing, never by restoring a broad admin role.

Detection and measurement

• Connector use from unexpected places: sign-ins by SIEM connector identities outside their expected network or workload identity (T1078.004).
• Credentials added to connectors: new secrets or certificates on SIEM app registrations outside a change (T1098.001).
• Platform persistence: new admins, new API keys, new suppressions outside the pipeline.
• Telemetry gaps: per-source volume against baseline, and collectors that miss heartbeats.

Metrics that show the controls are working:

1. Number of full platform administrators (target: five or fewer, our suggestion) and the share holding the role just in time.
2. Percentage of ingestion tokens and connectors that are per source, scoped and within their rotation date.
3. Suppressions older than their expiry without re-approval (target: zero).
4. Percentage of critical log sources with a working silence alert, and measured time to detect a stopped source.
5. Percentage of SIEM admin actions with a matching change or case reference.
6. Secret pattern hits found in indexed logs per month, and time to rotate them at source.

Framework mapping

Common failure patterns

• One ingestion token everywhere: a single token copied to every collector and into scripts, so one leak lets anyone write false events into any index.
• Connector granted owner rights: a cloud log connector given a broad administrative role during a proof of concept and never reduced, turning the SIEM into a path into the tenant.
• Analysts who can delete: broad built-in roles let every analyst change retention or delete indexes, so one compromised analyst account can erase evidence.
• Secrets indexed in clear: tokens in URLs and command lines are searchable by everyone with SIEM access.
• Audit log only inside the SIEM: the record of admin changes sits in the platform an attacker controls.
• Permanent suppressions: a noisy service account is suppressed during tuning and later becomes the account an attacker uses. See Top 10 SIEM Deployment Mistakes.

Practitioner checklist

• Classify the SIEM, its collectors and connector identities as tier 0 and administer them only from privileged access workstations.
• Enforce SSO with phishing-resistant MFA and keep one tested break-glass account.
• Separate platform admin, ingestion, detection, analyst and auditor roles, and restrict sensitive indexes by role.
• Require a second approver for data deletion, retention changes and source removal.
• Issue one scoped ingestion token per source and replace static connector keys with federation or certificates.
• Mask secrets at ingestion and hunt for credential patterns in indexed data.
• Export the platform audit log to immutable storage outside the SIEM administrators' control.
• Manage rules and suppressions as code with expiry dates, and alert on drift and on silent sources.
• Back up configuration and detection content separately and test a restore.
• Keep a decommissioning checklist that revokes every token, consent and connector identity.

Standards and references

• NCSC: Introduction to logging for security purposes
• NCSC: Secure system administration
• CISA and ASD's ACSC: Guidance for SIEM and SOAR Implementation
• ASD's ACSC, CISA and partners: Best Practices for Event Logging and Threat Detection
• CISA and FBI: Secure by Demand Guide
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-92 Rev. 1 Cybersecurity Log Management Planning Guide (Initial Public Draft)
• MITRE ATT&CK: T1685 Disable or Modify Tools

Related NHI Mgmt Group resources: SIEM Guide · SIEM Buyer's Guide · Securing the identity threat detection and response (ITDR) tool itself · Securing the PAM Vault Itself · Log Management and Retention Guide