Security Operations email parsing
Summarize
Summary of Security Operations email parsing
Security Operations email parsing enables ServiceNow customers to automatically generate Security Operations records—such as security incidents, vulnerabilities, and observables—by processing emails sent from external detection systems like malware detectors, firewalls, and threat intelligence tools. This capability facilitates seamless integration of external security data into ServiceNow, accelerating threat detection and response workflows.
Show less
How Email Parsing Works
- Each Security Operations plugin (e.g., Security Incident Response, Threat Intelligence, Vulnerability Response) has a designated email address (emailto) where external systems send emails for parsing.
- Incoming emails are stored in an email events table and matched against configured email parsers.
- Matched emails trigger transform and duplication rules that create or update Security Operations records and link the email to the record.
- Unmatched emails are accessible for review to build or improve parsers, with a Reprocess action to retry parsing after adjustments.
- Duplication rules control handling of multiple emails related to the same issue, specifying whether to create no new record, a child record, or update existing records and defining which fields to update.
- By default, email event records are deleted after 30 days to manage storage.
- Email parsing works alongside platform inbound actions but does not support setting values on indirect fields like sysjournalfield entries.
Handling Multiple Records in a Single Email
Emails from external systems can report multiple affected items in one message. The email parser supports defining a Record Separator to split the email into multiple sections, each evaluated separately to create individual Security Operations records. For example, a malware report listing multiple infected systems can be parsed into separate incident records.
- Field transforms can be configured to extract common data (e.g., Malware Hash, Malware Name) from header or footer sections applicable to all records.
- Section-specific data (e.g., System, IP address, Status) is extracted by field transforms searching within each separated record section.
- Records are only created for sections containing section-specific data; header sections without unique item data do not generate separate records but provide shared information.
Configuration and Practical Use
- Customers can create and edit email parsers within Security Operations to tailor how emails from their external detection tools are processed.
- Transforms allow mapping email content into Security Operations fields to accurately represent security events and vulnerabilities.
- Proper configuration of separators and field transforms ensures efficient and accurate creation of multiple records from complex email reports.
Benefits for ServiceNow Customers
- Automates ingestion of external security alerts into ServiceNow, improving response times.
- Reduces manual data entry and potential errors by parsing structured email content directly into records.
- Supports complex email formats reporting multiple issues, enabling comprehensive tracking within Security Operations.
- Allows ongoing refinement of parsers via unmatched email review and reprocessing to improve integration quality.
Generate new Security Operations records from external detection systems using Email Parsing. This feature provides a method for integrating information from external tools such as malware detection, vulnerability detection, firewalls, threat intelligence, and more.
Any system that can send an email, can create Security Operations records, for example, security incidents, requests, vulnerable items, vulnerabilities, security incident observables, attack methods, and more.
All Security Operations plugins (Security Incident Response, Threat Intelligence, and Vulnerability Response) have a property (email_to) that defines the email address where external integrations should send emails to, to be parsed by the email parsers. See for more information.
Email sent to any of the Security Operations email addresses is stored in an email events table. These emails are processed to determine whether they match any email parser.
Emails that have a match are flagged and the transform and duplication rules create or
update a Security Operations record.
The email is linked to that record and flagged as matched.
Emails that do not match are listed in Unmatched Emails as a Security Operations record. They can be reviewed to help build email parsers to handle these emails. A Reprocess action allows you to run the unmatched email through the parsers again. The original email log is linked to that record.
By default, email events are deleted after 30 days.
External detection systems (malware detectors, vulnerability, and so on) can send emails that report on multiple items at one time. The email parser supports separators within the email.
For example, a malware detector could send you an email report about all systems within your network infected by one particular malware with information about the malware first, followed by a list of the systems affected.
Field Transforms pull in data from each section. If something in the header or footer of the email applies to all records, such as Malware Hash, Malware Name, and Type in this example, the field transform for them should set Search for value to a value that searches within the email body either At the start of a line in the email body or Anywhere in the email body.
Field Transforms must be set to search At the start of a line within the record section or Sec for data that is defined within each section, such as System, IP address, or Status. The record section options are only available when there is a record separator defined within the email transform.
When parsing an email with a separator defined, records are only created for sections with at least one piece of section-specific data.
In this example, three records are created, even though there are four sections defined. The first section is a header, and it lacks anything specific to only one system. If any of the fields within the first section were filled in (System, IP, or Status), then a record would be created for that section, as well.