IJNSA 01

SOC using AI: Design and End-to-End Validation of an AI-Assisted Security Operations Center

Hashim Jarrar, Ahmad Aldarawish and Hatem Al-Kishawi, Middle East University, Jordan

Abstract

SOC using AI is an integrated Security Operations Center that combines deterministic detection with controlled AI assistance. Windows telemetry is collected through Sysmon and the Wazuh Agent, while Zeek and Suricata provide network visibility. Wazuh performs first-stage decoding and rule evaluation. A Python watcher selects newly generated security-relevant alerts, suppresses duplicate analysis, invokes local Ollama assistance, performs public-IP reputation checks through AbuseIPDB when appropriate, correlates related evidence, and stores incident data in SQLite for FastAPI and dashboard access. The wider platform also includes a CICIDS2017-oriented inference service with Random Forest, XGBoost, and Decision Tree artifacts; this ML service is a supporting component and is not presented as quantitatively benchmarked in this paper. Controlled host and network tests operationally verified the core event-toincident path, database integrity, agent connectivity, and service health. The reported results are limited to evidence observed in the final laboratory environment and do not constitute a statistical performance benchmark.

Keywords

Security Operations Center, Wazuh, Artificial Intelligence, Machine Learning, Incident Correlation

1. INTRODUCTION

Security Operations Centers depend on evidence from endpoints, network sensors, authentication systems, applications, and infrastructure. The operational challenge is not only to collect this information, but to preserve its source, identify security-relevant activity, and give analysts enough context to investigate efficiently. NIST describes intrusion detection and prevention as a combination of host-based, network-based, and complementary monitoring technologies [1]. SOC using AI follows this layered approach.

The project was implemented as a containerized SOC environment rather than as a stand-alone classifier or dashboard. Its validated core connects Windows endpoint telemetry, Zeek and Suricata network monitoring, Wazuh SIEM/XDR processing, project-specific detection rules, a Python watcher and analysis pipeline, local Ollama assistance, conditional AbuseIPDB
enrichment, incident correlation, SQLite persistence, FastAPI, and an analyst-facing dashboard. The repository also contains supporting services for machine-learning inference, response workflows, feedback, and monitoring.

A central design choice is that Wazuh remains the detection authority. AI receives selected alerts only after rule evaluation. It explains, prioritizes, and suggests investigation steps, but it does not turn raw telemetry into an authoritative alert by itself. This keeps the original evidence traceable and allows Wazuh to continue collecting and detecting if an AI service is unavailable.

1.1. Problem and Contribution

The project addresses the gap between collecting many security events and turning them into amanageable incident workflow. In a manual process, analysts may need to search SIEM data,
inspect endpoint logs, consult network sensors, query reputation services, and assemble notes
separately. SOC using AI links these activities in one path: telemetry is detected deterministically, selected alerts receive controlled AI and threat-intelligence context, related
evidence is correlated, and the resulting incident is stored and exposed through the same analyst interface. The contribution is therefore architectural and operational: integration, traceability, and analyst support are treated as one system rather than separate demonstrations.

2. TECHNOLOGY BASIS AND PROJECT SCOPE

2.1. Endpoint and SIEM Monitoring

Sysmon records detailed Windows activity such as process creation, network connections, and
file-related events [2]. The Wazuh Agent forwards host evidence to the central Wazuh environment, where decoders and rules normalize events and determine whether an alert should be generated [3]. This arrangement provides a stable host-to-SIEM path and retains the original rule identifier, severity, timestamp, and event data for later investigation.

2.2. Network Security Monitoring

Zeek and Suricata serve different purposes in the network-monitoring layer. Zeek produces structured metadata for connections and application protocols, including DNS, HTTP, and TLS, and records unusual protocol behavior [4]. Suricata adds signature-oriented IDS/IPS and network-security-monitoring capability [5]. The project uses them as complementary sensors rather than interchangeable tools.

2.3. AI, Machine Learning, and External Context

The local language-model layer runs through Ollama [6]. It is used after Wazuh detection to translate alert evidence into an analyst-friendly explanation, provide investigation context, and suggest reasonable next actions. The project also contains a machine-learning inference service built around Random Forest, XGBoost, and Decision Tree artifacts for CICIDS2017-style network-flow input. The implemented service contract expects 77 features. Because the final endto-end validation did not reproduce a controlled labeled benchmark for those artifacts, this paper describes the ML service as an implemented supporting capability and does not repeat accuracy or latency claims that were not re-measured in the final environment.

Threat-intelligence enrichment uses AbuseIPDB APIv2 [7]. Before an external lookup, an indicator is classified as publicly routable or internal. Private, loopback, and other internal addresses are not submitted. This minimizes disclosure of internal addressing and avoids sending indicators for which public reputation has no meaningful value. MITRE ATT&CK is used as a behavioral vocabulary for selected detections and investigation context, not as a replacement detection engine [8].

2.4. Related Work and Project Positioning

Research on intrusion detection has long examined machine-learning methods for separating benign and malicious activity. Buczak and Guven survey data-mining and machine-learning approaches for cyber intrusion detection [9], while Sommer and Paxson caution that operational network intrusion detection differs substantially from closed-world classification [11]. More recent work has moved toward AI-assisted SOC operations. A 2024 SIEM study highlights the continued role of SIEM platforms as the operational aggregation and response layer, including their convergence with analytics [15]. AACT learns from analyst triage decisions to prioritize or close alerts and reports evaluation on real SOC and open data [16]. Cognitive SOC uses specialized LLM agents to transform alerts into evidence-backed narratives and explicitly evaluates evidence linkage, citations, hallucination, and time-to-recommendation [17]. CORTEX similarly frames LLM alert triage as collaboration among specialized agents operating over enterprise evidence [18]. These systems emphasize automated triage or agentic reasoning; SOC using AI instead focuses on an evidence-preserving integration boundary in which deterministic Wazuh rules remain the detection authority and AI output is advisory context attached to, rather than substituted for, the original alert.

The contribution is therefore not the invention of a new detector or foundation model. It is the implemented and inspectable workflow that joins endpoint and network telemetry, deterministic SIEM detection, controlled alert selection, duplicate suppression, conditional public-IP enrichment, local LLM assistance, incident correlation, persistence, API access, and an analystfacing interface while preserving provenance. This differs from approaches that place an AI model directly in the decision path: the Wazuh alert remains independently auditable, external enrichment is data-minimized, and generated recommendations do not autonomously trigger containment. Table 1 summarizes the practical positioning against representative recent work. Online sources for the representative studies discussed above: SIEM study [15]; AACT [16];Cognitive SOC [17]; CORTEX [18].

Table 1. Positioning against representative recent AI/SIEM security work.

3. SYSTEM DESIGN

3.1. Layered Architecture

The implemented path begins at the sensors. Windows endpoints provide Sysmon and Wazuh
Agent telemetry; Zeek and Suricata provide network evidence. Wazuh performs decoding, rule evaluation, and alert generation. The Python AI engine then watches newly generated alerts, filters them by rule and level, suppresses repeated analysis, and forwards accepted alerts to the remaining analysis stages. Local AI, public-IP enrichment, correlation, persistence, FastAPI, and the dashboard sit behind this deterministic boundary.

Figure 1. Validated core architecture of SOC using AI.

3.2. Incident-Centered Data Model

The logical model is centered on the incident rather than on isolated AI outputs. An incident groups one or more alerts. Each alert retains its Wazuh evidence, including the rule identifier, severity, addressing information, description, timestamp, and raw event content. AI analysis and threat-intelligence records are supporting records linked to the alert. Analyst or response lifecycle actions are linked to the incident so that assignment, containment, resolution, results, and notes can be audited without modifying the underlying evidence.

Figure 2. Simplified incident-centered logical model for the validated core.

3.3. Alert-to-Incident Sequence

A new event first reaches Wazuh through the endpoint or network collection path. After rule evaluation, the watcher sees the generated alert and applies its configured selection controls. An accepted alert receives local AI context. If an address is suitable for an external query, the pipeline obtains reputation context; otherwise, that step is skipped. The correlator then persists the incident and its supporting evidence, and FastAPI makes the result available to the analyst interface.

Figure 3. Alert-to-incident processing sequence.

4. IMPLEMENTATION

4.1. Containerized Environment and Service Roles

Docker and Docker Compose isolate the central services and make the environment reproducible [13]. The Wazuh server, indexer, dashboard, and Filebeat form the SIEM core. The validated processing path includes the Python watcher, analyzer, correlator, threat-intelligence integration, persistence layer, FastAPI, and analyst dashboard. The wider repository also contains supporting alert-triage, correlation, feedback, flow-feature processing, gateway, RAG, rule-generation, retraining, response-orchestration, and monitoring services. SQLite is the database used for the validated incident-persistence path, while other data services belong to the broader project infrastructure.

Table 2. Core platform components and their roles.

4.2. Detection Engineering

Project-specific Wazuh rules convert Zeek-derived JSON events into detections that the watcher can use. Rule 110100 establishes the base Zeek event. Rule 110101 provides DNS NXDOMAIN context, while 110102 flags Zeek ‘weird’ behavior at level 7. Rule 110110 provides the connection-correlation base. Rules 110111 and 110112 represent possible and high-volume scans using frequency thresholds and suppression periods. Rules 110120 and 110121 provide a DNScorrelation chain. Selected host rules, including 5712 and 92213, are also part of the watcher allow-list.

Table 3. Project-specific Wazuh and watcher logic .

4.3. Watcher Controls and Duplicate Suppression

The watcher follows Wazuhalerts.json persistently and handles only alerts generated after it starts. A minimum rule level and an explicit allow-list restrict which events enter the analysis pipeline. Duplicate suppression prevents repeated evidence from creating unnecessary AI analyses. These controls became important during testing because replaying historical data or
accepting every event would inflate analysis counts and make the dashboard harder to interpret.

4.4. Local AI Analysis

The validated local model is llama3.2:3b through Ollama. The input to the model is the selected alert and its relevant security fields, not unrestricted raw telemetry. The generated output is stored as supporting context: a readable explanation, prioritization guidance, investigation observations, and recommended analyst actions. The original Wazuh alert remains separate so that the analyst can audit the evidence independently of the generated text.

4.5. Machine-Learning Inference

The repository includes a dedicated ML inference API with Random Forest, XGBoost, and Decision Tree model artifacts. The current service interface expects 77 ordered CICIDS2017 style network-flow features. This capability is separate from the Wazuh alert watcher and the local LLM. It can support network-flow classification and later correlation, but the final validation recorded for this project focused on the operational alert-to-incident path. For that reason, this paper does not present a new accuracy, precision, recall, F1, false-positive-rate, or inference-latency result for the ML models.

4.6. Noise Control and Address Handling

Testing showed that the SOC could observe its own infrastructure. Loopback and containerinternal traffic sometimes resembled scan activity, so the correlation logic was tuned to exclude the relevant internal ranges while preserving endpoint-originated discovery. The same principle is applied to threat intelligence: private addresses are retained as evidence but are not transmitted to the external reputation provider.

4.7. Persistence, API, and Analyst Interface

The validated incident workflow persists data in SQLite. FastAPI exposes health, incident, analytics, and investigation functions through a typed Python API with OpenAPI support [14]. The interface brings together the executive overview, real-time monitoring, alert evidence, incident management, analytics, system health, and the AI-assisted investigation workspace. Original evidence remains visible beside generated context rather than being replaced by an AI verdict.

4.8. Reproducibility and Test Environment

The final laboratory deployment used a Kali Linux virtual machine as the central/container host with 24 GB RAM, a DockerizedWazuh Manager 4.8.2, and one active Windows endpoint monitored through the Wazuh Agent and Sysmon. Zeek and Suricata supplied network telemetry from the monitored laboratory network. The local LLM was llama3.2:3b served through Ollama on a Windows host and reached by the analysis service over the laboratory network. The validated watcher tailed Wazuhalerts.json, used a minimum alert level of 7, selected configured rule IDs (including 110102, 110111, 110112, 5712, and 92213), applied a 60-second duplicate window, and persisted resulting incidents in SQLite. Port-scan correlation used frequency/timewindow controls: rule 110111 used 20 events within 60 seconds with a 120-second ignore period, while rule 110112 used 50 events within 60 seconds with a 180-second ignore period. The final evidence package did not preserve exact Zeek and Suricata version numbers or a repeatable CPU allocation record; those values are therefore not invented here and should be captured in a future reproducibility manifest.

5. VALIDATION METHODOLOGY

Validation was performed in layers. Individual components were checked first, then integration points, and finally controlled end-to-end scenarios. This order avoided a common testing mistake: a healthy container or open port does not prove that a security event can cross the whole SOC pipeline.

5.1. Component and Integrity Checks

Table 4. Component and integrity checks recorded in the validated environment.

5.2. Integration Checks

Table 5. Integration checks for the end-to-end path.

5.3. Controlled Security Scenarios

The final validation evidence contains three representative scenario categories: (1) network discovery/scan activity, including the possible-scan and high-volume-scan paths represented by rules 110111 and 110112; (2) a benign executable-drop event that produced a critical incident in the incident-management workflow; and (3) host authentication/process evidence, including an invalid OpenSSH login attempt and an abnormal-process command alert. These scenarios exercise different layers of the pipeline. The scan path was observed through Zeek/Wazuh correlation and watcher processing; the executable-drop scenario exercised endpoint evidence and incident persistence; the authentication/process observations confirmed additional host visibility. Repetition counts and event-to-incident or LLM latency were not instrumented consistently in the final run, so this paper does not report invented averages or statistical timing claims.

These scenarios were selected to prove traceability rather than to maximize attack-technique coverage. Duplicate suppression was configured with a 60-second watcher window, and Wazuh correlation rules also used explicit ignore periods, but the final evidence set did not record a controlled duplicate-injection experiment from which a suppression percentage could be calculated. Table 6 separates the evidence actually observed from steps that were not established for every scenario.

Table 7. Evidence chain observed in controlled laboratory scenarios.

6. RESULTS AND DISCUSSION

The strongest observed result is operational traceability: for the controlled paths that traversed the configured workflow, an originating host or network event can be followed into Wazuh evidence, watcher selection, optional AI/public-IP context, correlation and persistence, and finally the API/dashboard view. This is an end-to-end functional verification of the implemented path, not a throughput, latency, detection-accuracy, or analyst-productivity benchmark.

Testing also exposed operational issues that are easy to miss in a diagram. Internal infrastructure can generate security-like traffic, so scan logic needs carefully chosen exclusions. Historical replay can cause duplicate analysis, so the watcher must distinguish new events from backlog. External enrichment should be selective, both for privacy and because private address space has no useful public reputation. Generated explanations must remain visibly separate from deterministic evidence. These findings shaped the final implementation.

The project contains ML artifacts and a working inference service, but the final evidence set does not justify treating repository benchmark claims as new results of this paper. The defensible statement is narrower: the service is implemented, three model families are available, and its current input contract uses 77 CICIDS2017-style features. A publishable performance claim would require a frozen dataset split, reproducible preprocessing, the exact deployed artifacts, and a reported confusion matrix and timing methodology.

6.1. Manual and AI-Assisted Investigation Workflow

The implemented system changes how several routine investigation steps are assembled. The comparison below is functional: it describes which tasks the platform assists or centralizes. It does not claim a measured reduction in investigation time because a controlled manual baseline was not recorded during the final validation.

 

Table 6. Functional comparison of a manual workflow and SOC using AI support.

This comparison should not be interpreted as an MTTD or MTTR benchmark. A defensible numerical claim would require the same incident set to be investigated under controlled manual
and AI-assisted conditions, with start and stop criteria defined in advance.

6.2. Evaluation Boundaries and Reproducibility

The validation reported in this paper is deliberately separated into operational verification and model benchmarking. Operational verification asks whether telemetry can travel through the implemented pipeline, whether selected Wazuh detections reach the analysis layer, whether the resulting context is persisted, and whether an analyst can retrieve the incident through the API and dashboard. These checks can be supported directly by service status, alert records, database records, and controlled security scenarios. They do not, by themselves, establish a machine learning accuracy percentage.

A reproducible machine-learning evaluation requires a fixed labeled test partition, a documented preprocessing pipeline, the exact feature schema expected by the inference service, and per-class predictions that can be compared with ground truth. Accuracy alone is insufficient for an imbalanced intrusion-detection problem; precision, recall, F1-score, false-positive rate, and a confusion matrix should be reported together. The current manuscript therefore describes the Random Forest, XGBoost, and Decision Tree service as a supporting component without assigning an unverified final performance number.

The same boundary is applied to analyst-efficiency claims. The system clearly automates or centralizes several repetitive steps, including alert selection, public-IP reputation enrichment,
correlation, persistence, and presentation. However, a numerical statement such as a percentage reduction in investigation time would require a controlled experiment in which the same incident set is investigated manually and with AI assistance under predefined start and stop criteria. Until such measurements are collected, the paper limits the comparison to workflow capabilities rather than claiming a measured MTTR or MTTD improvement.

6.3. AI Output Review and Safety Boundary

The final validation did not include a blinded or statistically powered human-rating study of LLM explanations. Accordingly, the paper does not claim measured AI accuracy. Representative generated output was inspected together with the underlying Wazuh evidence to confirm that the interface preserves the source alert and presents the LLM text as supporting context rather than authoritative detection. Hallucination and inconsistent output remain explicit risks: a generated explanation can omit context, overstate causality, or recommend an action that is not justified by the evidence. The control is architectural rather than trust-based. The LLM does not create the authoritative alert, the original Wazuh evidence remains visible, and escalation/containment decisions remain analyst-controlled. Model unavailability therefore degrades explanation support but does not stop Wazuh collection and rule-based detection. Unsupported recommendations are not treated as autonomous response actions; production SOAR automation is outside the validated scope.

6.4. End-to-End Evidence Chain

The implemented evidence chain begins at endpoint and network telemetry. Windows events collected by the Wazuh agent and Sysmon, together with Zeek and Suricata network telemetry, are centralized through Wazuh. Custom and built-in Wazuh rules perform the deterministic firststage detection. A Python watcher then applies configured selection controls before forwarding relevant alerts to the analysis workflow. This design prevents the language model from becoming the primary detection authority and preserves the original security event as the basis for investigation.

For selected events, the analysis layer generates contextual information such as severity interpretation, risk-oriented prioritization, investigation guidance, and a concise analyst-facing explanation. Threat-intelligence enrichment is restricted to applicable public IP addresses; private or internal addresses are not submitted to the external reputation service. Correlation logic groups related evidence into incident-centered records, after which SQLite persistence and the FastAPI interface make the resulting incident, supporting analysis, and related evidence available to the dashboard.

Controlled end-to-end tests are most useful when each stage can be independently inspected. A valid test therefore checks the originating event, the Wazuh alert and rule metadata, watcher selection, generated analysis, persisted database record, API response, and dashboard presentation. This layered verification approach helps distinguish a detection failure from a transport, analysis, persistence, or presentation failure and makes troubleshooting more defensible than relying only on the final dashboard view.

7. SECURITY, RELIABILITY, AND LIMITATIONS

Several design decisions reduce the risk of the analysis layer weakening the SOC. Detection continues to be rule-based and independent of the LLM. Threat-intelligence enrichment is dataminimized: only an applicable publicly routable IP indicator is submitted to AbuseIPDB; private, loopback, and container-internal addresses remain local evidence and are not queried externally. The final validation evidence did not preserve a credential-storage audit, so this paper does not make an unsupported claim about the exact secret-management mechanism; production deployment should keep the AbuseIPDB API key outside source code, prompts, and dashboard output. The local Ollama model keeps LLM processing inside the laboratory environment rather than sending alert text to a hosted generative-AI service. Generated analysis is persisted as supporting incident context, while the original Wazuh alert remains separate and auditable. A separate audit of raw prompt retention was not recorded in the final experiment.

The environment remains a laboratory deployment. It has not been load-tested at enterprise event volumes, and the final validation does not establish statistically rigorous integrated ML accuracy, measured end-to-end latency, quantified false-positive reduction, or fully autonomous production SOAR. Untrusted log content is also a security boundary: log strings can contain attackercontrolled text and could act as prompt-injection-style input if copied directly into an LLM prompt. The safe design assumption is therefore to treat telemetry as data, constrain the fields passed to the model, separate system instructions from event content, avoid granting the LLM direct execution privileges, and require analyst approval for response actions. The final experiment did not include a dedicated prompt-injection benchmark, so resistance to such attacks is not claimed. Local LLM quality depends on the selected model and compute resources; AbuseIPDB enrichment depends on provider availability and policy; and network visibility depends on correct capture-interface placement.

8. FUTURE WORK

The next stage should turn the existing components into repeatable experiments. The deployed Random Forest, XGBoost, and Decision Tree artifacts should be evaluated against a frozen labeled dataset using the same 77-feature preprocessing contract, with accuracy, precision, recall, F1 score, false-positive rate, and confusion matrices reported together. Controlled workloads should also measure alert throughput, API latency, queue behavior, and resource use. Other useful extensions include tighter ML-to-incident correlation, approval-gated SOAR playbooks with rollback, distributed or high-availability deployment, and richer retrieval-augmented investigation using MITRE ATT&CK, internal runbooks, detection history, and lessons learned.

8.1. Planned Quantitative Evaluation

The next evaluation phase should freeze the exact ML artifacts and preprocessing code, construct a held-out labeled test set using the same feature definition expected by the inference API, and record the confusion matrix and per-class predictions. From these outputs, accuracy, precision, recall, F1-score, and false-positive rate can be calculated and reported with the dataset split, class distribution, software versions, and hardware environment needed for reproduction.

A second experiment should evaluate analyst effort. A fixed set of representative incidents can be investigated first with the manual tool workflow and then with the AI-assisted workflow, or by counterbalanced analyst groups to reduce learning effects. The study should define when investigation begins, what constitutes a completed triage decision, and which activities are timed. Reporting median investigation time together with error or disagreement rates would provide a defensible basis for any future claim that the system improves SOC efficiency.

9. CONCLUSIONS

SOC using AI demonstrates an evidence-preserving way to add AI assistance to a Security Operations Center. The implemented system combines Windows endpoint telemetry, Zeek and Suricata network monitoring, Wazuh rule-based detection, a Python watcher and correlation path, local Ollama analysis, conditional public-IP enrichment, SQLite persistence, FastAPI services, an analyst-facing dashboard, and a supporting three-model ML inference service. Controlled laboratory scenarios operationally verified representative paths from observed activity to inspectable incident evidence. The ML service remains a supporting component because this study did not perform a new reproducible accuracy or latency benchmark of its model artifacts.

The project also shows why the boundaries between these components matter. Detection is kept deterministic, AI output is treated as supporting analysis, external enrichment is data-minimized, and operational controls prevent internal noise and duplicate processing from overwhelming the investigation layer. This foundation is suitable for future benchmarking and automation, provided that new performance claims are measured against reproducible workloads rather than inferred from the presence of a service or model.

ACKNOWLEDGEMENTS

The authors thank Dr. Hashem Jarrar for supervising the project and for his guidance during the design, implementation, and validation stages.

REFERENCES

[1] K. Scarfone and P. Mell, (2007) “Guide to Intrusion Detection and Prevention Systems (IDPS),” NIST Special Publication 800-94.

[2] Microsoft, (2026) “Sysmon in Windows,” Microsoft Learn, accessed Aug. 29, 2026.

[3] Wazuh, (2026) “Architecture – Getting started with Wazuh,” Wazuh Documentation, accessed Aug.29, 2026.

[4] Zeek Project, (2026) “What Is Zeek?” Book of Zeek, accessed Aug. 29, 2026.

[5] Open Information Security Foundation, (2026) “What is Suricata,” Suricata User Guide, accessedAug. 29, 2026.

[6] Ollama, (2026) “Ollama Documentation,” accessed Aug. 29, 2026.

[7] AbuseIPDB, (2026) “AbuseIPDB APIv2 Documentation,” accessed Aug. 29, 2026.

[8] MITRE, (2026) “MITRE ATT&CK Enterprise Matrix,” accessed Aug. 29, 2026.

[9] A. L. Buczak and E. Guven, (2016) “A Survey of Data Mining and Machine Learning Methods forCyber Security Intrusion Detection,” IEEE Communications Surveys & Tutorials, Vol. 18, No. 2, pp.1153–1176.

[10] I. Sharafaldin, A. H. Lashkari, and A. A. Ghorbani, (2018) “Toward Generating a New IntrusionDetection Dataset and Intrusion Traffic Characterization,” Proceedings of ICISSP, pp. 108–116.

[11] R. Sommer and V. Paxson, (2010) “Outside the Closed World: On Using Machine Learning for Network Intrusion Detection,” IEEE Symposium on Security and Privacy, pp.305–316.

[12] L. F. Sikos, (2021) “AI in Cybersecurity,” Journal of Cybersecurity and Privacy, Vol. 1, No. 1, pp. 1–10.

[13] Docker, (2026) “Docker Compose Documentation,” Docker Documentation, accessed Aug. 29, 2026.

[14] FastAPI Project, (2026) “FastAPI Documentation,” accessed Aug. 29, 2026.

[15] “Analysis, Trends, and Utilization of Security Information and Event Management (SIEM) in CriticalInfrastructures,” (2024) 10th International Conference on Advanced Computing and CommunicationSystems (ICACCS),DOI:10.1109/ICACCS60874.2024.10717237.

Available:https://doi.org/10.1109/ICACCS60874.2024.10717237

[16] M. Turcotte, F. Labrèche, and S.-O. Paquette, (2025) “Automated Alert Classification and Triage (AACT): An Intelligent System for the Prioritisation of Cybersecurity Alerts,” arXiv:2505.09843. Available: https://arxiv.org/abs/2505.09843

[17] “Cognitive SOC: Evidence-Backed Narrative Generation for Security Operations with Multi-Agent LLM Architecture,” (2025) IEEE International Conference on Big Data(BigData), DOI:10.1109/BigData66926.2025.11401968.

Available:https://doi.org/10.1109/BigData66926.2025.11401968

[18] B. Wei, Y. S. Tay, H. Liu, J. Pan, K. Luo, Z. Zhu, and C. Jordan, (2025) “CORTEX: CollaborativeLLM Agents for High-Stakes Alert Triage,”arXiv:2510.00311.Available:https://arxiv.org/abs/2510.00311

AUTHORS

Dr. Hashim is an assistant professor in the department of cybersecurityMiddle East University – MEU. His research interests include cybersecurity, databases, big data, ontologies, information systems, image encryption

 

Ahmad Basem Ahmad Aldarawish is a Cybersecurity student at the Department of Cybersecurity, Faculty of Information Technology, Middle East University – MEU. His research interests include Security Operations Centers (SOC), Incident Response, Malware Analysis, Threat Detection, and AI-assisted cybersecurity.

Hatem Nabhan Al-Kishawi is a Cybersecurity student at the Department ofCybersecurity, Faculty of Information Technology, Middle East University – MEU.His research interests include Network Security, Critical Infrastructure Security, Malware Analysis, and Cybersecurity