\chapter{Conclusion and Future Work}

\section{Overview of the Research Journey}
This thesis presented an experimental end-to-end investigation of the feasibility and practical value of deploying \textit{Security Onion} as a Network Detection and Response (NDR) platform and augmenting it with a Large Language Model (LLM) assistant to streamline analysis. The path from background theory to implementation was intentionally hands-on: from a bare installation, through careful configuration and resource tuning, to a structured testing campaign with simulated attacks and finally, to the integration of an AI-driven SOC assistant capable of generating schema-aware Elasticsearch queries and summarizing results. 
\medskip \newline
The research deliberately highlighted the working choices and trade-offs experienced in practical contexts. Rather than assuming ideal situations, the development accounted for numerous constraints (like SPAN mirroring, single-node design, and limitations on storage) and noted the effect on observability, performance, as well as the analyst's workflow. At the same time, the project explored how an orchestrated approach toward field mappings, an index lifecycle management, and the formulation of queries could help move Security Onion beyond being just an aggregation of tools to being an integrated Network Detection and Response (NDR) capability. Inclusion of the large language model-based assistant built on the real Elasticsearch schemas of Suricata, Zeek, along with additional datasets, provided a distinct illustration to assess the potential of artificial intelligence to effectively diminish barriers for analysts while maintaining both rigor and auditability.

\section{Purpose, Coverage, and Constraints}
The primary objective was \emph{creating, deploying, and evaluating} an open-source and affordable NDR solution and \emph{determine} whether LLM assistance could assist in investigations so as to accelerate them as well as make them more systematic. This included:
\begin{itemize}
  \item Real-world installation and configuration of Security Onion (Suricata for IDS/NSM, protocol meta data using Zeek, Elastic Stack for storage, search, and visualization).
  \item Carefully selected set of attack scenarios run in a controlled environment against a vulnerable host, focusing on variety (scans, brute force, exploit, exfiltration patterns, suspicious downloads, lateral movement).
  \item Index life cycle policies and rule fine-tuning for maintaining the stability and interpretability of the system.
  \item An LLM-augmented question layer that converts natural-language intentions into well-formed, dataset-aware Elasticsearch DSL for correlation, aggregation, and matching.
\end{itemize}
The project worked under well-established bounds. The deployment was deliberately restricted to one node (standalone mode). Retention of packet capture was kept small (full-fidelity Stenographer PCAP archiving was not turned on) and no TLS decryption infrastructure was set up. These restrictions, although limiting, were taken in order to maintain scope and in favour of having a working, evaluatable prototype as opposed to an enterprise-level roll-out.

\section{What Was Built and Its Importance}
\subsection*{From Services to a Unified Platform}
The project assembled Suricata, Zeek, and Elastic components into a coherent system with well-defined data flows and a manageable analyst experience. The decisions were empirically justified: Suricata was tuned to prioritize reliable alerting on common exploit and malware signatures; Zeek was leveraged for high-value metadata (e.g., connection, DNS, HTTP, SMB logs) to support pivoting and cross-validation; Elasticsearch index lifecycle policies balanced retention and performance.

\subsection*{Attack Scenarios as Evaluation Tools}
Attack scenarios were not just demos; they were tools for measurement. Each scenario was designed to check for a different capability: signature-based exploit detection, behaviorally suspicious patterns (DNS anomalies, HTTP executable downloads), brute force on exposed services, lateral movement (SMB/WMI), and data exfiltration tactics (including covert DNS). Through logging the signals seen (actual alerting, metadata, correlations), the thesis created an reproducible process for measuring coverage and gaps

\subsection*{An LLM Assistant Grounded in Real Schemas}
The assistant was not a generic chatbot. It was systematically grounded in the actual Elasticsearch mappings of Security Onion datasets. It implemented matching, aggregation, and correlation behaviors with a progressive pipeline: extract anchor fields from the prompt, probe to discover relevant datasets, select fields per dataset, run queries, then summarize timelines and indicators. This design reduced the risk of hallucination, enforced structured JSON outputs, and produced human-auditable summaries. In essence, the assistant \emph{operationalized} AI support within the discipline of SOC investigation, rather than replacing human judgment.

\section{Empirical Results from the Testing Campaign}
\subsection*{Detections That Worked Reliably}
Classical scans and exploitation attempts (e.g., Nmap recon, EternalBlue-style SMB exploitation) elicited Suricata alarms at high confidence; Zeek provided protocol context (anomalies in the SMB session, service banners) by which the evidence could be meaningfully interpreted. Malicious HTTP executable downloads in the clear were highlighted both by Suricata's rules engine and by Zeek's HTTP logs, facilitating rapid pivoting on source/destination IPs, URIs, and user agents. SQL injection artifacts in HTTP parameters were also captured due to signature hits as well as supporting HTTP metadata.

\subsection*{Instances Where Detection Was Lacking or Non-existent}
Two gaps made the difference. Firstly, encrypted C2 over HTTPS essentially masqueraded as background traffic. In the absence of TLS interception or robust fingerprinting baselines (e.g., JA3/JA3S with policy on outliers), it was impossible for Suricata or Zeek to elevate this flow beyond generic TLS sessions. Secondly, DNS tunneling evaded static rules as there was no statistical baseline or entropy/length heuristics. It's not the fault of Security Onion in itself for not being able to detect these; it's the nature of today's threat landscape where encryption as well as covert channels are the normal not the anomaly.

\subsection*{Recognized Operational Trade-offs}
The system embodied the old saw of \emph{visibility} versus \emph{operability}. Aggressive rule-sets added wider coverage but also increased false positives, exerting pressure on CPU, memory, and analyst time. Tweaking and tuning rule-sets decreased noise but at the expense of detection gaps. Storage limitations demanded ILM policies that cut historical depth, trading completeness for system health. SPAN-based collection made the deployment easier but added possible packet loss and time artifacts. The thesis recorded these trade-offs openly and demonstrated practical methods for working through them.

\section{Deep Dive: Undetected and Hard-to-Detect Scenarios}
\subsection*{Encrypted C2 over HTTPS}
The encrypted C2 case made it clear that detection based on payload alone was not enough. Zeek's TLS logging (SNI, certificate details, cipher suites, versions) supports fingerprint-based heuristics but require curated and kept-up maintenance. A pragmatic plan should entail:
\begin{itemize}
  \item Creating per-host and per-segment TLS baselines (JA3/JA3S histograms; novel cipher.
  \item Rare-destination policy (e.g., first-seen domains for a host, low-reputation ASN), associated with time windows and working hours.
  \item Timing-based features, burstiness-based features, and packet size distributions for weakly supervised anomaly detectors.
\end{itemize}
The lesson is two-sided: first, encrypted traffic demands behavioral and contextual modeling; second, NDR should not attempt to do everything; endpoint signals and identity context are essential for closing the loop.

\subsection*{DNS Tunneling and Covert Channels}
Covert DNS exfiltration requires dual statistical - and semantic - level verification: query name length distributions, label entropy, NXDomain ratios, sudden transitions of RR types, as well as per-host baselines. Zeek DNS log files are ideal for providing some baseline context but meaningful detection occurs only when those features are adequately modeled. Steps for practical application include:
\begin{itemize}
  \item Maintaining rolling baselines per host/segment for query rates, lengths, and entropy.
  \item Triggering on persistent deviations, not sporadic peaks.
  \item Correlating with HTTP(S) destinations and process/identity context where it is available.
\end{itemize}
This undertaking underscored the feasibility of implementing such capabilities on the Security Onion platform; however, it necessitates focused feature extraction and the integration of either rule-based heuristics or machine learning components to transition from mere logs to practical detections.

\section{Operational Challenges and Lessons Learned}
\subsection*{Alert Fatigue and False Positives}
Default Suricata rules are intentionally broad; without tuning, they produce non-trivial noise (e.g., benign update traffic, P2P overlays). The project adopted thresholds, suppressions, and selective rule disabling, guided by observed traffic profiles. The key insight is organizational: \emph{detection engineering} is a continuous process, not a one-off configuration. Teams must allocate time to monitor rule health, track drift, and document the reasoning behind each tuning decision.

\subsection*{Resource Tuning and Stability}
Heap size for Elasticsearch, number of shards, and ILM temperature bands turned out to be crucial. Heap over-allocating incurs GC pause\footnote{Elasticsearch is written in Java and runs on the JVM; garbage collection periodically stops application threads to reclaim heap memory, causing brief “stop-the-world” pauses.}; heap under-allocating causes query timeouts. The practical take-away is that NDR platforms reside at the crossroads of both networking and distributed systems: the success depends on both security as well as platform engineering expertise.

\subsection*{Visibility vs.\ Forensics}
Disfavoring full PCAP retention (e.g., Stenographer) maintained storage but made simplicity unnecessarily expensive. To counteract this, the project relied on Zeek metadata and some choice Suricata log artifacts, knowing some deep-dive analyses would be beyond the scope of this deployment class. It's an acceptable trade-off for most small and mid-size environments.

\section{Challenges to Validity}
\subsection*{Internal Validity}
Experiment scenarios ran on a controlled test lab. Although this enhances reproducibility, it may overfit the lab's traffic patterns. To counteract, the test set was diverse in activity classes as well as cross-validated on several sets of data (Suricata alert data vs. Zeek's meta data). Biases still persist (background noise, host OS, version of services).

\subsection*{External Validity}
Results may not directly generalize to high-throughput, heterogeneous enterprise networks. Standalone mode cannot represent the scaling characteristics of distributed deployments. SPAN mirroring may unfaithfully represent lossless capture performance. These limits are acknowledged; the value lies in the \emph{method} and the \emph{engineering decisions} documented, which are transferable even when specific metrics are not.

\section{Academic and Industrial Significance}
\subsection*{Academic Importance}
The paper contributes an explicit, reproducible blueprint for turning Security Onion into an evaluatable research artifact. It demonstrates how to instrument important attack scenarios, how to measure detection in a lab considering hard constraints, and how an LLM assistant may be integrated without sacrificing auditability. It also identifies where NDR must develop (encrypted traffic, covert channels) as well as how open datasets (fields in the Zeek/Suricata protocols) may provide the foundation upon which ML investigations may proceed.

\subsection*{Industrial Importance}
For practitioners, the work shows how to deploy and operate a cost conscious NDR stack, prioritize tuning and build baselines that matter. It outlines a path to AI augmentation that is practical: schema-grounded, JSON-first, and compatible with human oversight. The approach can conceptually scale to larger networked environment with distributed Security Onion deployments.

\section{Lessons for Practitioners}
Three practical lessons followed:
\begin{enumerate}
  \item \textbf{Continuous tuning.} Continue considering rules and dashboards as dynamic assets. Monitor noise and value. Maintain change-log of tuning decisions.
  \item \textbf{Model the encrypted majority.} Plan for TLS-dominated traffic. Invest in fingerprints, baselines, and correlation with identity/endpoint context.
  \item \textbf{Auditability instrument.} Despite the use of AI assistance, make sure all questions and inferences may be referred back into the logs, indices, and fields.
\end{enumerate}
\clearpage

\section{Future Directions: Research Framework}
\subsection*{Encrypted Traffic Analytics}
Move beyond fixed fingerprints to sequence and graph-based modeling of flows, synthesizing TLS metadata, time, burstiness, and destination reputation. Investigate weak supervision (heuristic labels) for bootstrapping detectors where ground truth is not available.

\subsection*{Covert Channel Detection in DNS}
Engineer Zeek feature extractors for entropy, length, RR diversity, NXDomain ratios, and temporal locality. Compare rule-based thresholds with classical anomaly detectors (e.g., IF, LOF) and shallow neural approaches tuned for tabular time series.

\subsection*{LLM Reliability, Reproducibility and Guardrails}
Make outputs and prompts official versioned artifacts. Implement failure-safe fallbacks, deterministic decoding when possible, and schema constraints. To measure time saved, error rates, and trust calibration when analysts use the assistant, conduct user studies.

\subsection*{The First-Class Problem of Correlation}
Use anchor fields (such as \texttt{network.community\_id}, \texttt{log.id.uid}, \texttt{IP} tuples, and timestamps) to transition from ad hoc pivots to a principled correlation layer. Use DAGs to represent investigations so that each conclusion can be replayed and explained. 

\subsection*{Shareable and Open Benchmarks}
In order to advance NDR and AI-for-SOC research toward shared baselines, publish sanitized mappings, synthetic traffic recipes, and replayable attack traces. This would promote cumulative progress and speed up comparison.

\clearpage
\section{Future Directions: Enterprise Framework}
\subsection*{Distributed Security Onion at Scale}
Adopt multi-node architectures with dedicated search nodes, hot/warm/cold tiers via ILM, and resilient ingest. Instrument SLOs for query latency and data freshness. Validate loss characteristics with TAPs where feasible.

\subsection*{Compliance-Aware Monitoring}
Include GDPR/ISO 27001 considerations in access, masking/pseudonymization, and retention policies. Provide evidence packs and exports from the SOC assistant that are ready for compliance.

\subsection*{AI-Powered Triage and Orchestration}
Transition from assistive querying to assistive workflow: to lower MTTD/MTTR, the assistant creates tickets, improves IOCs, suggests containment playbooks, and initiates guarded automations (while keeping humans informed).

\subsection*{Endpoint and Identity Fusion}
In order to score detections based on host, process, and user context, Endpoint and Identity Fusion connects NDR with EDR and IAM sources. Higher-confidence escalations and accurate suppression of false positives are made possible by this.

\subsection*{Cost Control and Operational Hardening}
Establish rule-pack baselines, golden dashboards, and configuration-as-code (Ansible/Terraform) as formal processes. Monitor the cost of infrastructure versus the value of detection, and periodically reevaluate retention, regulations, and sensors in light of the measured utility.

\subsection*{Integration of a SOAR Platform}
The next step is to integrate an enterprise SOAR platform in order to scale beyond local playbooks. A case management system (like TheHive) will receive Security Onion alerts for triage, enrichment, and evidence tracking, and an automation engine (like StackStorm) will carry out authorized actions using standardized packs. In addition to supporting change control across staging and production, the design aims for high availability, role-based approvals, and complete audit trails. Message queues or webhooks are used for dependable delivery.

\subsection*{Enabling Response in the NDR Pipeline}
Beyond detection, the platform should carry out controlled response steps. Concretely: promote alerts to cases, apply containment (blocklists at the edge, host isolation on the switch, egress restriction to approved services), verify the effect on traffic, and record outcomes. Procedures will be versioned, tested, and auditable; rollback is mandatory for every action.

\section{Final Considerations}
This thesis aimed to do something concrete: turn an open-source stack into a functioning NDR platform, test it against realistic attacks, and explore whether AI could make the analyst’s work faster and clearer. It succeeded and, equally important, it exposed precisely where success must be qualified. Encrypted traffic and covert channels demand feature engineering and correlation beyond what signatures alone can provide. Scalability and compliance require distributed architectures and disciplined data governance. AI can assist meaningfully, but only under guardrails that preserve auditability and human control.
\medskip \newline
The central contribution is therefore twofold. First, a \emph{documented, reproducible path} from installation to evaluation that others can adopt and adapt. Second, a \emph{set of empirically grounded insights} about where open-source NDR excels, where it struggles, and how AI can be responsibly integrated today. The overarching message for both research and industry is hopeful but practical: with careful engineering, open tooling, and measured use of AI, it is possible to build security monitoring that is transparent, adaptable, and effective. The work presented here is not an endpoint; it is a foundation—one on which stronger, more autonomous, and more trustworthy defenses can be built.
