\chapter{Installing and Configuring Security Onion}

\section{Introduction}
This chapter represents the first stage of the experimental activity, where the content of the previous chapter is translated into a concrete deployment. This step follows the documentation review and the topology design: the main objective here is to install and configure \textbf{Security Onion} as a standalone node, with respect to both the requirements of Ricca IT and the research goals of this thesis. 
The chapter is structured as a combination of technical procedure and reflective commentary, emphasizing the reasoning behind architectural choices, the challenges faced during installation, and the trade-offs between completeness, performance, and scalability.
Ultimately, this deployment lays the foundation upon which attack simulations, detection evaluation, and AI integration have been performed, and later on each of these aspects will be discussed in the following chapters.

\section{Security Onion in Context}
Security Onion is not a single tool, but an appliance consisting of a large ecosystem of cohesive security services into one platform. In its standalone form, it bundles signature-based detection (Suricata), behavioral and protocol-aware analysis (Zeek), log ingestion and visualization (Elastic Stack), and optional services such as Strelka for file analysis or Stenographer for full packet capture. 
\medskip\newline
For the purposes of this research activity, the \textbf{standalone deployment}, where all components are hosted on a single node, was adopted in favor of a distributed architecture. This decision is driven by the scope of the project (a proof-of-concept with real traffic visibility) and the available infrastructure. Although distributed deployments offer scalability and role separation (manager, forward, and search nodes), the standalone mode is sufficient to achieve our established goals: testing detection accuracy, fine-tuning rules, and integrating AI-driven queries.
\medskip\newline
\textbf{Figure \ref{fig:so-standalone-architecture}} illustrates the Security Onion standalone stack, showing how Suricata, Zeek, the Elastic Stack, and the SOC web interface coexist on the same machine.
\begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/content/so-standalone.png}
    \caption{Security Onion standalone deployment architecture, consolidating detection, analysis, and visualization services on a single node.}
    \label{fig:so-standalone-architecture}
\end{figure}
\clearpage

\section{Installation Environment}
The deployment was hosted on a dedicated \textbf{VMware ESXi} hypervisor running on bare metal. This choice provided a balance between performance and manageability: bare metal ensures direct access to hardware resources, while ESXi adds a layer of virtualization that simplifies snapshotting, resource allocation, and future machine reconfiguration.
\medskip\newline
The Security Onion Desktop node was provisioned as a virtual machine with the following specifications:
\begin{itemize}
    \item \textbf{Memory:} 33 GB RAM
    \item \textbf{Disk:} 500 GB storage
    \item \textbf{CPUs:} 8 cores
    \item \textbf{Networking:} one interface mapped to a management VLAN, one to mirrored traffic (SPAN port from distribution switches)
\end{itemize}
\medskip
\noindent
Table \ref{tab:so-specs} compares the allocated resources with the official minimum recommendations, showing that the chosen configuration exceeds the baseline and ensures stable operation under moderate traffic load.
\begin{table}[H]
    \centering
    \begin{tabular}{|p{5cm}|p{4cm}|p{4cm}|}
    \hline
    \textbf{Resource} & \textbf{Recommended} & \textbf{Allocated} \\
    \hline
    RAM & 8–16 GB & 33 GB \\
    Disk Space & 200–300 GB & 500 GB \\
    CPU Cores & 4+ & 8 \\
    Network Interfaces & 2 & 2 \\
    \hline
    \end{tabular}
    \caption{Comparison of Security Onion recommended standalone specs vs. allocated VM resources.}
    \label{tab:so-specs}
\end{table}

\subsection{Traffic Capture Topology: SPAN vs TAP}
A critical aspect of any NDR deployment is the method used to forward traffic from production networks to the monitoring system. In this project, traffic was delivered to the Security Onion node using the \textbf{SPAN} (Switched Port Analyzer) technique, also referred to as port mirroring, on the distribution switches.
\medskip \newline
Even though SPAN provides a software-based mechanism for copying selected data flows to a monitoring interface, it comes with limitations. The most common issues associated with SPAN:
\begin{itemize}
    \item \textbf{Packet Loss:} under high load, switches may drop mirrored packets to preserve production performance.
    \item \textbf{Timing Distortion:} the traffic that gets duplicate may timestamps mismatches, which could indeed affect sequence analysis.
    \item \textbf{Switch Dependency:} not all switches support advanced SPAN configurations, and implementations may vary between different vendors.
\end{itemize}
An alternative approach consists in using dedicated \textbf{TAPs} (Test Access Points). TAPs provide hardware-level traffic duplication, granting no packet loss and minimal misalignment of timestamps. TAPs are often classified as the standard for security monitoring, especially in high-throughput network environments.
\medskip\noindent
However, in this deployment, TAPs were deliberately not used. The reasons stem from both practical and infrastructural points of view:
\begin{itemize}
    \item The production network was not technologically homogeneous, making it quite difficult to deploy hardware TAPs across all critical links.
    \item The introduction of TAPs would have implied configuration changes on critical production links, which was unfeasible during R\&D time.
    \item The trade-offs of SPAN were acceptable, within the context of this research.
\end{itemize}
So even though TAPs would have technically had a higher fidelity, SPAN was the best balance between traceability, safety and non-intrusiveness: in enterprise environments not to interfere with production operations is usually more important than doing perfect packet capture.

\section{Installation Procedure}
The installation process began with the acquisition of the official Security Onion ISO image. As a first security measure, the downloaded media was validated by computing its SHA256 digest and verifying it against the checksum published on the Security Onion Solutions website. This practice ensured the integrity and authenticity of the installation source, reducing the risk of corrupted or tampered software.
\newline
Once mounted in ESXi, the VM was booted from the ISO. The guided installation was selected, targeting a standalone deployment. The installer asked for key configuration items: network interface mapping (distinguishing between management and monitoring NICs), host-name assignment, and the creation of administrative credentials. Upon reboot, the Security Onion Desktop environment was launched, consolidating all the integrated services, like Suricata, Zeek, Elastic Stack, and the SOC web interface.
\newline
Although the Security Onion tech stack offers by default \textbf{Stenographer} for full packet capture alongside Suricata, this option was consciously not adopted. This choice has two main reasons behind it:
\begin{itemize}
    \item Stenographer belongs to earlier Security Onion releases and has been progressively omitted in favor of Suricata’s native capture and logging capabilities.
    \item Relying on Suricata alone avoids duplication of traffic capture and reduces storage overhead, focusing instead on signature-based detection enriched with contextual metadata.
\end{itemize}
This decision reflects an alignment with modern Security Onion usage patterns and emphasizes efficiency over redundancy.
\medskip \newline
After installation, the machine was accessible both via the web, through the Security Onion Console, and SSH. The SOC web interface provides a unified dashboard for log access, rule management, and visualizations.\newline
To ensure that the machine has started each service correctly, thus ensuring that every stack service is up and running after installation, it is possible to consult the \emph{Grid} or access the machine via SSH and run the command \emph{sudo so-status}. Figure \ref{fig:so-login} shows the Security Onion login screen following a successful deployment, while figure \ref{fig:so-grid} shows the status of the node.
\begin{figure}[H]
    \centering
    \includegraphics[width=0.85\linewidth]{figures/content/so_access.png}
    \caption{Accessing Security Onion}
    \label{fig:so_access}
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=1.0\textwidth]{figures/content/so_login.png}
    \caption{SOC Web UI login screen after initial installation of Security Onion.}
    \label{fig:so-login}
\end{figure}
\begin{figure}[H]
    \centering
    \includegraphics[width=1.0\textwidth]{figures/content/so_grid.png}
    \caption{SOC Web UI Grid}
    \label{fig:so-grid}
\end{figure}
\clearpage

\section{Post-Installation Configuration}
Once the standalone node was installed and operational, attention was shifted to the post-installation phase. This stage was crucial in tailoring the Security Onion to the characteristics of the monitored environment. This allowed alerts and logs to be both meaningful and manageable. Post-installation configuration involved two main aspects: \textbf{service orchestration} and \textbf{detection stack configuration}.

\subsection{SaltStack Orchestration}
Security Onion uses SaltStack for the orchestration of its internal services. This mechanism ensures that Suricata, Zeek, the Elastic Stack, and any other auxiliary components, such as Strelka or Filebeat, are consistently deployed and maintained. By relying on declarative states, the platform can automatically heal misconfigured or failed services, a feature particularly valuable in production environments where manual intervention may be costly or error-prone. During this research activity, SaltStack played a background role, but its presence guaranteed that every configuration change, such as the activation of rule sets or log pipelines, was propagated reliably across the system.

\subsection{Suricata as the Primary Capture Engine}
A conscious architectural choice was made to rely exclusively on Suricata for traffic capture and analysis. As stated previously, Security Onion offers the option to enable Stenographer for full packet capture: this feature was deliberately not pursued throughout the experiment. The reasons behind this decision have already been discussed in the installation section; here the focus is on how Suricata was effectively configured as the sole capture engine within the SOC interface.
\medskip \newline
With the SOC web user interface, the administrator may access the\textit{Administration} and \textit{Configuration} panels, where separate services are listed and monitored. Within this section, Stenographer and Suricata are shown as separate modules, each that could be enabled to capture data in real-time. By leaving Stenographer disabled and ensuring that the capture service provided by Suricata was running, all redundant traffic was sent directly into the detection pipeline of Suricata.
\medskip \newline
This decision streamlines the processes of configuration and monitoring. Rather than overseeing two concurrent capture systems, the SOC dashboard presents Suricata as the sole provider of packet-based alerts and logs. The alerts produced in this context are subsequently enhanced with metadata, indexed within Elasticsearch, and depicted in Kibana dashboards, in addition to being displayed in the integrated SOC dashboards.
\medskip \newline
Figure \ref{fig:so-suricata-capture} illustrates the SOC interface where Suricata is configured as the active capture engine, while Stenographer can be disabled via \textit{Administration} $\rightarrow$ \textit{Configuration} $\rightarrow$ \textit{pcap}. This confirms the practical enforcement of the architectural choice, transforming Suricata from a NIDS-only component into the backbone for both detection and packet capture within the standalone deployment.
\begin{figure}[H]
    \centering
    \includegraphics[width=1.0\textwidth]{figures/content/config-item-suricata.png}
    \caption{SOC web interface showing Suricata enabled.}
    \label{fig:so-suricata-capture}
\end{figure}

\paragraph{Suricata Configuration}
Configurations below were implemented through the SOC user interface to facilitate running Suricata as the only capture engine, while still allowing for extensive analytical insight.
\begin{itemize}
    \item \textbf{Capture engine workflow.} The capture engine used globally was originally set to \texttt{TRANSITION} mode, in order to allow the old Steno indexes to age out under the new Index Lifecycle Management (\emph{ILM}) policy; once stable, the capture mode was switched to \texttt{SURICATA}, disabling Steno.
    \item \textbf{PCAP selections.} \emph{Conditional PCAP} mode was set to \texttt{all} (capture all traffic), \emph{compression} enabled with \texttt{lz4}, and \emph{stream depth} configured to maximum (no truncation). \textit{Reflection:} setting \texttt{all} ensures analytical completeness in exchange of greater storage consumption; \texttt{lz4} adds minor CPU overhead in exchange for meaningful space savings; disabling truncation prioritizes forensic fidelity.
    \item \textbf{Metadata engine.} The overall \texttt{mdengine} was left to \texttt{ZEEK},  to keep its extensive protocol support; packet capture and signature-based functionality was concentrated on Suricata.
    \item \textbf{Network variables.} \texttt{HOME\_NET} was tailored to the internal address space of the company; \texttt{EXTERNAL\_NET} was left as \texttt{any} on purpose as a means to avoid eliminating east–west traffic. \textit{Implications:} many NIDS rules use patterns like \texttt{\$EXTERNAL\_NET -> \$HOME\_NET}. Using \texttt{any}  raises the matches to internal-internal flows, increasing lateral-movement awareness while raising the baseline of normal matches. This trade-off inevitably begets the tuning effort (suppressions, thresholding, custom rules) that follows, so that improvements in visibility do not become analyst fatigue.
    \item \textbf{Capture filters.} A concise BPF was applied to exclude a small set of trusted internal IPs (controlled/known-noise sources), trimming down some specific events without reducing coverage for unknowns.
    \item \textbf{VLAN context.} Due to SPAN behavior in the environment,the VLAN tags were stripped off from the mirrored traffic. Although this limited VLAN-aware tracking, it was acceptable in light of the passive and unobtrusive monitoring objectives discussed earlier.
    \item \textbf{Performance.} Defaults left for packet queues as well as AF-PACKET threading, based on the resources provided for the VM (8 vCPUs, 33 GB RAM). CPU affinity as well as NUMA pinning\footnote{NUMA pinning binds processes to a specific NUMA node (its CPUs and local memory) to minimize latency and boost performance} were not required.
\end{itemize}
\paragraph{Summary} 
In short, Suricata was initialized with optimization for completeness (capture=\texttt{all}, no truncating, \texttt{lz4} compression) as well as internal transparency (\texttt{EXTERNAL\_NET=any}), while rich metadata were provided by Zeek. Balancing the deliberate expansion of the detections is the judicious tuning methodologies outlined in the upcoming section,\emph{Tuning and Log Management}, so as to prevent unnecessarily generating noise.

\subsection{Zeek and Metadata Logging}
Zeek was left enabled as the master platform metadata engine and was installed through the SOC interface (\textit{Administration} $\rightarrow$ \textit{Configuration} $\rightarrow$ \textit{zeek}). No filesystem-level override was necessary. Preserving rich, protocol-aware context (e.g., DNS, HTTP, TLS) while aligning the configuration to the network capture selections made for Suricata was the main goal of this experiment.

\paragraph{Network variables and capture scope.}
\texttt{HOME\_NET} definition was also tailored to correspond to the internal address space of the company (the actual CIDRs are excluded), so that Zeek connection and packet analyzers properly identify internal hosts. As in the configuration setup of Suricata, a small group of internal IPs that were benign sources of background traffic were excluded using a compact \textbf{BPF}, so that non-actionable events are minimized without losing insight into unknown or lateral activity. Since SPAN behavior existed in the environment, \textbf{VLAN tags} were not included within the mirrored feed, so VLAN-aware filters as well as analytics were not considered here.

\paragraph{Log set and correlation.}
Default analyzers and logs were retained. In practice, the most useful datasets for this work were the following:
\begin{itemize}
  \item \texttt{conn.log} for session baselining and pivoting,
  \item \texttt{dns.log} for domain-resolution context,
  \item \texttt{http.log} for method/URI/user-agent visibility,
  \item \texttt{ssl/tls.log} for certificate and JA3/JA3S fingerprints
\end{itemize}
\textbf{Community ID.} correlation remained enabled by default, providing a stable join key across Zeek metadata, Suricata alerts, and Elastic indices. This provided a consistent acceleration in timeline reconstruction and cross-tool pivots in the SOC UI.

\paragraph{File extraction and downstream analysis.}
Zeek file extraction was activated so that Strelka could analyze artifacts that were being observed in traffic for content analysis. This augmented the signature alerting that was being provided by Suricata by adding context when file movement moved across monitored links. Storage impact was reasonable under the project restrictions as well as the ILM policy.

\paragraph{Performance profile.}
All the \textbf{performance parameters} (threading, pinning, number of workers) were left as their default values. From the VM headroom (8 vCPUs, 33 GB RAM) and the observed throughput, the default values were sufficient to maintain the stability without any serious packet/capture loss. No CPU affinity or any NUMA pinning was required.

\paragraph{Reflection.}
Network scope replication of Suricata in Zeek (customized \texttt{HOME\_NET} and selective BPF) retained the two engines analytically identical and prevented any traffic classification mismatches. VLAN tags being omitted are a known SPAN limitation on diverse networks, which was accepted. Finally, retaining the full Zeek log set (with Community ID) inflates ingest volume on purpose; this is a conscious trade-off to allow maximum contextual correlation

\subsection{Elastic Stack and Index Management}
The Elastic Stack (Elasticsearch, Logstash, and Kibana) was configured as the backbone for log storage and visualization. To keep search performance predictable and storage usage under control, the deployment relies on \textbf{Index Lifecycle Management (ILM)}. In essence, ILM is a policy-driven mechanism that governs how indices \emph{roll over}, \emph{age}, and eventually \emph{deleted}. It does so by moving indices through well-defined \emph{phases} and applying actions (e.g., shrink, force-merge, freeze, delete) based on time or size thresholds.

\paragraph{Why ILM is needed.}
Security telemetry grows continuously and unevenly: Suricata alerts and Zeek metadata can spike during scans or tests, while background noise accumulates steadily. Without lifecycle policies, the indices would either become too large, negatively affecting query latency and cluster stability, or be retained longer than justified (inflating storage and compliance risk). ILM addresses both concerns by:
\begin{itemize}
  \item keeping shard\footnote{A shard is a partition of an index in Elasticsearch, used to distribute data and queries across nodes.} sizes reasonable for low-latency queries;
  \item lowering the priority of older data or removing it entirely to free up storage space;
  \item offering a clear, auditable retention schedule.
\end{itemize}

\paragraph{Phases used in this deployment.}
The ILM was aligned with the available storage resources and the project analysis needs. The policy adopted the following phases:
\begin{itemize}
    \item \textbf{Hot Phase:} newly ingested logs reside in the hot tier for fast indexing and querying. Indices can \emph{roll over} by age (and/or size), e.g., when they reach a target size to avoid having huge shards).
    \item \textbf{Warm Phase (after 14 days):} indices swap to lower-performing storage and may be forced-merged into smaller chunks, which decrease the overhead of queries/storage on aged, less-accessed data.
    \item \textbf{Cold Phase (after 60 days):} indices are preserved as part of budget-friendly, sporadic access (read-only). It preserves the forensic value as well as minimizes the use of resources.
    \item \textbf{Delete Phase (after 90 days):} indices are deleted based on the retention schedule, to avoid unlimited growth and conforming to storage and data governance limitations.
\end{itemize}
In a stand-alone Security Onion node, the stages happen as logical states, not as additional levels of hardware; their significance still prevails, as they regulate rollover, merge, as well as retention processes directly affecting stability in the system, as well as disk usage.

\paragraph{Rationale behind Tuning levers.}
ILM presents various "knobs" which could be tailored to needs based on the environment:
\begin{itemize}
  \item \textbf{Rollover conditions} (by index size, number of documents, and/or age): avoid overgrown shards that slow down search and cause heap pressure.
  \item \textbf{Retention windows} (phase ages): balance forensic value versus storage cost; shortening and lengthening of the retention windows may vary based off the company needs, compliance constraints and traffic volume.
  \item \textbf{Shard/replica strategy:} replicas are generally reduced to a minimum in single-node deployments to avoid unassigned shards; replicas provide availability through a trade-off in space in cluster deployments.
  \item \textbf{Segment optimization} (force-merge in warm): consolidates segments for cheaper long-term storage and faster cold reads.
  \item \textbf{Cold/frozen storage or snapshots}: store very old indices to the object store (snapshots) for legal hold purposes without allowing the latter to overstay within the master disk.
\end{itemize}

\paragraph{Governance and compliance considerations.}
Aside from performance, ILM is also a data governance strategy. Logs normally contain personal data (usernames, IP addresses that are tied to individuals, URLs, device identifiers). Rules such as GDPR emphasize data minimization and storage limitation: store only that which is necessary, only for as long as necessary to meet a legitimate purpose. In practice, this implies that:
\begin{itemize}
  \item synchronizing delete phase timing with contractual/legal retention schedules;
  \item outlining retention based on index classification;
  \item entering the ILM policy into the organization data retention register.
\end{itemize}
These limitations are operationally significant: aggressive capture selections (e.g., PCAP \texttt{all}, no stream truncating) result in increasing the number of logs ingested and potentially releasing a larger set of personal data gathered, which ILM then must handle responsibly.

\paragraph{Applied settings during this project.}
In concrete terms, the roll-out involved a hot $\rightarrow$ warm (14~days) $\rightarrow$ cold (60~days)$\rightarrow$ delete (90~days) cycle. Rollover and retention kept investigative questions about recent activity fast, while older data migrated to cheaper states and subsequently expired. The Elasticsearch heap was also capped at 11 GB (roughly about 33\% of the total RAM), which, alongside the ILM policy, kept the indexing and the search responsive under the allotment of 500\, GB.

\paragraph{Reflection.}
This ILM policy extends previous capture choices (e.g., Suricata PCAP=\texttt{all}, \texttt{lz4}, no truncation) by making the data lifecycle explicit and sustainable. In a production SOC, such parameters would be re-evaluated as part of concurrent rule tuning and BPF filtering: if the visibility is broadened, ILM time-periods and rollover sizes could need to be narrowed to offset the growth that results from the wider ingest, all while still permitting investigative requirements and regulations.

\section{Validation of Deployment}
A Validation phase follows installation and configuration: a final check-up over the whole platform was performed, in order to ensure that after the applied changes all services were running and that meaningful security telemetry was being captured as expected.

\subsection{Service Verification}
Status checks confirmed that Suricata, Zeek, and Elasticsearch were active and stable. The SOC web interface displayed active dashboards and confirmed that logs were being ingested continuously. At this stage, baseline logs from routine activities, such as HTTP browsing and DNS queries, were already visible.

\subsection{Functional Testing with Sample Traffic}
Some controlled traffic was generated to validate detection efficiency:
\begin{itemize}
    \item \textbf{ICMP (Ping):} confirmed Zeek’s ability to log connection metadata and Suricata’s visibility of basic flows.
    \item \textbf{HTTP Requests:} verified logging of URIs, methods, and response codes.
    \item \textbf{Nmap Scan:} triggered Suricata’s ET SCAN rules, generating clear alerts visible in the SOC dashboard.
\end{itemize}
These simple yet effective tests guaranteed that the node was properly receiving mirrored traffic and that both Suricata and Zeek were able to process it.

\subsection{Dashboard Inspection}
Kibana visualizations were explored to confirm log ingestion. The built-in dashboards showed:
\begin{itemize}
    \item Alert distributions by signature (e.g., ET SCAN Nmap detection).
    \item Top source and destination IPs.
    \item Protocol breakdowns (TCP, UDP, ICMP).
\end{itemize}
The ability to pivot between alerts and raw logs reinforced the value of combining Suricata and Zeek within the same Elastic environment.

\section{Tuning and Log Management}
Although the initial deployment confirmed that everything ran as expected, the raw outputs were insufficient for a realistic monitoring scenario. Without tuning, Security Onion tends to generate excessive alerts, many of which may be irrelevant or redundant in a given network.

\subsection{Suricata Rulesets}
Suricata was configured with both the \textbf{Emerging Threats Open (ETOpen)} rule-set and the \textbf{GPL} rules. These cover a wide range of malicious behaviors, known as \emph{signatures}, from scanning activity to malevolent command-and-control traffic. Here are presented just a small portion of the rules, treated as examples here, that were tuned as follows:
\begin{itemize}
    \item \textbf{Suppressions:} ET INFO Spotify P2P and Windows Update P2P rules were suppressed for internal subnets (172.22.2.0/24), reducing the noise from legitimate background traffic.
    \item \textbf{Thresholds:} ET INFO Microsoft Connection Test, enabled to trigger if more than two events per hour were identified; effectively lowered benign alerts exposition.
    \item \textbf{Custom Alerts:} New self-made rules have been introduced to generate alerts only after specific iterated events, ensuring that unusual benign events did not replicate all over multiple dashboards.
\end{itemize}
Selectively suppressing and thresholding specific events kept an high investigative value of the alerts and lowered the amount of potential false positives.

\subsection{Sigma Rules}
Sigma, a generic log signature format, was adopted to monitor specific behaviors within system and authentication logs. Categories included:
\begin{itemize}
    \item \textbf{Active Directory and Privilege Escalation:} monitoring unauthorized replication requests or changes in DAC\footnote{DAC (Discretionary Access Control) is a permission model where object owners define access via ACLs; common in Windows/AD environments.} permissions.
    \item \textbf{Credential Dumping:} identification of LSASS\footnote{LSASS (Local Security Authority Subsystem Service) is the Windows process that handles authentication and stores credential material in memory; replicating or accessing it is usually a common attack step.} replication or Mimikatz-like tools usage.
    \item \textbf{Cobalt Strike Indicators:} detection of beaconing patterns and named pipes.
\end{itemize}

\subsection{YARA with Strelka}
Although Strelka was not the primary focus of this deployment, YARA rules can be used to detect malware artifacts within file samples captured in traffic flows. For instance, a Cobalt Strike beacon rule was enabled, which is activated when specific binary patterns such as \texttt{reflectiveLoader}\footnote{Typically an exported symbol or embedded string associated with reflective DLL loading, a technique that maps and runs a DLL directly in memory without using the OS loader, commonly used for in-memory code injection.}
 and \texttt{MalleableProfile}\footnote{A Cobalt Strike configuration (malleable C2 profile) that customizes network and artifact indicators for Beacon; references or derived patterns can link a sample to a particular C2 profile.} are acknowledged. This potentially enriches the multi-faceted detection strategy, combining Suricata signatures with file analysis.

\subsection{Log Lifecycle Management}
Elasticsearch’s ILM policy ensured that the logs were managed according to the previously discussed tiered model (hot–warm–cold–delete). This prevents uncontrolled growth of storage usage, a critical aspect to take care of, given the 500 GB disk allocation. Furthermore, by allocating 11 GB of heap memory, query responsiveness in Kibana remained consistent even during intensive searches.

\subsection{Reflection}
This tuning process presented an important lesson: the value of an NDR platform is as much about the breadth of the rule-sets as it is about the flexibility to tune them to the environment being monitored. Suppressing or thresholding low-priority alerts decreased the amount of analysis time, while allowing targeted rules (e.g., looking for credential dumping) improved assurance that significant detections were accurate. That is, the process of tuning changed Security Onion from a chatty sensor to a contextual awareness-based detection platform.

\section{Challenges and Troubleshooting}
No installation or configuration activity is complete without obstacles. Despite the solid foundation provided by the official documentation, several practical issues emerged during this deployment.

\subsection{Resource Tuning}
The first major challenge involved resource allocation. Suricata and Elasticsearch are both resource-intensive services. Initial runs showed that Elasticsearch consumed excessive heap memory, leading to slower queries and occasional instability. This was mitigated by explicitly setting the heap size to 11 GB (approximately one third of the available RAM). Once tuned, the platform achieved consistent stability and responsiveness.

\subsection{Rule Noise and False Positives}
The number of default rule-set generated alerts presented an issue. Specifically, ET INFO event categories were commonly fired on benign activity like connection checks performed by Microsoft or P2P traffic initiated by Spotify. These would otherwise have suppressed more pertinent alerts, left unchecked. Suppression lists and threshold rules were implemented, as outlined above, to minimize false positives. This procedure was not merely an initial configuration: initial attack simulations demonstrated the requirement for iterative refinement until the "signal-to-noise" ratio was acceptable.

\subsection{Balancing Completeness with Efficiency}
This consideration to eliminate Stenographer in favor of Suricata also involved debate about completeness. Steno has the capability to capture packets in the raw, which could be significant based on forensic analysis; as such, it has high storage overhead. This consideration to use only Suricata was justified based on the project objectives: log analysis, as well as real-time detection. This compromise, nonetheless, is recognized as a limitation as well, where packet payloads were not retained at the packet level to facilitate future analysis.
\clearpage

\section{Comparison with Distributed Deployments}
Although this thesis relied on a standalone deployment, it is useful to compare it with distributed architectures to highlight differences and potential trade-offs.

\subsection{Distributed Architecture Overview}
In a distributed deployment, Security Onion splits the responsibilities across multiple nodes:
\begin{itemize}
    \item \textbf{Manager Node:} central point for orchestration, rule distribution, and SOC web interface.
    \item \textbf{Search Node:} dedicated to Elasticsearch and Kibana for handling high-volume queries.
    \item \textbf{Forward Nodes:} positioned across the network to capture and forward traffic.
    \item \textbf{Honeypot Nodes:} (optional) simulating vulnerable services to attract attackers.
\end{itemize}

\begin{figure}[H]
    \centering
    \includegraphics[width=0.5\textwidth]{figures/content/so-distributed.png}
    \caption{Distributed deployment architecture of Security Onion, showing role separation and scalability across nodes.}
    \label{fig:so-distributed-architecture}
\end{figure}

\subsection{Standalone vs Distributed}
Table \ref{tab:so-standalone-vs-distributed} summarizes the main differences between the two deployment strategies.
\begin{table}[H]
\centering
\begin{tabular}{|p{2cm}|p{5cm}|p{6cm}|}
\hline
\textbf{Aspect} & \textbf{Standalone} & \textbf{Distributed} \\
\hline
Complexity & Low: all services on one node & High: multiple nodes and orchestration \\
\hline
Scalability & Limited by single machine resources & Horizontally scalable across nodes \\
\hline
Performance & Adequate for small/medium traffic & Optimized for enterprise / high-throughput \\
\hline
Resilience & Single point of failure & Role separation increases fault tolerance \\
\hline
Use Case & Lab, proof-of-concept, SMB & Enterprise SOC, high traffic visibility \\
\hline
\end{tabular}
\caption{Comparison of standalone and distributed Security Onion deployments.}
\label{tab:so-standalone-vs-distributed}
\end{table}
\noindent For the purposes of this thesis, the standalone deployment proved its worth: it provided full visibility into the mirrored traffic, supported rule tuning, and enabled integration with an LLM pipeline. However, in production contexts, especially where multi-gigabit links or regulatory compliance are involved, distributed deployment would be obvious next step of the architecture evolution.
\clearpage

\section{Summary}
This chapter documented the installation and configuration of Security Onion in a standalone deployment. The activity began with provisioning a virtualized environment on a VMware ESXi hypervisor, allocating 33 GB of RAM and 500 GB of storage to the appliance. The installation process followed official guidelines, but with deliberate choices: enabling Suricata and Zeek for detection, configuring Elastic for log management, and consciously excluding Stenographer in favor of Suricata’s integrated capabilities.
\medskip\newline
Validation confirmed that the system was able to ingest mirrored traffic, generate alerts, and present them through dashboards. Subsequent tuning efforts focused on reducing noise from default rulesets, applying suppression and thresholds, and introducing Sigma and YARA rules for broader coverage. Log lifecycle management was tuned for sustainability and resource allocation was optimized through heap size adjustments.
\medskip\newline
Challenges such as false positives, resource balancing, and traffic mirroring misconfigurations highlighted the practical difficulties of deploying an NDR platform, even in a controlled environment. However, each hindrance contributed to a deeper understanding of both the technical stack and the operational mindset required in a SOC.
\medskip\newline
Finally, a comparison between standalone and distributed deployments underscored the limitations of scalability of the chosen architecture while also validating its suitability for research goals. The standalone setup achieved the desired balance between manageability and completeness, serving as a strong foundation for the experimental simulations and analyses that follow in the next chapter.
