Sumo Logic Cloud SIEM Guide: Tuning Rules, Signals and Insights Well

Sumo Logic Cloud SIEM turns raw logs into records, fires rules that produce signals, and only raises an insight when an entity's accumulated signal severity crosses a threshold, so the quality of what analysts see depends on ingestion, rule tuning, criticality and suppression working together. A missing parser hint means records never reach the rules; an over-broad suppression means real attacks never become insights. This guide explains how to run Sumo Logic Cloud SIEM well, based on Sumo Logic's documentation: getting logs mapped, choosing rule types, tuning built-in rules without forking them, using entity criticality and suppression deliberately, automating triage and controlling who can change detections. It is written for detection engineers and SOC leads who operate Cloud SIEM. For the general discipline, see the SIEM Guide.

This is an independent guide from NHI Mgmt Group, based on Sumo Logic's public documentation as of November 2026. It is not sponsored or reviewed by Sumo Logic. Product features change, so confirm settings against Sumo Logic's current documentation.

Key takeaways

• No mapping, no detection. Only Continuous tier logs can be sent to Cloud SIEM, and each message needs mapping hints, supplied by a Cloud-to-Cloud connector's "Forward to SIEM" option or by _siemforward and _parser fields on the source.
• Insights come from activity scores, not single alerts. With the documented defaults (a 14-day detection window and a threshold activity score of 12), an entity whose unique signal severities rise from 0 to 13 within the window produces an insight.
• Tune, do not fork. Rule tuning expressions are ANDed with built-in rules and survive Sumo Logic's content updates, so they beat copying a rule to change it.
• Criticality and suppression move the score. A criticality such as severity+3 surfaces high-value entities sooner; suppression keeps signals out of insights entirely, so every suppression needs an owner and, where possible, a TTL.
• Detection content is privileged. Rule, tuning and suppression changes are logged in sumologic_audit_events; restrict the Content capabilities and alert on changes.

How Cloud SIEM turns logs into insights

Cloud SIEM has four core objects. Records are normalised events built from incoming messages. Signals are rule detections, each fired on an entity. Entities are usernames, hostnames, IP addresses, MAC addresses and custom entity types, each with an activity score. Insights are higher-level findings built from an entity's signals, and they are what analysts triage.

Getting logs into Cloud SIEM

Sumo Logic documents three ingestion methods in order of preference. All require Cloud SIEM to be enabled and the data to be in the Continuous data tier.

1. Cloud-to-Cloud connector (preferred): most connectors have a Forward to SIEM option that adds the mapping hints (Format, Vendor, Product and an Event ID template) automatically. Where the option is absent, assign the field _siemforward with the value true to the connector.
2. Sumo Logic source plus parser: for an HTTP source, tick SIEM Processing; for other sources, assign _siemforward=true to the source, or at collector level so sources inherit it. Then assign _parser with the parser path, for example /Parsers/System/AWS/AWS Network Firewall, copied from the Parsers page with Copy Path. Customise a parser with a local configuration if it does not fully fit your format.
3. Source plus ingest mapping (least recommended): mapping hints configured by hand in a Cloud SIEM ingest mapping.

Prioritise the sources that feed identity and privilege detections first: identity provider sign-ins, cloud control plane audit logs, endpoint telemetry and privileged access logs. A Log Source Coverage Matrix Template helps track which sources are mapped and which rules depend on them.

Rule types and when to use each

Every Cloud SIEM rule has an expression, a severity from 1 (lowest) to 10 (highest) and one or more On Entity attributes. A matching record generates one signal per On Entity attribute it contains, so a rule on both srcDevice_ip and dstDevice_ip produces two signals.

• Prototype first: Sumo Logic advises prototyping rule expressions in the core log search before writing a rule, and the rule details page has a Prototype Rule checkbox for saving a new rule as a prototype while you review its output.
• Community Sigma rules: imported rules are broad by design; review the expression and the original rule's known false positives, then tune. Updates upstream are not applied automatically: re-importing creates a new match rule. See the Sigma Rules Guide.
• Coverage view: the MITRE ATT&CK Coverage page in Cloud SIEM administration helps compare rule coverage with the techniques you care about.

Tuning rules without forking them

A rule tuning expression is matched against incoming records and ANDed with the rule expression; a signal fires only when both match. The documented example user_userId = !jdoe stops a rule firing for one user. Because Cloud SIEM preserves tuning expressions when it updates built-in rules, tuning keeps you on maintained content.

1. Find the noise: sort the Rules list by the 24-hour and 7-day signal counts and filter by source to find the loudest rules.
2. Read the records: open signals and their records to identify the benign pattern (a scanner, a backup job, a deployment pipeline).
3. Write the narrowest expression: exclude the specific account, host or network, not a whole class of activity. Prefer a match list of known scanners referenced by the expression over hard-coded values.
4. Scope it: apply the expression to the selected rules only; reserve "all rules" for exclusions that are safe everywhere.
5. Record the reason: name expressions with the ticket and owner, and review them quarterly.

Tuning expressions, match lists and multi-entity rules together reduce the number of custom rules to maintain. For tuning practice beyond the product, see the Alert Fatigue Reduction Guide.

Insight generation, criticality and suppression

An entity's activity score is the cumulative severity of its unique signals over the detection window. The documented defaults are a 14-day detection window and a threshold activity score of 12, so an entity whose score goes from 0 to 13 within 14 days triggers an insight. Both are set in Insight Generation Settings.

Entity criticality

A criticality is a Severity Expression applied to signals on chosen entities, using +, -, * or /. severity+3 suits an executive's laptop or a domain controller; results round down and cannot go below 0. Define criticalities under Cloud SIEM > Criticality, assign them on the entity details page, or manage them as code with the Terraform resource sumologic_cse_entity_criticality_config. Lowering severity also lowers the activity score, so use reductions sparingly.

Suppression mechanisms

A suppressed signal is still generated but excluded from insight generation; the suppressedReasons field in the sec_signal index records why.

Triage, automation and response

• Statuses and resolutions: Cloud SIEM supports custom insight statuses and resolutions. Define resolutions such as true positive, benign true positive and false positive so closure data feeds tuning. See the Alert Triage Guide.
• Automations: automations run Automation Service playbooks for enrichment and notification. The Execution trigger is Insight Created, Insight Closed or Manually Done; the playbook Type must be CSE, and it must pass Run Test and be published before use. Start with Manually Done, then switch to automatic triggers.
• Entity automations: set Object to Entity and choose entity types; they run only when an insight contains entities of those types.
• Limits: actions per hour are limited and the same automation cannot run concurrently on one insight, so keep playbooks short and idempotent.
• Context actions: context actions query an external system for details on an entity, indicator or record field, which speeds lookups without leaving the insight.

Access control and audit for detection content

Cloud SIEM capabilities are granted in roles under Administration > Users and Roles > Roles, starting with View Cloud SIEM, then capabilities in three groups: Insights, Content (rules, match lists, entities) and Configuration (mappings, tags, automations). Users cannot manage something without also being able to view it.

• Custom roles per job: analysts get Insights capabilities; detection engineers get Content; platform owners get Configuration. Sumo Logic notes that custom roles do not gain new feature capabilities automatically, so review release notes and add only what each role needs.
• Search filters: do not restrict Cloud SIEM users' search filters on indexes that hold Cloud SIEM records, or investigations break.
• Audit indexes: user actions land in sumologic_audit_events and system actions in sumologic_system_events, both on by default for Cloud SIEM and Enterprise accounts. Filter by _sourceCategory values such as cseRule, cseRuleTuningExpression, cseSuppressList and cseMatchList; the operator field shows who acted.
• Retention: audit indexes follow the default partition's retention unless you edit those partitions; set them to match your evidence requirements.

Where identity fits

Most high-value Cloud SIEM detections are identity detections: brute force, new admin accounts, role changes and unusual cloud account use. Two identity tasks make them work. First, entity lookup tables and normalisation must resolve human and machine accounts consistently, or one service account appears as several entities and never accumulates a score. Second, the API access keys and connector credentials that feed and manage Cloud SIEM are non-human identities: scope them, store them in a secrets manager and rotate them. See the Detection Engineering for Non-Human Identities Guide.

How to implement

1. Inventory sources: list every source that should reach Cloud SIEM, its data tier, its ingestion method and its parser.
2. Fix ingestion: move sources to C2C with Forward to SIEM where available, otherwise set _siemforward and _parser; confirm records appear with key attributes populated.
3. Normalise identities: configure entity lookup tables for username and hostname conventions, including service accounts.
4. Set criticality: define two or three criticalities (crown-jewel hosts, privileged users) and assign them.
5. Baseline for two weeks: run with defaults for at least one detection window, recording signal counts per rule and insights per week.
6. Tune the top noise: add tuning expressions to the loudest rules, one change at a time, and compare signal counts before and after.
7. Add custom rules as prototypes: write custom rules with Prototype Rule set, review their signals, then promote them.
8. Automate: add enrichment playbooks as Manually Done, then enable Insight Created triggers.
9. Roll back: tuning expressions can be removed and rules disabled; keep criticality in Terraform and record every rule and tuning change in a ticket so a previous state can be restored.

Detection and measurement

Alert on changes to suppressed lists, network blocks and tuning expressions from the audit index, and review sec_signal for suppressed signals on critical entities during each investigation. For managing rules as code, see the Detection as Code Guide.

Common misconfigurations

• Logs searchable but not forwarded: a source without _siemforward or in a non-Continuous tier never produces records, so its rules stay silent.
• Forking built-in rules: copied rules miss upstream improvements; tuning expressions avoid this.
• Broad network block suppression: suppressing a VPN or office range hides an attacker operating from an authenticated session.
• Permanent indicator suppression: suppressed list entries with no TTL outlive the reason they were added.
• Split identities: unnormalised usernames spread one account's signals across several entities, so the score never reaches the threshold.
• Broad Content rights: analysts who can edit suppressions can silence detections without review.

Framework mapping

Practitioner checklist

• Every priority source is in the Continuous tier and forwarded with C2C Forward to SIEM or _siemforward plus _parser.
• Entity lookup tables normalise human and service account names.
• Criticalities defined for crown-jewel hosts and privileged users.
• Insight window and threshold reviewed after the first detection window.
• Noisy built-in rules tuned with narrow, named tuning expressions rather than copies.
• New custom rules start as prototypes.
• Every suppressed indicator has a TTL and every suppressed entity or network block has an owner.
• Custom roles separate Insights, Content and Configuration capabilities.
• Audit index alerts on changes to rules, tuning expressions and suppressed lists.
• Automations tested as Manually Done before automatic triggers.

Standards and references

• Sumo Logic: About Cloud SIEM Rules
• Sumo Logic: Cloud SIEM Ingestion Best Practices
• Sumo Logic: Record Processing Pipeline
• Sumo Logic: Insight Generation Settings
• Sumo Logic: About Signal Suppression
• Sumo Logic: Entity Criticality
• Sumo Logic: Cloud SIEM User Accounts and Roles
• Sumo Logic: Cloud SIEM Audit Logging

Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · UEBA Guide · Alert Triage Guide