FortiSIEM: Log Processing and Search Operators

• FortiSIEM processes every log it receives including pulled or collected, security or performance information.

FortiSIEM Log Processing

• Log processing includes parsing data, populating event attributes, and enriching other attributes.
• Log processing does not include encrypting the data.

Structured Search Operators

• The "=" operator expects a single value.
• The "CONTAINS" operator searches for the presence of a keyword in an attribute.
• The "BETWEEN" operator searches for attribute values within a specified range.
• The "IS [NULL]" operator checks if an attribute has no value.
• The "REGEX" and "NOT REGEX" operators match values based on regular expression patterns.
• Operators like "EQUAL TO", "NOT EQUAL TO", "IN", and "NOT IN" allow referencing CMDB groups in structured searches.

Watch Lists

• Watch Lists are containers of similar items referenced in searches, rules, and reports.
• Watch Lists can be populated dynamically by triggered rules or manually.
• Watch Lists have an expiry field that can be set to a specific date or "Never expires".

FortiSIEM Integrations

• FortiSIEM integrates with Osquery to allow users to query operating system information in a structured format.

Nested Queries

• A nested query (or subquery) is a query embedded within another query.
• In a nested query, the inner query (subquery) runs first.
• Nested queries can be event queries or CMDB queries.
• A use case for nested queries involves correlating failed and successful logons from the same source IP.

Rule Types

• The three types of rules in FortiSIEM mentioned are event-based, baseline, and UEBA.
• Rules in FortiSIEM track events to trigger incidents based on security, performance, and availability issues.
• Rules are composed of subpatterns that track events over a specified time window and are evaluated in memory.
• The phRuleWorker process evaluates rule data in parallel in FortiSIEM.
• The phRuleWorker process evaluates rule data every 30 seconds.
• When defining a rule action to generate an incident, event attributes and aggregations can be selected from matching subpattern events to populate incident details.
• Aggregate functions in subpattern conditions perform calculations on matching data and return a single result.
• Logical operators like AND, OR, NOT are used for defining conditions with multiple subpatterns.
• When creating rules from analytics searches, COUNT(Matched Events) can be selected as the aggregate function to count the number of events.
• Aggregate Condition defines the number of event matches required for a rule to trigger.
• A single subpattern rule is constructed to evaluate a single condition that has occurred.
• Defining a relationship between multiple subpatterns in a rule correlates events using shared attributes between subpatterns and reduces false positives.
• When defining conditions for a multiple subpattern rule, a relationship must be defined if multiple subpatterns are used.
• How many matching events occur should be considered when defining the rule time window for a subpattern because the matching events are kept in memory.
• When creating rules from analytics searches, FortiSIEM uses the analytics search filter conditions to create the rule subpattern filter conditions.
• The group by attributes are defined in a subpattern that you want to have present in the incident source, target, or detail are the Group by attributes.

Performance Metrics

• FortiSIEM handles collecting performance metrics from a device with multiple components, like a server by ensuring each component (disk, interface) produces a unique event.
• Each performance message is mapped to an event type.
• Setting static hard-coded thresholds for performance metrics per device or globally is a tedious process because it requires manual tuning of the system.
• FortiSIEM builds distinct baselines for hours of the weekdays and weekends.
• Hourly buckets are used to store data for specific baselines, summarized every hour by the supervisor.
• The supervisor summarizes results and stores baseline data in the SQLite database every hour.
• The value defined in the phoenix_config.txt file for 'Num Points Relevance in Rules' determines the minimum number of data points required before baseline rules are triggered.
• The expression 2*STAT_AVG(AVG(Memory Util):109) in a baseline rule means trigger if current average memory utilization is 100% (2 times) more than the statistical average.
• The statistical average of matching events cannot be displayed in an incident detail based on a baseline rule trigger.

Incident Handling

• According to NIST SP 800-61, incident handling is defined as a lifecycle with four phases.
• The MITRE ATT&CK framework is a detailed mapping of adversary behavior framework used for threat intelligence and classification.
• The MITRE ATT&CK framework consists of 14 tactics categories, described as "technical objectives" of an adversary.
• The four categories of incidents mentioned in the context of FortiSIEM's Incidents dashboard are Security, Performance, Availability, and Change.
• The MITRE ATT&CK dashboard view classifies security events detected by FortiSIEM into MITRE ATT&CK categories.
• The primary purpose of the Incident List view in FortiSIEM is to enable users to search incidents and take actions.
• The purpose of the Incident Name option when refining the incident List view is to condense incidents into single rows with a count to reduce noise and understand occurrences.
• An incident achieves the 'Auto Cleared' status when a clear condition defined for the rule is met.
• For performance and availability incidents, if an incident is not triggered again within 24 hours, the system may change the status to 'System Cleared' to conserve system memory, the 24-hour period can be extended using a back-end configuration file.
• The purpose of the mitigation library in FortiSIEM is to provide pre-built remediation scripts to take action on devices in response to incidents.
• Besides using the provided remediation scripts, users can add scripts to the mitigation library by creating and adding their own scripts from the FortiSIEM GUI.
• The raw event messages that created the incident can optionally be included when exporting single or multiple incidents as a PDF report.
• The Risk view on the Incidents tab shows entities (Devices and Users) ordered by risk score.
• The UEBA incident dashboard shows UEBA incidents created by the AI module based on alerts received from FortiInsight.
• In the MITRE ATT&CK view, the Rule Coverage view provides an overview of the tactics and techniques that FortiSIEM rules cover.
• In the MITRE ATT&CK Incident Coverage view, the bolded number under each tactic in the main row header indicates the number of incidents associated with a specific tactic.
• The MITRE ATT&CK Incident Explorer provides a host-centric, interactive ATT&CK view.
• When defining a pattern-based clear condition for a rule, association between the clear condition incident attributes and the original rule incident attributes must be defined to ensure the cleared incident is associated with the original rule.

FortiSIEM Remediation

• FortiSIEM Remediation responds to detected network and security threats and operational device conditions.
• FortiSIEM records all successful and failed remediation attempts in back-end events, these can be queried using event type PH_INCIDENT_ACTION_STATUS.
• The system notifies users when an incident is cleared automatically by a rule's clear condition by sending an email with "[Cleared]" in the subject header, provided the automation policy allows clear notifications.
• The system notifies users when an incident is cleared manually by an operator by sending an email with "[Cleared Manually]" in the subject header, provided the automation policy allows clear notifications.
• In policy definitions for automation, users can specify whether they want to be notified when an incident is cleared in the incident automation policy.
• The possible incident status states mentioned, including those related to clearing are Active, Auto Cleared, System Cleared, Cleared Manually.
• The ability to query operating system information in a structured format using osquery allows users to check specific security configurations like the status of Windows command-line auditing, this is shown in the sources by checking the registry for a specific key value.
• In the CMDB Lookups and Filters lesson objectives, referencing the CMDB data in structured searches is listed as something you should be able to do after completing the section.
• Structured search allows you to filter data in a structured way using operators.
• When creating a rule from an analytics search, the analytics search display conditions are used to create the rule Group by conditions.
• "OR" is the Boolean operator that should be used between two conditions checking if the Reporting IP equals one specific value OR another specific value.
• "IS" is the operator that must be used in a search condition Attribute: User Operator: ? Value: NULL.