Alert Processing (System Workflows)

The Alert Processing process extracts key observables from raw alert data using predefined templates in the Alert Templates Table. The system checks whether each alert has already been processed and flags unprocessed alerts for further attention, ensuring efficient and accurate data handling.

---

"Alert Template" Table

The Alert Template Table plays a critical role in the alert processing phase. Each alert requires a corresponding template to define how the system extracts observables from the raw payload. Without a predefined template, the system cannot process the alert.

The table contains multiple fields, including the Vendor name, the Alert Name, the Template itself, a description, and the Case Type. This structure ensures that the system knows how to process different types of alerts from various vendors.

Here’s how the templates work:

1. Unique Template for Each Alert

   • Every alert must have a unique template associated with it. Alerts cannot be processed unless they have an existing template in the system.

2. Templates are Defined Using JSON

   • Templates are structured as JSON entries. These entries define the "path" within the alert payload where each observable can be located, along with its corresponding type (e.g., IP Address, Username, File Hash).

3. Template JSON Format Example

   • Below is an example of a template in JSON format. The key (e.g., device.external_ip) represents the location of the observable in the alert payload, while the value (e.g., "IP Address") specifies the type of observable.

{
  "agent_id": "Agent ID",
  "device.external_ip": "IP Address",
  "device.local_ip": "Local IP Address",
  "device.hostname": "Target Hostname",
  "user_name": "Username",
  "sha256": "File Hash",
  "user_principal": "Username",
  "parent_details.sha256": "File Hash"
}

Creating Custom Templates Based on Alert Payloads

1. Understand the Alert Structure
   • Before creating a custom template, you need to examine the alert payload. The payload contains important information, such as the sender's email address or the device information, which will be extracted as observables.

In this example, the alert payload looks like this:

{
  "@odata.etag": "W/\"CQAAABYAAABOkmv/qhPtT7Ka/WdrM4/xAAHdWH1R\"",
  "id": "awdawdawdawda-qhPtT7Ka-WdrM4-xAAAAAAEMAABOkmv-qhPtT7Ka-WdrM4-xAAHd62AUAAA=",
  "receivedDateTime": "2022-04-19T18:33:43Z",
  "sender": {
    "emailAddress": {
      "address": "frodo@middleearth.com",
      "name": "Frodo Baggins"
    }
  },
  "subject": "Mordor-47 CS Sensor installation"
}

2. Identify the Observable

   • In this example, we want to extract the email address (frodo@middleearth.com) from the alert payload and store it as an observable of type User Email.

   • The email address can be found under:

   "sender.emailAddress.address"

3. Define the Observable Type

   • Next, we need to determine the type of the observable. In this case, we are extracting an email address, so the type will be "User Email".

4. Create the Path in the JSON Template

   • The path is the location within the alert payload where the observable can be found. The path follows a dotted notation, starting from the root of the JSON object and navigating to the value you want to extract.
   • In this example, the path to the email address is

   "sender.emailAddress.address"

5. Build the Custom JSON Template

   • Now that we have both the observable type and path, we can build the JSON template. The template will map the path in the alert payload to the observable type.
   • The custom template looks like this:

   {
     "sender.emailAddress.address": "User Email"
   }

6. Apply the Template for Other Observables

   • The same process can be repeated for other observables in the alert. For example, if you wanted to extract the sender's name, you would identify the path ("sender.emailAddress.name") and define the appropriate type (e.g., "User Name").

7. Test the Template

   • After creating the template, test it with similar alerts to ensure that the system correctly extracts the observables based on the path and type you defined.
   • For this example, the final JSON template looks like this:

   {
     "sender.emailAddress.address": "User Email"
   }

This template tells the system to extract the email address from the alert payload and label it as a User Email observable.By following these steps, you can create custom JSON templates for different observables in your alert payloads, ensuring that key data is accurately extracted and categorized for case management.

---

"On New Table Record- Process Alert" Workflow

This workflow handles the complete lifecycle of an alert, from its ingestion and processing to response actions, aiming to streamline alert triage, deduplication, enrichment, and response.

---

Subflow 1- Extract Observables

Using specific templates from the alert template's table, this subflow parses the alert's raw data to identify observables—data points like IPs, URLs, and file hashes that represent key entities in the alert.

---

Subflow 2.1- Get Duplication Rule Workflow

This Subflow determines the most suitable deduplication rule for a given alert, following a hierarchy of priority. It first checks for a specific rule associated with the alert. If no specific rule is found, it attempts to retrieve a universal rule for the vendor. If no universal rule exists, one will be created using "Name" as the default deduplication parameter.

---

Subflow 2.2- Check for Case Duplicates

This subflow identifies if the alert has any duplicates in any open case or in a case that has been closed . If duplicates are found, it provides the case ID, flags whether the case should be reopened, and if no duplicate exists.

note

• If “Name” is selected as a deduplication parameter, it will cancel any other parameter and be used exclusively for the deduplication.

• If multiple observables are valid for deduplication (e.g., the deduplication parameter is "User" and multiple users are linked), the first case found will be used. If there are multiple cases, the most recently updated one will be selected.

---

Subflow 2.3- Link Alert to Existing Case

This subflow links the alert, along with its associated observables, to the identified case. It also updates the case severity to match the alert's severity if the alert's severity is higher.

---

Subflow 2- Create Case

---

Subflow 3-Enrich Observables"

This workflow is designed to identify observables that have not yet been enriched and perform the necessary enrichment tasks. It systematically processes each observable, ensuring that the correct subflows are triggered based on the type of observable (Users, Devices, or IOCs).

---