\chapter{Methodology and Motivations}
Following the theoretical foundations discussed in the previous chapter, this section describes the structured approach to implement and evaluate Security Onion, exploring its official documentation, deployment options, staged threat scenarios for detection test purposes, and LLM integration. The methodology steps are followed by the objectives of this project, as it is necessary to understand clearly the motivations behind the study of Security Onion.

\section{Documentation Review}
Understanding how to deploy Security Onion and its network monitoring capabilities was needed before diving into its technicalities. Hence, the first step of the activity focused on grasping the necessary information to know which deployment options are available and which is the best fit for the company objectives for this first approach: the company opted for a Standalone Deployment, which comprises all components in one box.\newline
Once the deployment scenario has been chosen, network visibility became the next key aspect to review:
\paragraph{Intrusion Detection}
Security Onion generates NIDS (Network Intrusion Detection System) alerts by monitoring your network traffic and looking for specific fingerprints and identifiers that match known malicious, anomalous, or otherwise suspicious traffic. This is signature-based detection so you might say that it’s similar to antivirus signatures for the network, but it’s a bit deeper and more flexible than that. NIDS alerts are generated by Suricata.
~\cite{securityonion-netvisibility}
\paragraph{Network Metadata}
Unlike signature-based intrusion detection that looks for specific needles in the haystack of data, network metadata provides you with logs of connections and standard protocols like DNS, HTTP, FTP, SMTP, SSH, and SSL. This provides a real depth and visibility into the context of data and events on your network. Security Onion provides network metadata using your choice of either Zeek or Suricata.
~\cite{securityonion-netvisibility}
\vspace{1em}
\paragraph{Full Packet Capture}
Full packet capture is like a video camera for your network, but better because not only can it tell us who came and went, but also exactly where they went and what they brought or took with them (exploit payloads, phishing emails, file exfiltration). It’s a crime scene recorder that can tell us a lot about the victim and the white chalk outline of a compromised host on the ground. There is certainly valuable evidence to be found on the victim’s body, but evidence at the host can be destroyed or manipulated; the camera does not lie, is hard to deceive, and can capture a bullet in transit. Full packet capture can be written to disk using either Stenographer or Suricata.
~\cite{securityonion-netvisibility}  
\medskip \newline
The main network monitoring services which we rely onto are Suricata and Zeek, which will be further discussed in the following chapters.

\section{Deployment Set up}
Figure~\ref{fig:deployment} illustrates a simplified yet representative version of the network topology in which the machine has been deployed.
Although some implementation details have been abstracted for clarity, the structure reflects the actual configuration adopted throughout the activity.
\begin{figure}[htbp]
  \centering
  \includegraphics[width=0.75\textwidth]{figures/content/net-diagram.png}
  \caption{Security Onion - Machine deployment}
  \label{fig:deployment}
\end{figure}
\clearpage
\noindent
At the top of the architecture lies the external connection to the Internet, through which both legitimate traffic and potential attacker activity may flow. This traffic first reaches a next-generation firewall (NG-FW), which acts as a control point for ingress and egress filtering. The internal network is segmented into two core switches that manage the distribution of high-throughput traffic throughout the infrastructure.\newline
Below them, two distribution-layer switches are responsible for connecting different internal network segments and replicating selected traffic flows toward monitoring systems.
This setup ensures visibility into the east-west and north-south traffic within the network, as the Security Onion instance receives mirrored traffic from both distribution switches.\newline
Specifically, mirrored and monitored ports are configured to forward selected packet streams, including potential attack vectors, to the Security Onion sensor for inspection.
On the right side of the topology, a VMware cluster represents the virtualized workload environment being monitored.\newline
The layout reflects a typical enterprise segmentation pattern, where active traffic, mirrored flows, and security monitoring are logically decoupled yet tightly integrated.
\paragraph{Traffic Monitoring}
To enable traffic monitoring in this network environment, selected packets must be duplicated and forwarded to the Security Onion sensor for analysis. This is accomplished using the SPAN (Switched Port Analyzer) technique, also known as port mirroring. SPAN is a feature supported by most managed switches that allows a specific port (the monitor port) to receive a copy of the traffic traversing one or more source ports or VLANs.\newline
In this deployment, the distribution-layer switches were configured to mirror traffic from internal segments towards the interface connected to the Security Onion node. This approach ensures that the monitoring system has visibility into both north-south and east-west flows, without interfering with the production network or introducing latency. While SPAN is not the only method available for passive traffic tapping, it offers a non-intrusive and cost-effective solution particularly suited for virtualized infrastructures or enterprise-grade managed switches where inline deployment or hardware tapping may not be feasible.

\section{Installation and Configuration}
The next step following the initial setup involved taking care of the installation of Security Onion.\newline
The deployment of Security Onion was carried out within a virtualized infrastructure powered by VMware vCenter and ESXi. A dedicated physical server hosted the hypervisor environment, allowing the creation and management of guest virtual machines, including the one allocated to run Security Onion.
\medskip \newline
The installation process followed the official Security Onion documentation for VMware-based deployments, starting with the download of the installation ISO image. 
To ensure the integrity and authenticity of the downloaded image, a SHA256 digest check was performed and verified against the published checksum provided by Security Onion Solutions, aligning with the best practices for secure software acquisition.\newline
The guest system was configured with the Security Onion Desktop interface and deployed in standalone mode, a configuration comprising all core services, such as Suricata, Zeek, the ELK Stack, and the SOC Web UI, on a single node.\newline
Once the system was provisioned and booted, the initial configuration was completed using Security Onion’s guided setup utility, which includes network interface mapping, service selection, and account provisioning. More details about the post-installation steps can be found in the official documentation... as described in Security Onion’s post-installation configuration steps~\cite{so-postinstall}.

\section{Rule Tuning}
Once the system was successfully deployed, efforts were diverted to understanding how Suricata, the signature-based NIDS included in Security Onion, generated alerts. By default, Security Onion integrates the Emerging Threats Open rule-set to provide Suricata with a broad set of detection signatures suitable for general-purpose use. However, before proceeding with attack simulations, it was necessary to optimize Suricata’s detection capabilities. Fine-tuning the rule-set to the specific characteristics of the monitored network environment was essential to reduce noise, improve relevance, and ensure that the generated alerts would be both accurate and meaningful in the context of the testing scenarios.

\paragraph{ETOpen}
The Emerging Threats Open (ETOpen) rule-set is a widely used and community-maintained collection of intrusion detection signatures for signature-based NIDS. It provides coverage for a broad range of known threats, including malware traffic patterns, exploit attempts, suspicious protocol behaviors, and command-and-control activity. Distributed under an open-source license, ETOpen is particularly suited for general-purpose monitoring environments and serves as the default signature base for Security Onion~\cite{etpro-categories}.

\section{Attack Scenarios}
In order to effectively test Suricata and Zeek, 9 realistic attack scenarios were designed to test both components and provide a comprehensive result on how precise these two can be. The attacks progressively evolved in complexity and potential impact, thus returning valuable data to inspect and report.
\clearpage

\section{LLM Integration}
As a final step in this research, dedicated efforts were directed to evaluate the use of Large Language Models (LLMs) to support the Security Operations Center (SOC) workflow. A proof-of-concept system was implemented by integrating a self-hosted LLM within an OpenWebUI container, connected to Security Onion’s Elasticsearch back-end, which serves as the primary log indexing component in the ELK stack. The model was configured to generate and execute JSON-based Domain Specific Language queries (DSL) from natural language prompts, enabling automatic retrieval of relevant logs across Suricata and Zeek data sources.\newline
Three core query functions were developed to support matching, aggregation, and multi-step correlation across datasets. Live field mappings were dynamically extracted from Elasticsearch to enhance the model's schema awareness, allowing it to construct contextually accurate queries. The pipeline was designed to pivot across key fields—such as \texttt{log.id.uid}, \texttt{network.community\_id}, and \texttt{source.ip}—and reconstruct timelines from alert activity. The queries results were passed back to the LLM, which then produced natural language summaries to assist the analyst in interpreting Suricata alerts, Zeek logging and ultimately suggest potential response steps.\newline
This experimental component demonstrates how LLMs can act as intelligent SOC assistants, lowering the barrier to investigation and enriching analyst workflows through automation and contextual synthesis.
\clearpage

\section{Motivation and Goals}
Three major trends represent the motivation behind this research activity:
\begin{enumerate}
    \item The growing need for NDR solutions to counter increasingly evasive threats.
    \item The opportunity to explore the capabilities of Security Onion as an open-source alternative to commercial systems.
    \item The integration of Artificial Intelligence, i.e. Large Language Models (LLMs), to improve SOC workflows.
\end{enumerate}
The main objectives this activity aims to achieve are summarized as follows:
\begin{itemize}
    \item \textbf{Evaluate Security Onion capabilities}, including:
    \begin{itemize}
        \item The installation and configuration of Security Onion and its main modules (Zeek, Suricata, ELK).
        \item The design and analysis of realistic attack scenarios to test detection mechanisms and platform response.
        \item The collection, normalization, and analysis of logs for suspicious behaviors.
    \end{itemize}
    \item \textbf{Frame the platform within Ricca IT’s infrastructure}, to provide Security Onion as an additional service delivered to clients.
    \item \textbf{Investigate AI integration}, by designing and developing a proof-of-concept system: the analysis and correlation of logs is assisted by a LLM, in order to reduce the burden on SOC analysts.
\end{itemize}