Skip to main content
Sumo Logic

Using Cloud SIEM Training Manual

Cloud SIEM is an additional option to include with Sumo Logic. It provides additional infrastructure to Sumo Logic .

Cloud SIEM Value


“SIEM” stands for Security Information and Event Management. SIEMs are used to provide a far-reaching view in organizational security, and are used in many SOC (security operations centers). Before we dive deep into the details, we need to make some distinctions between the Sumo Logic core product and the Cloud SIEM offering. The Sumo Logic core product on its own is a SIEM system and is used in many Security Operations Centers today. The way Sumo Logic core is used for security is covered in more detail in our Security Analytics certification.

Cloud SIEM is an additional option to include with Sumo Logic. It provides additional infrastructure to Sumo Logic to improve this cycle:


This is a security cycle similar to many other cycles used in the industry. This cycle is composed of collecting log data, detecting when the picture the data creates warrants human intervention through an investigation, and ultimately response recommendations to a security incident. Cloud SIEM shifts manually handled aspects of this cycle starting with data collection, and pushes automation through as much of this process as possible until human intervention becomes absolutely necessary. If and when a security condition gets to the point of human intervention, much of the work of correlating log events across multiple attack surfaces has already been done, making investigations susceptible to quick resolutions (commonly referred to as MTTD/MTTR, or Mean Time To Detection and Response) measured in days or hours, rather than weeks or months.

The key differences between Sumo Logic core functionality from the additional functionality provided with Cloud SIEM can be seen in the following table:


To summarize, Sumo Logic Core supports all expected SIEM functionality. Sumo Logic’s Cloud SIEM provides structured rules-based security incident detection, automated security correlation, and investigation management.


The Sumo Logic platform is compliant to a variety of standards.

Sumo Logic as a Platform (as a product) is compliant with:

  • PCI DSS 3.2 Level 1 certified
  • SOC 2 Type II attestation
  • ISO 27001 certified
  • CSA Star certified
  • HIPAA-HITECH compliance
  • U.S. – EU Privacy Shield
  • AES 256-bit encryption at rest
  • TLS encryption in transit
  • FedRamp Ready

You can find an updated list here:

Cloud SIEM Architecture

To get a better understanding of the Cloud SIEM solution, we’ll do it from the perspective of the aspect that is most important to making it work: the data (which is log data at first). Log data can track virtually anything, and an efficiently running business can generate millions of logs in minutes. As we go from the collection to investigation, from the perspective of data, it can be seen as a large systemically-driven filter, designed to take millions of logs, and filter it down to human-consumable bits of data for investigation.  


From top to bottom: millions of logs sources get organized into events. Factors are derived from the events. Notable events are generated from correlating factors or events. Notable events can be combined to indicate the existence of a security condition, and security conditions detected by rules can trigger one or more actions including making investigations. We’ll cover each piece of terminology in more detail, but for now, it’s important to note that through this journey, we’ve automated away the analysis of millions of logs down to less than 10 security incidents to investigate.



Relating this back to the original cycle and the security roles we referenced, you can see that most of the automated data processing (“detection”) occurs under the Security Engineer’s purview, while the processes needing human intervention (“investigation”) is under the Security Analyst’s purview. 

Let’s start breaking down Cloud SIEM architectural segments. Throughout this course, we will refer to the following diagram often as a reference to piece together what each segment of Cloud SIEM does.  




We first start with sources of logs. Logs get collected by Sumo Logic collectors. So far, this is consistent with how the core platform collects logs. There are hosted collectors, which can collect logs from popular services from AWS, GCP, or Azure, among other services capable of sending data outbound. Installed collectors can collect data from on-site and localized hardware using Syslog or similar systems and devices. This process of collection serves data to all of Sumo Logic’s use cases, not just Cloud SIEM. The details of each method of collection and the steps to do so are covered extensively in our Administration certification.



To get a better idea of what you can collect through Sumo Logic, check out the App Catalog under security and compliance. We support collection of data from many sources. 

Next we’ll touch upon how Cloud SIEM detects logs and processes them for downstream use. Parsing does many things, but first and foremost, it transforms log messages into more structured data by converting them into events. Events are then analyzed to determine their security relevance. This analysis is done by the Rules Engine. Analysts benefit from this automated analysis while performing investigations further downstream. It’s important to note that parsing in Cloud SIEM is not like parsing in Sumo Logic core platform where regular parsing is done on search runtime or with Field Extraction Rules. Parsing for Cloud SIEM is done in a separate dedicated interface with unique syntax to index and prepare events in ways that make them easier for downstream processing, including during security investigations.




After being parsed and organized, the Rules Engine provides context by filtering, joining, and aggregating related events. The Rules Engine is powerful in that it draws correlations between different sources of events in a given time range. For example: Let’s say you want to detect a short-lived privileged account creation as indicated in AWS VPC flow logs. A good rule will detect the length of time a privileged account exists by recognizing the ‘create privileged user’ event, and comparing the time to the ‘delete same user’ event. A better rule will detect when a ‘create privileged user’ event has been detected from a VPC flow log and joined with a large data ex-filtration event from a separate network log.


We’ve covered log collection and how the Rules Engine detects their relevance for security use cases. Now we’ve reached the response phase where we’re asking the question: “How do we detect when a given condition, or pattern of events, (defined by the Rules Engine) is met?” When a rule condition is met, it is said to “trigger” an action or multiple actions can be automated to perform when a rule is triggered, such as sending an email to a list of recipients, creating a notable event to be re-ingested and re-processed, performing a webhook to send out to a message service like ServiceNow or Slack, among other actions. For the purpose of describing Cloud SIEM at a high level, we’ll focus on the Create Investigation action.



When the “create investigation” action is committed, it creates an investigation object in Cloud SIEM, complete with details derived from events that triggered the rule, and save that investigation to a Burndown repository (which can be thought of as triage).




When an investigation reaches the Burndown queue, it indicates the events that triggered the rule to create the investigation need to be reviewed by a person (namely, the security analysts) to determine if a security event has occurred. This is done using the Investigation Workflow user interface, which lays out predefined correlations and a structure to events deemed likely relevant to the investigation. This preprocessing is designed to make the analyst’s work easier and accelerate the resolution of security investigations. After the investigation is complete, the analyst generates a Report with findings - much of which is auto-completed by Cloud SIEM since the details of the investigation are tracked. The analyst also has the option to provide what additional intervention should be performed - whether it’s taking down an instance, resetting a user password, or limitless other actions depending on what occurred.  Think of the Burndown queue as incidents whose response cannot be completely scripted.





As a quick recap: Sumo Logic will collect log using collectors. Parsers take the logs and refine them into structured events and enrich them with metadata. The Rules Engine analyzes the events and triggers when a condition is met. A trigger can commit one or more actions. The action we’re going to focus on is to Create an Investigation. Investigations are best created when a circumstance defined by the Rules Engine requires the Security Analysts’ attention. All investigations are stored in the Burndown queue. The analyst can then be assigned to an investigation contained in the Burndown, reviews the events through taking advantage of the correlations Investigation Workflow has to offer, and generates a report from the findings, possibly with a corrective course of action. That’s the complete cycle for Sumo Logic Cloud SIEM.



The first Cloud SIEM-native element of the data journey pipeline is Parsing. Parsing exists as its own tab option through the Cloud SIEM navigation selection.




In the overview graphic referenced below, we show data going through one parser, but there are actually two different types of parsers: Device Parsers, and optionally, Mapping Parser. We’ll cover device parsers first, since they are further upstream in the data journey and are required to produce any data for Cloud SIEM. 




Device Parsers

As mentioned before, Parsing in Cloud SIEM is done in a separate dedicated interface with different syntax to index and prepare events in ways that make them easier to read and investigate. It’s important to note that parsing in Cloud SIEM is different than the Sumo Logic core product. When raw log messages are ingested into Sumo Logic, configured Cloud SIEM Device Parsers detect ingested logs with a given Source Type metadata tag defined however you’d like upon setting up the collector, and process the logs into structured event dictionaries (“Events”, for short) - complete with with legible key-value pairs. These parsers are what we call “device specific,” meaning there may be one device parser for PAN firewall messages, one device parser for CloudTrail logs, and so on. Ideally, there would be as many device parsers as there are security services implemented in an organization. For instance, you may install a collector on a PAN Firewall so they will be ingested by Sumo Logic to be used with Cloud SIEM. You can configure the logs to be tagged with “PANF” as the _sourceType. Afterward, you would specify a device parser (source type) to detect and process any logs ingested with _sourceType=”PANF”. This way, the parser is forwarded logs with a format it understands and processes into refined events to be used in downstream security rules.


Device parsers for common services are offered out-of-the-box without the need to configure yourself. You also have the ability to create customized parsers, which can detect logs from less conventional sources.




As a real life example, the following image is what a Palo Alto Network (PAN) Firewall log message looks like. PAN firewall messages have standard comma-separated field value format (CSV). The log messages themselves don’t have the field names, but since this log message has a standard format, a device parser can assign each value to the correct field name and create an event dictionary, which is the list of derived key-value pairs you see on the right of the table below:


Destination Location :

Action Flags : 0x0

Action : allow

Category : any

Future3 : 2016/02/26

Future 4 : 0

Future 5 : 0

Destination Port : 0

Log Forwarding Profile : IAS_Test

Source Zone : trust

Start Time : 2016/02/26 11:15:03

Sequence Number : 21377534186

Serial Number : 007701000616

Packets Sent : 2

Bytes : 236

Nat Destination Port : 0

syslog_timestamp : Feb 26 11:15:14

Packets : 2

Rule Name : Trusted

Source IP :

Future1 : 1

Future2 : 2

Session ID : 98703 

Elapsed Time : 0

Protocol : icmp

Packets Received : 0

Bytes Sent : 236

syslog_host :

Egress Interface : ethernet1/2

Virtual System : vsys1

Destination Zone : trust

syslog_facility : 14

Destination IP :

Flags : 0x19

Receive Time : 2016/02/26 11:15:13

Repeat Count : 2

Generated Time : 2016/02/26 11:15:13

Source Port : 0

Bytes Received  0: 


Source Location :

Ingress Interface : ethernet1/10

NAT Source Port : 0

Application : ping

Subtype : enc


There are many out-of-the-box device parsers developed and maintained by Sumo Logic that can parse logs from common services, such as the ones shown in the diagram below, to process into events so businesses can reach value quickly. Logs can also be produced from home-grown internal systems with their own custom formats of logs. Luckily, Cloud SIEM device parsers can also accommodate these sources of data as well, since they are configurable to accept these custom logs.



You can navigate to any existing parsers in your environment similarly by navigating to “Cloud SIEM” in the navigation pane, then selecting the Parsers tab. When you create a new parser, you’re free to fill the name and provide an optional description in the Basic Details window. Next, in the Configuration window, you can identify the source of logs from which you want to parse.




As a recap: Device Parsers are the first parsers logs interacts with. They are used to parse logs into a list of more digestible key-value pairs called “Event Dictionaries”, which we refer to as “Events” for short. They are device or service specific, meaning each individual source of log data needs a device parser. 

Mapping Parsers are the other types of parser we’ll cover. Mapping parsers are the second layer of parsing log data can encounter. Unlike device parsers, mapping parsers are optional.

Parser Syntax

As a part of Sumo Logic core collection systems, logs are tagged with metadata. One of the metadata fields defined at the collector level is the source type. Referencing this source type in the first stanza using [sourcetype:] is how you reference any data with this metadata tag.

Next, you can define the parsing format. Cloud SIEM Parser configurations identify fields from JSON, CSV, and XML formatted logs. If the logs are not in those formats, REGEX can be used to identify patterns and extract fields from the underlying text.




Although it’s not apparent during the parsing configuration, defining factors with parsing configuration becomes important during the context of an investigation, as shown in the diagram above. Similarly, defining the field types in the parsing configuration becomes important to investigations as shown in the diagram below. During investigation, factor types are displayed as headers and Factors as rows. All events with a defined set of Factors for a given Factor Type will appear below the corresponding header. Events with identical fields values are aggregated together. The amount of events sharing identical field values are indicated in the Count row.





Some, but not all of the information is crucial to understanding a log message or event. Factors are designed to call out specific aspects of an event that tend to be relevant to analysts during security investigations. For example, if you define a parser stanza to call out three parsed fields and tie them to the “Identify” factor (FACTOR:Identity = remote_user, remote_host, user_info), during an investigation, those fields will be prominently displayed under the “Identity” Factor Type and grouped with all other events that match the same three fields. As indicated before, one event can generate multiple factors, and one factor can be composed of multiple events.




There are many preset Factor Types. In addition to Identity and Application Factor Types, there are Endpoint, Network, Error, Alert, Threat, Investigation, and Operational. Security analysts are able to pivot off of these factors given they are configured in parsers for the events relevant in an investigation. Below, we have listed the factor type descriptions:

Alert - Information about events that describe an incident such as correlation events from a SIEM, an alarm from a network monitoring service, or an alert from a device.

Application - Information about events that describe interactions with application services on the network. such as database requests or web requests.

Endpoint - Information about events that identify particular devices or describe changes to those devices such as DHCPack (which binds a MAC address to an IP address), reboot, software install, or storage attachment.

Identity - Indicates which user was associated with authentication events, for example VPN, Radius, OpenID, and OAuth events.

Investigation - If more than one investigation contains queries for the same data close to the same times, investigations other than the current one that contain these same queries appear in this section. This is useful to see if a particular link key is causing multiple alerts, or to see if other analysts are investigating the same link keys.

Network - Information about events that describe the transmission of data across the network such as network translation and firewall transit.

Operational - Information about events related to a host, app, or user but not tied to a specific transaction such os OS reboots.

Threat - Information about suspected threats such as external databases (, and so on), or suspicious behavior flagged by IDS threat detection (PAN firewall), UBA, or other devices.


Links Keys are another tool to provide security analysts pivot points during an investigation. When an analyst clicks on a link key, multiple queries run in the backend to identify events that relate to the link key. The results of these multiple queries are summarized on the next investigation screen, where the results events are aggregated and organized once again by Factor Types. This is what we refer to as a “pivot”, and the analyst is free to make as many pivots as necessary to gather evidence for an investigation.




Link keys in events are categorized by Field Types (and thus can be used as links in Investigation Workflow) using the parser configuration syntax: “FIELD_TYPE:{NameOfField}={FieldTypeAssignment}”. 


Like Factors, link keys are categorized by a finite number of Field Types. The Field Types are: 

  • IP Address (ip) 

  • MAC Address (mac)

  • User (user)

  • Host Name (hn)

  • Network (net)

  • URL (url)

  • Field (field)

  • Hash (hash)

  • Registry Key (registry_key)

  • Geo Location (geo)


The abbreviation denoted in the parenthesis is the text you would reference when writing the parsing configuration syntax.



Parser Configuration Examples





TIME_PARSER = yyyy-MM-dd ‘T’ HH:mm:ss.SSSSSSX

START_TIME_FIELD = timestamp



FIELDS = type, timestamp, elb, client, target, request_processing_time, target_processing_time, response_processing_time, elb_status_code, target_status_code, received_bytes, sent_bytes, request, user_agent, ssl_cipher, ssl_protocol, target_group_arn, trace_id, domain_name, ...






EVENT_BREAK_AFTER = </incident>

LOG_ENTRY_TAG:incident = incidentId, rulesType, severity, repeatCount, organization, status




FIELD_TYPE:remote_host = IP Address

FIELD_TYPE:remote_user = User

FIELD_TYPE:request_url = URL

FACTOR:Identity = remote_user, remote_host




REGEX = %{SYSLOGTIMESTAMP:syslog_timestamp} +(?P<hostname>[^ ]+) +(?P<program_name>[A-Za-z-]*)(\[(?P<pid>.*)\])?: +(?P<_description>.*)

START_TIME_FIELD = syslog_timestamp

Mapping Parsers


Why would you want to parse already parsed events through a mapping parser? Mapping parsers are an extra offered layer of parsing so you don’t need to create a Rule for every device providing data. Mapping parsers will convert field names and values to a set of common terms, or schemas, that normalize event data from multiple device sources. The end result is called an Information Model, and is helpful for simplifying automated downstream processing, including and especially rules processing.

Let’s see an example in the context of a diagram: 



We see two sources of logs that provide similar formatted data: One for PAN Firewall Logs and one for Cisco Firewall Logs. After being processed by their respective device parsers into events, the event field names and values may be communicating similar information, but with slightly different nomenclature. PAN Firewall logs may use the field “src_IP” whereas Cisco Firewall logs may have the equivalent field named “sourceIP”. A mapping parser will apply the field name “Source IP” consistently among all events generated from firewall devices.

To create a new model or see what existing Information Models exist in your environment, click “Cloud SIEM” in the left navigation pane, then click the Information Models tab.



When you create a new parser, you’re free to fill the name and provide an optional description in the Basic Details window. Next, in the Configuration window, you can identify the source of logs from which you want to parse. You can reference an Information Model schema by entering its path in the Model Path field. The Parse Configuration field is where you can enter syntax to define how the incoming logs are parsed. We’ll cover some syntax on how to do that, shortly. You can use the Log Message to import a set of logs you would like to test your Parser Configuration against.


As a recap: Device Parsers are the first parsers log data interacts with. Device parsers create Event Dictionaries, and can define Factors and link keys. Mapping Parsers can be considered the “normalization” layer. Mapping parsers will ensure consistency of field names and values so rules can process sources of data that use different naming conventions.




Like Parsing, Cloud SIEM Rules can be viewed, created, and edited from the Rules tab found in the Cloud SIEM left navigation selection.

A Cloud SIEM rule automates the detection of a given event or multiple events representing a security threat in a given timeframe: Such as the detection of a suspicious short-lived account by joining a “CreateUser” event with a corresponding “DeleteUser” event in a given timeframe. Or the detection of unsuccessful login attempts by a given user in one system, perhaps escalated to a higher priority when it’s followed by a successful login attempt in another system for the same authenticated user. A Cloud SIEM rule is made up of components—filter, join, aggregation, and action—that map to the steps the Rules Engine performs to evaluate a rule and fire actions. The filter and action components are required; the join and aggregation components are optional. The components of rules exert flexible configuration to meet a broad spectrum of detection and response, and as many can be created as needed.



To create a new rule, click Cloud SIEM from the left nav > Rules.




The UI below shows how to create a rule in Sumo Logic. You can see the four components of a rule can be configured here, in the user interface: Filter, Join, Aggregation, and Response Action. There’s additional Basic Detail fields above where you can define the rule name and an optional description.



Filter Component

The first job of a rule is to collect all events that match a filter expression. For example, in a rule to detect suspicious account creation and deletion activity, you might set up two filters: One for “CreateUser” events, and another for “DeleteUser” events. One or more filters can be configured to accept events from many sources.

Join Component

The join component correlates events from separately filtered sources. For example, you could use the join component to compare “CreateUser” and “DeleteUser” events to identify event pairs that occurred within a specified time window for the same account (A given account was created and deleted within x minutes). The join component is required if the filter component of the rule defines more than one filter.

Aggregation Component

An Aggregation component is optionally used if you’d like to gather a defined number events matching the upstream Join and Filter conditions before passing to the Response Action component. 

Response Action Component

When an event or sequence of events matches all defined Filter, Join, and Aggregate components, a corresponding response defined in the Response Action component is said to be triggered. Similar to the Join and Aggregate components, you can define a number of triggers to occur within a timeframe (or session period) before an external response occurs. You have the ability to include as much complexity with triggers as you’d like, such as to have one action for the first trigger and different actions for every subsequent trigger, or commit actions based on time relative to triggers, and more. 

Rule Examples


Above is an example of a simple rule configuration. Many orgs that can utilize Sumo Logic Cloud SIEM are also using other security services that will create alerts on their own, such as IDS or Amazon GuardDuty. Cloud SIEM can handle the collection of alert logs from these systems so all your security sensor can be seen in one place - without the need to log in and out of different environments. A rule can be used to generate an investigation (or a variety of other actions) from alerts generated from these systems. This is done by configuring a rule with a filter to pick up alerts from a given security sensor indicating an alert, for example: Amazon GuardDuty with severities greater than “7”, then using a response action component to generate the investigation. Notice we haven’t used the optional Join and Aggregation components. For purposes of this example, a Join component isn’t necessary since the filter is only picking up logs from one source. Similarly, an aggregation component isn’t necessary assuming you’d like to create an investigation for any GuardDuty alert with this high of a severity. 


Above is another example of a rule that correlates multiple events using a Join component. If you are trying to detect a short-lived account, you are scanning for a “create user” and “delete user” event. Since rules can support multiple filters to receive different kinds of incoming events, one way a rule can be configured for this use case would be to utilize two filters: one for “create user” and one for “delete user”. A Join component can be used downstream of filters to match the events based on having a similar username, and within a specified time range. If any two events match the Filter and Join conditions, a response action component will trigger a response - in this case, to create an investigation.

Notable Events

You may have noticed from the Response Action component, there is the ability to Create Notable Events. A notable event denotes when a condition defined by a rule doesn’t quite necessitate the creation of an investigation, but rather, a new type of event: a Notable Event. Notable events are processed similarly to any other ingested event data. When notable events are created, they are re-ingested into Sumo Logic where they can be queried against in Sumo Logic core, and reprocessed by Cloud SIEM. Because of this, notable events are one way rules can leverage other rules to create a nuanced and comprehensive security picture. 




Since notable events are re-ingested and reprocessed in Cloud SIEM, they can be reprocessed by one or more rules. Rules pick up notable events using their Filter component. Depending on the use-case, it’s reasonable for rules to exist that rely solely on receiving notable event data. 




Diagrammed below a real-world example of how a notable event could be used. A rule, “Rule A”, is configured with a filter component to pick up failed logins, or login attempts. The aggregate component of Rule A groups five events matching the filter to triggering a response action. The response action creates a notable event, which is promptly re-ingested back into Sumo Logic as a new piece of data. Another rule, “Rule B”, is configured with two filter components: One to pick up any notable events create from Rule A, and another to pick up all successful login attempts from the same service. A join component in Rule B joins all notable events and successful login events which share the same user field within 10 minute period. Any return results are passed to Rule B’s response action component, which may create an investigation, or do something as simple as sending email informing a member of the security team to have a conversation with this user about their credentials to determine if their credentials have been compromised.


Lookup Tables

Just like notable events, lookup tables are used as a tool for rules to “talk” with each other. Lookup tables are ideal for storing broader security information about systems or users (what we refer to as “entities”). This could be tracking the security state of users, or lists of whitelisted IP addresses, for example. Lookup table can be created by clicking on the Content Library (folder icon) > Add New > New Lookup.



Lookup tables are maintained manually by people, or automatically with response actions. Response actions can update or remove lookup table rows in response to the triggering of rules. In addition, lookup tables can be used in the filter components of multiple rules to accept incoming events, as indicated on the next image. This means, if configured correctly, lookup tables do not require human intervention to be utilized with rules and stay updated. 


The diagram below is what the filter component utilizing a Whitelisted IP Lookup Table may look like. The rule is designed to detect AWS console logins from IP addresses that don’t exist on the whitelist (untrusted IP Addresses). You may be able to tell from the expression [!lookupContains(id:[LookupTableName], sourceIPAddress=Address)] that this is rule is looking for the existence of an IP address in the lookup. If it doesn’t exist (notice the “not” exclamation boolean), the event is passed to the downstream components of the rules, including a response action to send a message to AWS Admins via Slack webhook message informing them a user from an unauthorized IP logged into the AWS console.


Below is what creating a Cloud SIEM lookup table looks like, which is accessible through the Cloud SIEM Lookup tab. Along with expected fields, like the name and description, you can use a Time To Live option. This functionality tracks lookup table entries, and removes them after a period of time - very useful for getting rid of stale data. You also have the ability to upload tables from your current tracking systems, or create one using the schema only option.


Out-Of-The-Box Content

Cloud SIEM comes with an out-of-the-box automated system to globally monitor entities and assess security states in real-time. This includes a system to track Entity Security States (ESS), and Sumo Attack Lifecycle (SAL). 

What does this look like in Sumo Logic Cloud SIEM? We’ve covered rules, parsers, information models, and lookup tables. Cloud SIEM comes with these components pre-fabricated to be used as a joint Entity Security State and Sumo Attack Lifecycle system to provide real-time security evaluation system for your business. The out-of-the-box functionality includes a comprehensive structure of information models, rules, and notable events used in harmony to detect and record Entity Security States and Sumo Attack Lifecycles in Lookup Tables and notable event data. This information can be used to create pointed investigations organized by urgency of remediation.

Entity Security States


Breaking down Entity Security States: We refer to “entities” as any System (such as IP Address, MAC Address, Host Name, Instance ID) and Users (such as User ID, User Name). We define “Security State” as a measurement of threat intensity. Security States may range from: 0 (Good), 1 (Suspected), 2 (Hostile or Targeted), 3 (Intruder or Compromised).

These three entities types are classified as the Target or Adversary, as well as a measurement of their respective threat as indicated in the table below.



For example: A user’s or a service account’s identity and authentication components (e.g. credentials, a password hash, or keys) have been captured, and the adversary can impersonate the account. How would this be categorized using this ESS table? Answer: The Entity Security State tracking system would categorize this example as a “Targeted User” entity type with a “Compromised” security state. 


As another example: A device has been identified as the source of an attack, but no evidence exists the attack has successfully compromised a system, user, or application. How would this be categorized? Answer: This would be tracked as an “Adversary System” entity. Since no intrusion has occurred, the entity’s security state would be categorized as “Hostile”. 

Sumo Attack Lifecycle

We define Sumo Attack Lifecycle as a list tracking common attack phases. This tracking list relates to other industry-standard attack matrices such as the MITRE’s ATT&CK™ matrix: (© 2018 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.). The following outline reflects the SAL tracking fields available in Cloud SIEM:

  • Recon (Reconnaissance)

  • Delivery

  • Exploit

  • Activities

    • C2 (Command and Control)

    • Collection

    • Concealment

    • Discovery

    • Expand Access

    • Lateral Movement

    • Persistence

  • Objectives Result in Violation of

    • Confidentiality

    • Integrity

    • Availability


For those less familiar with security, the phases of common attack sequences start with reconnaissance, which can include a suspicious user scanning networks for activity, web-scraping, which is useful for preparing for phishing, and spear-phishing attacks, among others. Delivery is a transmission phase when malicious payload is delivered. Delivery could be via email, an attachment to a message, in a document available on a website, etc. Exploit is when the payload is deployed and secures a foothold in a target system, such as a network or application. After the exploit, the attack can expand to the litany of the listed activities. None of these activities are “required” to happen, and can occur in any order. Ultimately the objective of the attack is to affect the CIA triad (Confidentiality, Integrity, or Availability of information). 

Working Together

The combination of the two systems, Entity Security State and Sumo Attack Lifecycle are meant to be used in conjunction to provide a real-time accurate scan of your users and systems, and any attack phase they may be engaged in. This creates a system of security priority at any given point, ensuring the greatest known threats are handled first.



Entity Security State

Sumo Attack Lifecycle

Resulting Priority

Security Incident A

Adversary User Intrusion

Command & Control Attack Phase

Address ASAP

Security Incident B

Dormant User

No Activity

No action needed


Investigation Workflow


Working from the Cloud SIEM architecture diagram below, we’ve reached the Burndown repository where any created investigations go for further human analysis. 




Investigation Workflow is designed to automate and rapidly execute searches and analytics to help security analysts expediently investigate and remediate incidents. This is the value businesses derive from Sumo Logic Cloud SIEM. The longer security exposure and exploitation exist, the more damage is incurred on the business. Value of Cloud SIEM comes from the  reduced cost of security incidents through quicker Mean-Time-To-Detection and Response (MTTD/MTTR). 

Investigation Workflow is broken up into three parts: The Burndown Tab, where all new and in-process investigations can be viewed. The Investigation Tab, where an investigations are conducted using pre-corrleted steps. And the Investigation History Pane, where details about the investigations are kept and investigation reports are generated.

When an analyst investigates an issues in Cloud SIEM, they use a series of pivots to gain a holistic understanding of the security issue. A pivot can be as easy as one click on a link key, and by default, each pivot represents multiple chaining queries from the link key of the previous pivot. The results of the query are organized compactly for rapid insight to determine the next step of investigation. The investigation engine can track lateral movements to create a branching investigation. Analysts have the ability to add notes for each pivot in the process, or the investigation as a whole. At the end of an investigation, you can generate a report directly from Cloud SIEM. Much of the content used to author the report is generated from the investigation history, which includes an overview diagram of each pivot, relevant events, and any additional pivot comments and summary text the analysts has included. 



The Burndown tab is your entry point to Investigation Workflow—it portrays a list of new and in-progress investigations for an organization. It’s accessible by clicking New from the interface, then selecting Burndown from the dropdown selection. A tab appears showing a list of all new and in-progress investigations generated from a given date. 


Burndown Filters

Taking a closer look at the top selection (image below), you have the ability to filter by a variety of variables. From left to right, you can use the button selection to show All investigations, new investigations by clicking Burndown, and any investigations assigned to you. From the dropdown items, you can filter by Assignee and/or by investigation Status. The date selection will filter all investigation create on or after a given date. 


Creating Investigations

Not all investigations need to be created from the downstream automated Cloud SIEM processes. If you want to create an investigation manually (one not generated automatically from a rule trigger), select + Investigation. You’ll be prompted to enter some values to define the investigation. 


Note: (Optional) Enter a short note that will be associated with the initial pivot.

Start: Enter the start date for the investigation.

End: Enter the end date for the investigation. 

Link Keys: Enter one or more link keys. As you enter the value, Investigation Workflow will suggest a link type. Some  link types, like user and host names, are ambiguous. If the wrong link type is shown, select the correct type from the pulldown. You must enter at least one link key.

Severity: (Optional) Enter the severity of the investigation. 

Type: You can enter any text desired. 

Description: (Optional) Enter a description of the investigation.

Chain: (Optional) If you choose this option, Investigation Workflow will run secondary queries on all the link values in the factors returned by your primary query.



Investigation Details

The columns provide broader information about each investigation, as shown below:



View: This column appears when All or Assigned to Me is selected. For investigations that are in progress this column contains an eye icon. You can click the icon to view the investigation. For investigations that have not been claimed, whose status is “New”, this column is empty.  

Created: The date that the investigation was created, which for automatically generated investigations is determined by the underlying log event.  For investigations that were created from scratch, it is the date that the investigation was created.

Severity: The severity of the investigation. For investigations that Investigation Workflow created for an alert event, the severity value comes from the underlying log event.

Type: Describes the nature of the problem to investigate, for instance “Malware Detected” or “Failed Password Attempts”. This is determined from the log data. 

Alert: Contains the Alert factor that Investigation Workflow derived from the underlying log event.

Status: The current status of the investigation. For a list of values, see Investigation Status Values.

Assignee: The user to whom the investigation is currently assigned.

Assigning Investigations

There are two methods of assigning existing investigations. The first method is to highlight an investigation by clicking on its row. When you highlight an investigation, an Actions dropdown appears in the top menu. Click Actions, then you can click Assign to assign to someone other than yourself, or you can click to Change Status and make a selection, which will assign a new investigation to you as well as make the status change. The second method is to click a link keys, which will simultaneously assign the investigation to yourself and create the first Pivot. When the investigation is open, you can witness an icon appear next to the corresponding investigation in the burndown.





Working With Investigation Interface

This concept has been covered, but bears repeating. This is the user interface for an active investigation. This is where the backend configuration of Cloud SIEM comes together to provide rapid context setting. Factor types are displayed as headers and Factors as rows. All logs with a defined set of Factors for a given Factor Type will appear below the corresponding header. Multiple logs with the same values for the same set of factored fields are grouped together. The amount of logs composing each factor is indicated in the Count row. For example, I could describe the last entry of the endpoint factor by saying “there were 49 logs sharing the same field values indicating a unique endpoint factor.” These 49 events can be spread across different systems provided the mapping parsers have been configured to provide a consistent schema.



Hovering over each factor row reveals a plus icon on the left side. Clicking the plus icon opens the option to view the event dictionaries that compose the factor by clicking Details, or their corresponding raw logs by clicking Raw.


On the right side of the investigation window, we see the Investigation Status Pane. This pane gives details about the investigation and provides areas for the analyst to include more information. As the investigation is conducted through pivots, this pane become more populated with investigation history.


Pivot Tab

By default, the Pivot tab is open. This tab shows each pivot (or step) in the investigation. A pivot can be created by clicking a link key, or by clicking the + icon in the top right corner to create a more customized pivot, complete with a time range, one or more link keys and the option to Chain the pivot. Running a chained pivot runs a primary query for factors that contain that link key. Then, Investigation Workflow runs a set of secondary queries:  one for each of the unique field values in the factors returned by the primary search. This is referred to as a chained search.


Moving back over to Investigation Status Pane, next to each pivot there’s a comment bubble icon. Clicking this icon reveals a text field where you, as an analyst, can include any written comments. This may be a justification for why you chose to make a certain pivot in the investigation or other plainly written details relevant to the pivot.

Notes Tab

One tab over is the Notes tab. Similar to pivot comments, the notes field give you the ability to enter any details you would like to include in the investigation. However, the notes field is meant to provide details of the investigation as a whole and are not published in generated reports. It should be used as a tool to track internal details of an investigation.


Reports Tab

Next tab over is the Reports tab. You can generate as many reports as needed for an investigation by clicking the + icon. You are given the option to make the report Public, or enforce Authenticated access. The report can be generated in HTML  or PDF format.




Summary Tab

Similar to pivot comments, Summaries are included in any reports generated from the previous tab for the investigation. Similar to notes, text entered in this field are meant to address the overall investigation. Apart from being included in the investigation, it is not context-specific unless denoted by the author.


Report Generation

The report is the product of investigation. This is an example of an automated report generated from the investigation history pane, including a diagram of pivots, any details written in the pivots’ comments, and the summary written by the investigator. The HTML report is easy to navigate because it drills down to your report results at any point of the investigation.The viewer of the report can click on any pivot and see corresponding details highlighted.