\chapter{Background}
In order to fully understand the importance and technical foundations of Network Detection and Response (NDR) systems, it is essential to first revisit the key concepts and principles that underpin the broader field of network security.\newline
This chapter provides an overview of formal definitions and taxonomies discussed throughout the academic course in Cybersecurity, with particular reference to materials developed by Prof. Fulvio Valenza~\cite{valenza-fundamentals}, as well as a review of Zeek, Suricata and the ELK stack, the main technologies used and evaluated throughout the activity.

\section{Threats, Vulnerabilities, and Attacks}
\subsection*{Threats}
\begin{quote}
``Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.''~\cite{valenza-fundamentals}
\end{quote}
This definition, provided by NIST SP 800-30 Rev.1 and presented in Prof. Valenza's slides, establishes a comprehensive scope for understanding what constitutes a threat in modern networked systems.

\subsection*{Vulnerabilities}
\begin{quote}
``A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.''~\cite{valenza-fundamentals}
\end{quote}
This captures the essence of what makes a system exploitable and underlines the relationship between a vulnerability and the potential threats that could exploit it.

\subsection*{Attacks}
\begin{quote}
``Any kind of malicious activity that attempts to collect, disrupt, deny, degrade, or destroy information system resources or the information itself.''~\cite{valenza-fundamentals}
\end{quote}
This definition from NIST (as cited in the lecture slides) emphasizes the intent behind attacks, setting them apart from threats and vulnerabilities as active, often intelligent, adversarial actions.\newline
These three formal definitions establish the knowledge behind the broad scope of network security monitoring, which will be discussed following prof. F. Valenza lectures' slides~\cite{valenza-nsm}.

\section{Network Security Monitoring}
Network Security Monitoring is the practice of collecting, analyzing, and escalating indications and warnings to detect and eventually respond to threats spreading within a network. It is a discipline, rather than a mere toolset, and represents a core pillar of modern cybersecurity operations, granting operational visibility over a network and helping to improve the defenses of a networked environment. \newline
A fundamental element of NSM is \textbf{security event logging}, which can be described as the continuous recording of events that may have relevance to the confidentiality, integrity or availability of systems. It is what we mainly rely on for real-time detection of malicious activity across the network; it often comes in handy to build attack timelines and complex scenarios through retrospective analysis, providing support for both compliance and incident response activities, as well as crucial details for post-response reporting. \newline
A distinction must be mentioned here:
\begin{quote}
“Security event: An occurrence considered by an organization to have potential security implications to a system or its environment. Security events identify suspicious or anomalous activity. Events sometimes provide indications that incidents are occurring.”~\cite{valenza-nsm}

“Security incident: An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system [...] or constitutes a violation or imminent threat of violation of security policies.”~\cite{valenza-nsm}
\end{quote}
Although events are numerous and may only suggest abnormal behavior, incidents require response and escalation. The ability to classify one from the other is what turns raw log data into actionable intelligence, a key function of both NSM and the detection engines found in Security Onion.
\clearpage

\section{Log Lifecycle}
The logging activity usually follows 4 main steps:
\begin{enumerate}
    \item Log generation: logs are produced by network and/or system components. In our case, a Security Onion standalone node will behave as the main source of logs.
    \item Log transmission: logs are transmitted from sources to a centralized system. In our case, transmission does not actually occur since Security Onion is operating as a single node receiving duplicated network traffic.
    \item Log storage, logs are collected and stored safely. In our case, the ELK stack is leveraged to fulfill this requirement.
    \item Log analysis: logs are parsed, normalized, analyzed, and evaluated according to specific techniques, different for each service. In our case, this activity is performed using Suricata, Zeek, rule-sets, and visual dashboards (Kibana, Security Onion Alets, Dashboard and Hunt sections). 
\end{enumerate}
Ultimately, logs are underpinned by a management policy, which establishes log retention, archival, and disposal of the latter.\newline
At this point, one question should arise naturally: \textbf{What has NDR got to do with this?} The answer is: everything! This kind of activity has to be carried out using valuable data, and logs are just the right source of information to let SOC (Security Operation Center) analysts understand and assess what is going on over a network. What tools should they be using? Here, SIEM and IDS play a key role, since they manage logs throughout their life and lastly help in finding IoCs.

\section{IoC, SIEM and IDS}
Before introducing what SIEMs and IDSs are, a clarification is needed about what a SOC analyst expects to find when watching a potentially infected network, to which it may have been previously exposed to attackers.
\subsection*{Indicator of Compromise}
\begin{quote}
“IoCs are specific techniques used in the course of an attack, which may appear as anomalous behavior.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“SP 800-53, Recommended Security Controls for Federal Information Systems and Organizations, defines IoCs as forensic artifacts from intrusions that are identified on organizational information systems (at the host or network level).”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“IoCs provide organizations with valuable information on objects or information systems that were compromised.”~\cite{valenza-nsm}
\end{quote}
IoCs can be categorized into three main categories:
\paragraph{Network-based IoCs}
\begin{quote}
“They can include events such as unusual traffic patterns or the unexpected use of protocols or ports.”~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\begin{quote}
“For example, there might be a sudden increase in traffic to a specific website or unexpected connections to URLs, IP addresses or domains that are known to be malicious.”~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\paragraph{Host-based IoCs}
\begin{quote}
“Host-based IoCs reveal suspicious behavior on individual endpoints.”
~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\begin{quote}
“They can include a wide range of potential threats, including unknown processes, suspicious hash files or other types of files, changes to system settings or file permissions, or changes to file names, extensions or locations.”~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\begin{quote}
“File-based IoCs are sometimes treated as a separate category from host-based IoCs.”~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\paragraph{Behavioral IoCs}
\begin{quote}
“Behavioral IoCs reflect behaviors across the network or computer systems, such as repeated failed login attempts or logins at unusual times.”
~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\begin{quote}
“This category is sometimes incorporated into the other categories.”~\cite{valenza-nsm}
\vspace{-1em}
\end{quote}
\begin{figure}[htpb]
  \centering
  \includegraphics[width=0.55\textwidth]{figures/content/iocs.jpg}
  \caption{Summary of Indicators of Compromise~\cite{iocs}.}
  \label{fig:iocs-diagram}
\end{figure}

\subsection*{Security Information and Event Management (SIEM)}
In Security Onion, this role is covered by the ELK Stack (Elasticsearch, Logstash and Kibana).
\begin{quote}
“Security information and event management (SIEM) is the process of identifying, gathering, monitoring, analyzing, and reporting security-related events.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“The objective of SIEM is to extract from a large volume of security events those events that qualify as incidents.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“SIEM takes data input from all devices/nodes and other similar applications, such as log management software. The collected events data is analyzed with security algorithms and statistical computations to trace out any vulnerability, threat, or risk.”~\cite{valenza-nsm}
\end{quote}

\paragraph{SIEM Functions}
\begin{quote}
“The first phase of event management is the collection of event data in the form of logs. As event data are generated, they are generally stored in logs local to the devices that generate them.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Normalization: For effective management, the log data needs to be in a common format to enable further processing.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Filtering: This step includes assigning priorities to various types of events. On the basis of priority, large number of events can be set aside and not subject to further analysis, or they can be archived in case there is a need to review them later.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Aggregation: The IT facility of a large enterprise generates millions of events per day. It is possible to aggregate them by categories into a more manageable amount of data. For example, if a particular type of traffic is blocked a number of times, it is sufficient to record as a single aggregate event the type of traffic and the number of times it was blocked over a particular time frame.”~\cite{valenza-nsm}
\end{quote}

\paragraph{SIEM Analysis Techniques}
\begin{quote}
“Pattern matching: It is important to look for data patterns within the fields of stored event records. A collection of events with a given pattern can signal a security incident.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Scan detection: Often, an attack begins with a scan of IT resources by the attacker, such as port scans, vulnerability scans, or other types of pings. A substantial number of scans being found from a single source or a small number of sources can signal a security incident.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Threshold detection: A straightforward form of analysis is the detection of a threshold being crossed. For example, if the number of occurrences of a type of event exceeds a given threshold in a certain time period, that constitutes an incident.”~\cite{valenza-nsm}
\end{quote}

\paragraph{Event Correlation}
\begin{quote}
“Event correlation consists of using multiple events from a number of sources to determine that an attack or suspicious activity occurred. For example, if a particular type of attack proceeds in multiple stages, the separate events that record those multiple activities need to be correlated in order to see the attack.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Another aspect of correlation is to correlate particular events with known system vulnerabilities, which might result in a high-priority incident.”~\cite{valenza-nsm}
\end{quote}

\subsection*{Intrusion Detection and Analysis}
\paragraph{Definitions}
\begin{quote}
“Intrusion: Violations of security policy, usually characterized as attempts to affect the confidentiality, integrity, or availability of a computer or network. These violations can come from attackers accessing systems from the Internet or from authorized users of the systems who attempt to overstep their legitimate authorization levels or who use their legitimate access to the system to conduct unauthorized activity.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Intrusion detection: The process of collecting information about events occurring in a computer system or network and analyzing them for signs of intrusions.”~\cite{valenza-nsm}
\end{quote}

\paragraph{Intrusion Detection System (IDS)}
\begin{quote}
“An intrusion detection system consists of hardware or software products that gather and analyze information from various areas within a computer or a network for the purpose of finding, and providing real-time or near-real-time warning of, attempts to access system resources in an unauthorized manner.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Any malicious venture or violation is normally reported either to an administrator or collected centrally using a security information and event management (SIEM) system.”~\cite{valenza-nsm}
\end{quote}
Detection comes with three different flavors, each different and more adequate to the specific kind of analysis required:

\paragraph{Signature-Based Analysis}
\begin{quote}
“Signature-based IDS detects the attacks on the basis of the specific patterns.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Such as number of bytes or number of 1’s or number of 0’s in the network traffic.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“It also detects on the basis of the already known malicious instruction sequence that is used by the malware.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“The detected patterns in the IDS are known as signatures.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Moreover, this type of detection is also based on rules that specify system events, sequences of events, or observable properties of a system that are believed to be symptomatic of security incidents.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Signature-based IDS can easily and accurately detect the attacks whose pattern (signature) already exists in system (with few false alarms), but it is quite difficult to detect the new malware attacks as their pattern (signature) is not known.”~\cite{valenza-nsm}
\end{quote}

\paragraph{Behavioral Analysis}
\begin{quote}
“Anomaly-based IDS searches for activity that is different from the normal behavior of system entities and system resources.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“An advantage of anomaly detection is that it is able to detect previously unknown attacks based on an audit of activity.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“A disadvantage is that there is a significant trade-off between false positives and false negatives.”~\cite{valenza-nsm}
\end{quote}

\paragraph{Protocol Awareness}
\begin{quote}
“Normal traffic typically conforms to RFC specifications. Malicious traffic often does not.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Attackers often intentionally bend protocols in order to evade detection.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Just as the arms race exists between attacker and defender, it also exists between attacker and detector.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“Protocol-aware NIDS/NIPS reassemble fragments (Layer 3), reassemble streams (Layer 4), and even reconstruct entire protocols (Layer 7) because they have to understand how the endpoint of the communication will interpret the data.”~\cite{valenza-nsm}
\end{quote}
\begin{quote}
“It’s possible for protocols to be broken in a non-malicious way by a misconfigured or malfunctioning device. However, protocol abuse is often a symptom of malicious intent. Either way, it is worth detecting.”~\cite{valenza-nsm}
\end{quote}

\paragraph{IDS Classification}
IDSs can be further classified on the basis of the detection target:
\begin{itemize}
    \item Host Intrusion Detection System (HIDS)
    \item Network Intrusion Detection System (NIDS)
    \item Protocol-based Intrusion Detection System (PIDS)
    \item Application Protocol-based Intrusion Detection System (APIDS)
    \item Hybrid Intrusion Detection System
\end{itemize}
Even though Security Onion offers minimal HIDS functionalities as well, in the context of this research the focus is mainly on achieving NIDS capabilities through Security Onion's network traffic monitoring services, which are Suricata and Zeek.

\section{Zeek}
\subsection*{Overview}
Zeek, formerly known as Bro, is an open-source network analysis framework that is widely used for security monitoring of networks and for analyzing traffics. Unlike signature-based intrusion detection systems, Zeek runs as a passive observer of traffics but creates high-fidelity structured logs that record the details of its detected activities \cite{zeek-docs}. It originated with the mid-1990s at the Lawrence Berkeley National Laboratory but has matured over time into a flexible and extendable platform. The name was changed from Bro to Zeek in 2018 to more appropriately reflect the mission of the project as well as the values of its users \cite{zeek-docs}.

\subsection*{Fundamental Operations}
The biggest purpose of Zeek is producing end-to-end logs that condense network activity. Those logs contain structured versions of the network interactions as well as application-level protocol interactions across multiple formats including tab-separated values (TSV) and JSON \cite{zeek-docs}. By default, Zeek observes and prints out an extremely broad range of activities including:
\begin{itemize}
\item Connection metadata : Summarized details of each TCP, UDP, ICMP connection.
\item DNS activity: queries and answers, with record types and response codes.
\item HTTP transactions: URIs that were requested, methods, headers, MIME types, and server response.
\item SSL/TLS information: including certificates, cryptographic definitions, and handshake details.
\item Other application protocols include SMTP, FTP, and SMB.
\end{itemize}
These logs offer network security experts unparalleled clarity of activity that is taking place over the monitored connections, thereby providing the basis for detecting incidents, forensic analysis, as well as security analytics \cite{zeek-docs}.

\subsection*{Architecture and Deployment}
Zeek is designed to work well across a range of scales, from tiny scales up to large scales. It is able to work on one machine for small network deployments, or it can be deployed in a clustered setup that supports high-throughput monitoring \cite{zeek-docs}. A clustered setup usually consists of:
\begin{itemize}
\item Workers that capture and analyze traffic.
\item A Manager, who organizes workers and is responsible for policies.
\item Optional Loggers, reserved for data output processing.
\end{itemize}
The zeekctl command allows for centralized management of such deployments such that administrators are able to start, stop, and manage the whole cluster as a whole \cite{zeek-docs}. This scalability makes Zeek suitable for both enterprise networks and test networks, where throughput speeds often reach multi-gigabit speeds. The architecture also allows operators to tailor Zeek to different performance requirements without having to sacrifice insight or analytical capabilities \cite{zeek-docs}.

\subsection*{Detection Features}
Though not a signature-based IDS itself, Zeek accommodates many different detection mechanisms. Some of these are anomaly detection, semantic misuse detection, and policy enforcement by script \cite{zeek-docs}. Some examples of native detection abilities include:
\begin{itemize}
\item Identifying SSL/TLS channels that use weak or out-of-date cryptographic parameters.
\item Identifying brute-force login attempts over SSH.
\item Monitoring of susceptible software versions within monitored traffic.
\item Verification of SSL/TLS certificate hierarchies.
\end{itemize}
These mechanisms enhance signature-based systems such as Suricata, effectively making Zeek an essential part of multi-level network defense strategies \cite{zeek-docs}.

\subsection*{Relevance to Security Onion}
Zeek acts as the network traffic analysis engine that continuously creates comprehensive logs for input into the Elasticsearch–Logstash–Kibana (ELK) stack. These logs lay the foundation for dashboards, queries, and correlation exercises. Its extensibility also allows the analyst to tailor detector policies based off organizational needs.


\section{Suricata}
\subsection*{Overview}
Suricata is an open-source threat detection engine that was created by the Open Information Security Foundation (OISF). It is a solution that provides a Network Intrusion Detection System (NIDS), Network Intrusion Prevention System (NIPS), as well as a Network Security Monitoring (NSM) solution. Suricata detects intrusions, exploitation attempts, as well as malicious behaviors by processing network traffic in real-time using a combination of signature-based as well as anomaly-based methods \cite{suricata-userguide}.

\subsection*{Fundamental Operations}
Suricata examines network traffic at multiple layers from packet headers to application-level protocol, thanks to its flexible rule engine that handles:
\begin{itemize}
\item Intrusion Detection (IDS): traffic monitoring and alerts generation on suspicious activity.
\item Intrusion Prevention (IPS): blocking or modifying packets when potential malicious behavior gets spotted.
\item Network Security Monitoring (NSM): generating fine-grained logs of traffic activity for analysis and correlation.
\end{itemize}
Rules are written with a easy-to-learn syntax that is Snort rule syntax compatible allowing for quick adoption and implementation of community contributed rule-sets \cite{suricata-userguide}.

\subsection*{Logging and Protocol Understanding}
Beyond its detection capabilities, Suricata offers end-to-end protocol inspection as well as logging. Built-in parsers enable it to comprehend multiple protocol types and produce structured documentation for:
\begin{itemize}
\item HTTP: requests, responses, headers, URIs.
\item DNS: queries and answers plus record information.
\item TLS: handshake details, certificates, and cipher suites.
\item SMTP and other protocol.
\end{itemize}
Logs are exportable in multiple formats such as JSON such that they are easily collectible by log management software and by SIEM offerings \cite{suricata-userguide}. This feature makes Suricata simultaneously a detection system as well as a provider of telemetry.

\subsection*{Scalability and Performance}
Suricata is tuned for modern high-speed networks. Performance highlights of key features are:
\begin{itemize}
\item Intrinsic multi-threading for optimal exploitation of multi-core processors.
\item Support of hardware acceleration for selective environments.
\item From cramped lab settings to huge enterprise-scale deployments across multi-gigabit networks.
\end{itemize}
These advancements to performance ensure that Suricata remains effective across experimental deployments as well as production deployments \cite{suricata-userguide}.

\subsection*{Expanded Functions}
Beyond traffic inspection, Suricata supports:
\begin{itemize}
\item File extraction from network streams for the analysis of malwares.
\item Anomaly detection by flows to identify unexpected patterns.
\item Integration of external sources of threats.
\item Auto-updating with Emerging Threats (ET) rule sets. These abilities broaden the use of Suricata from a traditional IDS/IPS to a next-gen security monitoring solution \cite{suricata-userguide}.
\end{itemize}

\subsection*{Relevance of Security Onion}
In Security Onion, Suricata serves as the signature-based detection centerpiece alongside Zeek's behavioral traffic analysis. Suricata creates alerts from rule matches that are then fed into the ELK stack for visualization and correlation. This way, analysts are able to see Suricata alerts sitting next to Zeek logs for increased insight into attack signatures as well as contextual traffic.


\section{The Elastic Stack (ELK)}
\subsection*{Overview}
Elastic Stack, previously referred to as ELK consisting of Elasticsearch, Logstash, and Kibana, forms a suite of tightly integrated components for large-scale ingestion, storing, searching, analyzing, and visualizing data \cite{elastic-docs}. The latest Elastic documentation refers to these as individually highlighted software but are integrated together in a shared documentation portal with aligned releases and an integrated user interface with regard to deployment and management,
and upgrades \cite{elastic-docs}. Altogether, Elasticsearch provides distributed search functionality and analytical workflows, Logstash is an elastic data ingress and transformation pipeline, and Kibana offers interfaces for visualization, exploration, and management \cite{elastic-docs}.

\subsection*{Elastic}
Elasticsearch is a RESTful open-source search and analytics engine built for high availability, horizontal scalability, and near-real-time operations \cite{elastic-docs}. The data is organized as shards and indices that provide parallelism and fault tolerance. Important features are analytics with aggregation, full-text search, and an extensive API surface (document indexing, search, mappings, and lifecycle operations for indices) that control data from ingestion phase till retention phase \cite{elastic-docs}. Of course, text search is just the tip of the iceberg of Elasticsearch capabilities handle structured data as well as semi-structured data and time-series workloads, in addition to modern retrieval patterns used by security and observability tools. It provides a schema and mapping model to manage field types as well as behaviors, including offering role-based access control and multiple security capabilities within the receiver distributions \cite{elastic-docs}.
Within the ELK realm, Elasticsearch serves as the query and store back-end that drives dashboards, alerts, and investigations.

\subsection*{Logstash}
Logstash is a server-side data processing pipeline that feeds data from many sources, transforms them, and sends the transformed events out to one or multiple destinations (typical destination being Elasticsearch) \cite{elastic-docs}. It has a configuration model that adheres to the input–filter–output paradigm, such that:
\begin{itemize}
\item Inputs accept events from multiple sources like files, message queues, network sockets, or Beats/agents.
\item Filters update and refine events (e.g., parsing with grok, restructuring JSON, normalizing fields, adding metadata, or geo-enriching IPs).
\item Events are forwarded to target destinations like Elasticsearch or elsewhere for data storing and processing.
\end{itemize}
Logstash is designed for throughput and reliability, ensuring persistent queues, and capabilities for bursts and backpressure. Moreover, it is extensible via plugins and its JSON-centric model of an event maps well against Elasticsearch's document store allowing smooth downstream indexing and search \cite{elastic-docs}.

\subsection*{Kibana}
Kibana is the user interface that works with data that is living in Elasticsearch \cite{elastic-docs}. It provides interfaces for:
\begin{itemize}
\item Visualization and Dashboards: building charts, maps, and ad-hoc views from time-series and other data.
\item Searching and Exploration: selective querying and filtering, along with proficient data exploration workflows.
\item Apps and Management: configuration of index patterns/data views, connectors, alerts, saved objects, and solution apps management (e.g., observability or security capabilities, if enabled).
\end{itemize}
The integration of Kibana with these abilities of Elasticsearch like saved searches, visualizations, and alerting makes Kibana the analysts' and operators' workspace of choice \cite{elastic-docs}.

\subsection*{Data Transmission and the Architectural Responsibilities}
A conventional data pipeline of an ELK stack is like this: data sources $\rightarrow$ Logstash (ingestion/transformation) $\rightarrow$ Elasticsearch (storage/querying) $\rightarrow$ Kibana (visualization/operation) \cite{elastic-docs}. This separation of labor has numerous advantages:
\begin{itemize}
\item Decoupled ingest and store: Logstash accepts heterogeneity at
Edge while Elasticsearch is concerned with scalable search and indexing.
\item Schema and normalization: filters normalize formats and fields for greater quality of correlation and search.
\item Real-time insights: Kibana provides dashboards, searches, and alerts from the data that gets indexed.
\end{itemize}
Because each element scales individually, deployments can actually correctly size ingest, storage, and UI layers by volume of data and query pattern \cite{elastic-docs}.

\subsection*{Relevance to Security Onion}
In a network detection and response platform, ELK provides the telemetry spine: Logstash (or synonymous ingest) pre-processes and normalizes network and security events; Elasticsearch indexes them for immediate search and analytics; and Kibana offers the report and investigative surface \cite{elastic-docs}. In the larger Security Onion picture treated elsewhere in this thesis, these capabilities map intuitively against needs for storing high-volume network logs, correlating events, and offering analyst-friendly dashboards \cite{elastic-docs}.
\clearpage

\section{Summary}
This chapter has established the theoretical and technological foundations necessary to understand modern network security monitoring and threat detection. We began by defining fundamental security concepts such as threats, vulnerabilities, and attacks, and explored how these elements interact within the cybersecurity landscape. Building on these definitions, we discussed the principles of Network Security Monitoring (NSM), emphasizing structured event logging, log lifecycle management, and correlation techniques as enablers of threat detection through SIEM and IDS platforms. Particular attention was devoted to the taxonomy of Indicators of Compromise (IoCs) and to the different detection paradigms, signature-based, behavioral, and protocol-aware, that shape how alerts are generated and interpreted in practice.
\medskip \newline
Having laid this conceptual groundwork, the chapter then examined the main technologies that constitute the backbone of the Security Onion platform: \textbf{Zeek}, for network protocol analysis and high-fidelity logging; \textbf{Suricata}, for intrusion detection and prevention through rule-driven analysis; and the \textbf{Elastic Stack (Elasticsearch, Logstash, and Kibana)}, for scalable log ingestion, indexing, and visualization. Each of these components was described in detail to highlight their individual contributions and their complementary roles when integrated within a unified NSM framework.
\medskip \newline
Together, these theoretical perspectives and tool descriptions provide the foundation for the experimental work that follows. The next chapter introduces the methodology used to design, implement, and evaluate a real-world deployment of Security Onion in a controlled environment. From system setup to attack simulation, every decision in that process is anchored in the concepts and technologies outlined in this background.
