# Module 21: Evaluating Alerts :::success Here is a cheat sheet generated from the course content using ChatGPT. It recaps the main concepts of each module, definitions and examples. At the end of (almost) each part, you will find a link to online related flashcards. ::: ### 21.1 Sources of Alerts Cheat Sheet #### 21.1.1 Security Onion - **Overview**: Open-source suite for Network Security Monitoring (NSM) running on Ubuntu Linux. - **Core Functions**: - Full packet capture - Intrusion detection (network and host-based) - Alert analysis tools - **Deployment**: Can be installed as a standalone or sensor/server platform. - **Components**: Includes tools from corporations like Cisco but available as open source. --- #### 21.1.2 Detection Tools for Collecting Alert Data - **Security Onion Architecture**: - **Data Layer**: PCAPs, session data, host logs, syslog, alert data, etc. - **Detection Layer**: Tools like Snort, Zeek, Suricata, OSSEC, and Wazuh. - **Analysis Layer**: Sguil, Wireshark, Kibana. ![image](https://hackmd.io/_uploads/Sk3XFCFNkl.png) - **Key Tools**: - **CapME**: Web application for viewing PCAP transcripts via tcpflow/Zeek. - **Snort**: Signature-based NIDS sponsored by Cisco with automatic rule updates via PulledPork. - **Zeek**: Behavioral-based NIDS using policies instead of signatures. - **OSSEC**: Host-based intrusion detection system requiring agents on hosts. - **Wazuh**: Replacement for OSSEC with extended features for endpoint protection. - **Suricata**: NIDS with native multithreading and reputation-based blocking. --- #### 21.1.3 Analysis Tools - **Sguil**: High-level console for investigating alerts, serving as a starting point for analysis. - **Kibana**: Interactive Elasticsearch dashboard for NSM data queries and visualizations. - **Wireshark**: Packet capture analysis integrated into Security Onion. - **Zeek**: Enables in-depth network traffic analysis. --- #### 21.1.4 Alert Generation - **Overview**: Alerts are notifications from NSM tools and security devices. - **Five-Tuple Information**: - Source IP (SrcIP) - Source Port (SPort) - Destination IP (DstIP) - Destination Port (DPort) - Protocol (Pr) - **Sguil Console**: - **ST (Status)**: Real-time (RT) and color-coded by priority. - **CNT**: Count of correlated events for same source/destination. - **Sensor**: Reporting agent, e.g., OSSEC or Snort. - **Alert ID**: Identifier for sensor and event number. - **Event Message**: Triggering text from the rule. --- #### 21.1.5 Rules and Alerts - **Sources**: - NIDS (Snort, Zeek, Suricata) - HIDS (OSSEC, Wazuh) - Asset monitoring (PADS) - Syslog and HTTP/DNS/TCP transactions - **Alert Formats**: Vary by source (e.g., Snort vs. OSSEC rules). - **Sguil Alerts**: Investigate rule triggers and event details. --- #### 21.1.6 Snort Rule Structure - **Structure**: - **Rule Header**: Specifies action, protocol, source/destination addresses, ports, and direction of flow. - **Rule Options**: Contains alert messages, metadata, and packet payload criteria. - **Rule Location**: Path and line number of rule (added by Sguil). ![image](https://hackmd.io/_uploads/BkcoF0KV1e.png) - **Components**: - **Rule Header**: - Action: Example `alert` - Protocol: Example `ip` - Source/Destination: Example `any any -> any any` - **Rule Options**: - Alert message: `msg:` - Packet content: `content:` - Class type: `classtype:` - Unique ID: `sid:` - Rule revision: `rev:` - **Sources for Snort Rules**: - GPL: Older rules from Sourcefire. - ET: Emerging Threats rules. - VRT: Cisco Talos-maintained rules. >[!Warning]Recap >Security Onion is an open-source suite of Network Security Monitoring (NSM) tools that run on an Ubuntu Linux distribution. Security Onion tools provide three core functions for the cybersecurity analyst: full packet capture and data types, network-based and host-based intrusion detection systems, and alert analyst tools. Some components of Security Onion are owned and maintained by corporations, such as Cisco and Riverbend Technologies, but are made available as open source. > >Security Onion contains many components. It is an integrated environment which is designed to simplify the deployment of a comprehensive NSM solution. Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools: Sguil - serves as a starting point in the investigation of security alerts. Kibana - Kibana is an interactive dashboard interface to Elasticsearch data. It allows querying of NSM data and provides flexible visualizations of that data. The Wireshark packet capture application is integrated into the Security Onion suite. Zeek is a network traffic analyzer that serves as a security monitor. Zeek inspects all traffic on a network segment and enables in-depth analysis of that data. > >Security alerts are notification messages that are generated by NSM tools, systems, and security devices. In Security Onion, Sguil provides a console that integrates alerts from multiple sources into a timestamped queue. A cybersecurity analyst can work through the security queue investigating, classifying, escalating, or retiring alerts. > >Alerts will generally include five-tuples information when available, as well as timestamps and information that identifies which device or system generated the alert. Depending on the security technology, alerts can be generated based on rules, signatures, anomalies, or behaviors. Alerts can come from a number of sources, such as NIDS, asset management and monitoring, HTTP, DNS, and TCP transactions, and Syslog messages. > >Snort is a Network Intrusion Detection System (NIDS). It is an important source of the alert data that is indexed in the Sguil analysis tool. It uses rules to identify potentially malicious traffic. Snort rules consist of two sections: the rule header and the rule options. The rule header contains the action, protocol, source and destination IP addresses and netmasks, and the source and destination port information. The rule options section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken. The structure of the options section of the rule is variable. ### 21.2 Overview of Alert Evaluation Cheat Sheet --- #### 21.2.1 The Need for Alert Evaluation - **Evolving Threat Landscape**: - New vulnerabilities and threats emerge constantly. - Attack surfaces change with evolving user and organizational needs. - **Challenges**: - Threat actors vary exploits to evade detection. - Impossible to design measures that prevent all exploits. - Alerts often require skilled analysts to verify incidents. - **Alert Prioritization**: - Overly conservative detection rules are preferred (better to over-alert than miss incidents). - Tier 1 analysts investigate alerts via tools like: - **Sguil**: Main alert investigation tool. - **Zeek**: Behavior-based traffic analysis. - **Wireshark**: Packet capture and analysis. - **Kibana**: Interactive dashboards for data visualization. - **Figure Reference**: Sguil as the central interface connecting Kibana, Zeek, and Wireshark. --- #### 21.2.2 Evaluating Alerts - **Alert Classifications**: - **True Positive**: Alert correctly indicates an incident. - **False Positive**: Alert is triggered by benign activity. - **True Negative**: No alert issued, and no incident occurred. - **False Negative**: No alert issued, but an incident occurred (most dangerous). ![image](https://hackmd.io/_uploads/ByHU9CK4kg.png) - **Implications**: - **True Positives**: Desired, but may require escalation. - **False Positives**: Costly in terms of time; indicate tuning needs. - **True Negatives**: Desirable; reflect accurate alerting systems. - **False Negatives**: Dangerous; indicate undetected exploits. - **Analyst Responsibilities**: - Escalate true positives for further investigation. - Inform security teams about excessive false positives. - Perform Retrospective Security Analysis (RSA) for past data using updated threat intelligence to uncover false negatives. --- #### 21.2.3 Deterministic Analysis and Probabilistic Analysis - **Deterministic Analysis**: - Assumes all steps of an exploit are known and must succeed for the exploit to work. - Provides a **worst-case scenario**. - Suitable for known vulnerabilities with standardized characteristics (e.g., fixed port numbers). - **Probabilistic Analysis**: - Estimates the likelihood of exploit success based on the probability of each step succeeding. - Useful for real-time analysis where multiple variables are unknown. - Focuses on the **most likely paths** for exploits. - Accounts for dynamic or unpredictable variables (e.g., dynamic port numbers). - **Summary**: - **Deterministic**: Best for static, known threats. - **Probabilistic**: Best for dynamic, real-time scenarios with uncertainties. :::danger **Check Your Understanding** :ballot_box_with_check: You can find the answers to the quiz by clicking [here](https://itexamanswers.net/26-2-5-check-your-understanding-identify-the-alert-classification-answers.html). ::: >[!Warning]Recap >The threat landscape is constantly changing as new vulnerabilities are discovered and new threats evolve. As user and organizational needs change, so also does the attack surface. Threat actors have learned how to quickly vary features of their exploits in order to evade detection. Detection rules should be overly conservative. It is better to have alerts that are sometimes generated by innocent traffic, than it is to have rules that miss malicious traffic. For this reason, it is necessary to have skilled cybersecurity analysts investigate alerts to determine if an exploit has actually occurred. > >Security incidents are classified using a scheme borrowed from medical diagnostics. This classification scheme is used to guide actions and to evaluate diagnostic procedures. The concern is that a diagnosis can be either accurate, or true, or inaccurate, or false. Alerts can be classified as True Positive (The alert has been verified to be an actual security incident) or False Positive (The alert does not indicate an actual security incident). An alternative situation is that an alert was not generated. The absence of an alert can be classified as: True Negative (No security incident has occurred. The activity is benign.) and False Negative (An undetected incident has occurred). True Positives and True Negatives are desirable. False Positives are not desirable but unavoidable, and False Negatives are dangerous. > >Statistical techniques can be used to evaluate the risk that exploits will be successful in a given network. This type of analysis can help decision makers to better evaluate the cost of mitigating a threat versus the damage that an exploit could cause. Two general approaches that are used to do this are deterministic and probabilistic analysis. Deterministic analysis evaluates risk based on what is known about a vulnerability. It assumes that for an exploit to be successful all prior steps in the exploit process must also be successful. This type of risk analysis can only describe the worst case. Probabilistic analysis estimates the potential success of an exploit by estimating the likelihood that if one step in an exploit has successfully been completed that the next step will also be successful. Probabilistic analysis is especially useful in real-time network security analysis in which numerous variables are at play and a given threat actor can make unknown decisions as an exploit is pursued.