# ROSCA: Robust and Scalable Security Alert Correlation and Prioritisation using the MITRE ATT&CK Framework

Rémi Garcia, Abdelkader Lahmadi, Pierre-François Gimenez, Charles Sala

► To cite this version:

Rémi Garcia, Abdelkader Lahmadi, Pierre-François Gimenez, Charles Sala. ROSCA: Robust and Scalable Security Alert Correlation and Prioritisation using the MITRE ATT&CK Framework. WATCH 2025 - First International Workshop on Analytics, Telemetry, and Cybersecurity for HPCC (High Performance Computing and Communications), Oct 2025, Taipei, Taiwan. 10.1145/3733826.3762680. hal-05351162

HAL Id: hal-05351162

https://inria.hal.science/hal-05351162v1

Submitted on 6 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# ROSCA: Robust and Scalable Security Alert Correlation and Prioritisation using the MITRE ATT&CK Framework

Rémi Garcia

Université de Lorraine, CNRS, Inria, LORIA

Nancy, France

remi.garcia@inria.fr

Pierre-François Gimenez

Univ. Rennes, Inria, IRISA

Rennes, France

pierre-francois.gimenez@inria.fr

Abdelkader Lahmadi

Université de Lorraine, CNRS, Inria, LORIA

Nancy, France

abdelkader.lahmadi@loria.fr

Charles Sala

Hospices Civils de Lyon

Lyon, France

cybersecurity@chu-lyon.fr

## Abstract

In large organisations and complex infrastructures, the overwhelming volume of security alerts often results in analyst fatigue, delayed responses, and missed attacks. Security Operations Centers (SOCs) typically rely on black-box commercial solutions, offering limited transparency into their alert classification mechanisms and lacking the flexibility for in-house adaptation or re-implementation. To address these limitations and improve situational awareness, this paper proposes ROSCA, an efficient alert prioritisation method grounded in the MITRE ATT&CK kill chain model. The proposed approach automatically aggregates and correlates alerts based on their shared attributes, enabling the construction of contextualised cases. Each case is assigned a score reflecting its threat level, before being presented to analysts within a prioritised queue. Our method handles multi-stage attack patterns and supports rapid processing through a robust, noise-tolerant scoring mechanism designed for interpretability and operational integration. We validate the effectiveness of ROSCA on real-world alert data and compare it against the MATE framework, demonstrating superior prioritisation accuracy and more reliable identification of critical alerts.

## CCS Concepts

* Security and privacy → Intrusion detection systems.

## Keywords

Alert correlation, Intrusion detection, Anomaly detection

## ACM Reference Format:

Rémi Garcia, Abdelkader Lahmadi, Pierre-François Gimenez, and Charles Sala. 2025. ROSCA: Robust and Scalable Security Alert Correlation and Prioritisation using the MITRE ATT&CK Framework. In *Proceedings of the 2025 Workshop on Analytics, Telemetry, and Cybersecurity for HPCC (High-Performance Computing and Communications) (WATCH '25)*, October 13–17, 2025, Taipei, Taiwan. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3733826.3762680

<figure><img src="image_2.png" /></figure>

This work is licensed under a Creative Commons Attribution 4.0 International License. WATCH '25, Taipei, Taiwan

© 2025 Copyright held by the owner/author(s).

ACM ISBN 979-8-4007-1914-1/25/10

https://doi.org/10.1145/3733826.3762680

## 1 Introduction

Correlating the overwhelming volume of security alerts in noisy and complex environments remains a persistent challenge in both research and operational settings. IT environments, in particular, deploy sophisticated security mechanisms and operate under high volumes of network and process data, leading to an excessive number of alerts that can easily saturate Security Operations Centers (SOCs) [15]. In practice, many of these alerts are low-value or irrelevant, making it difficult to identify those requiring immediate attention. This prioritisation bottleneck can significantly delay SOC responses to critical incidents [10].

Due to alert fatigue and time constraints, analysts frequently limit their focus to recent alerts or disregard large portions of incoming data. A key aspect of this challenge is understanding attacker progression within coordinated campaigns. The MITRE ATT&CK framework [1] provides a structured taxonomy of adversarial behaviours that can serve as a foundation for interpreting and contextualising alerts.

A popular approach to extract insights from large volumes of data is the use of deep learning, due to its strong statistical performance. However, critical challenges remain regarding the interpretability of results, generalisation to unseen data, and overall reliability [16, 20]. In practice, these methods often require substantial computational resources and time-intensive training processes, without guaranteed effectiveness outside the training domain.

Moreover, from the perspective of security analysts, the utility of such models depends not only on accuracy but also on the ability to contextualise alerts within the broader kill chain. Reliable context reconstruction is essential for identifying exploits and understanding how specific alerts fit into an orchestrated attack campaign. Without this contextual awareness, even accurate detection may fall short of supporting effective defence and response strategies.

To address these limitations, we propose an alert correlation and prioritisation mechanism that builds on intrusion detection outputs. By organising related alerts into higher-level cases structured through the MITRE ATT&CK framework, our approach aims to enhance situational awareness and streamline SOC decision-making.

In this work, we emphasise simplicity, generality, and resource efficiency. Our goal is to design a prioritisation solution that is deployable and adaptable in real-world environments, without requiring high-level expertise, while being self-contained and fully automated. ROSCA, our RObust and Scalable Correlation of Alerts,
is designed to be agnostic to both alerts' data sources and formats, requiring no prior knowledge of the underlying network topology. This ensures broad compatibility across diverse technologies and deployment contexts. Given our focus on noisy environments—where alert streams are often inundated with false positives—we introduce mechanisms to ensure robustness against such interference. ROSCA constructs a dynamic graph of alerts, where nodes represent alert groups and edges reflect semantic similarities across relevant fields. Through this graph, alerts are aggregated into coherent cases, which are scored and prioritised. The final output is a ranked list of alert cases, ready for analyst review and further investigation. To promote deployability across diverse environments and ensure the reproducibility of our experiments, we provide a publicly available implementation of ROSCA in Python, without any third-party dependencies, and under the GPLv3 licence<fnref n="1" />.

The rest of the paper is organised as follows. Section 2 presents the MITRE ATT&CK classification and previous research work for alerts correlation. The approach for field extraction is then discussed in Section 3.1, followed by the aggregation and correlation algorithm in Section 3.2. We evaluate our solution in Section 4 on authentic alert flows for both endpoint and IDS network alerts, and provide elements of comparison with similar research. We detail our conclusions and future perspectives in Section 5.

# 2 Background and related work

## 2.1 The MITRE ATT&CK framework

This work builds upon the MITRE ATT&CK framework [1], a widely adopted threat classification standard that has gained significant traction since its introduction in 2013. Designed to support forensic analysis and threat intelligence, ATT&CK offers a comprehensive taxonomy of threats across multiple platforms. It provides a structured knowledge base that links attack techniques, tactics, and threat actor objectives, enabling systematic cross-referencing between observed behaviours and known attack patterns.

Within this framework, malicious activities are modelled as components of Advanced Persistent Threats (APTs)—long-term, targeted campaigns that unfold through a defined sequence of stages, often referred to as the attack kill chain. The deployment of an APT is structured hierarchically using the Tactics, Techniques, and Procedures (TTP) model. At the lowest level, procedures represent concrete adversary actions, grouped into techniques or sub-techniques that reflect common attack methods. These, in turn, are associated with one or more tactics, which define high-level objectives (e.g., Reconnaissance or Credential Access) within the attack kill chain.

In this work, we focus on the Enterprise matrix of the MITRE ATT&CK framework, which provides a broad, general-purpose classification applicable across diverse enterprise environments. It encompasses adversarial behaviours observed on Windows, macOS, Linux, cloud infrastructures, networks, and containerised systems, making it well-suited for comprehensive threat modelling.

The tactics within the Enterprise matrix are organized to reflect the progression of an attack along the kill chain—a sequencing that is central to our algorithm. At the time of writing, the ordered list of Enterprise tactics is as follows: *Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation,*

*Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, and Impact.*

This perspective allows for a more contextualised and better understanding of threats, moving beyond isolated alerts for recognising coordinated and progressive adversarial actions. For alert-to-case interpretation, we leverage the metadata provided by existing security solutions already deployed within the SOC environment. These include both endpoint and network-based detection systems, many of which are at least partially aligned with the MITRE ATT&CK framework in their current implementations.

## 2.2 Alerts aggregation and correlation

Aggregation and correlation of security alerts is not a new field of study, and much research has been undergone in this direction. Debar et al. published fundamental work in [3], addressing IDS alerts. The authors then process alerts across several probes, aggregating on source, target, and alert class to give a condensed view of the security issues. The correlation step labels alerts either as duplicates or consequences of other events.

Morin et al. [11] later proposed a formalisation of IDS alert correlation in first-order logic, revolving around system characteristics, vulnerabilities, security tools, and events and alerts. The specific problem of alert flooding is discussed in [18], where alerts are modelled as time-series related flows, and only deviations from normal are reported to the operator. This concept of deviation-based processing against alert fatigue is part of NoDoze [6] where alert dependency graphs are generated, after interpretation of process-level logs to determine what is a likely malicious deviation.

SIEM-based alert correlation has been explored in [4], where alert information is enriched with expert knowledge on attacker behaviour. This relies on domain-specific knowledge and security team intervention to establish custom rules.

Hassan et al. have contributed to endpoint alert provenance [5]. Their threat scoring methodology assesses risk based on temporal ordering between individual alerts. In contrast to the retention of unwieldy system logs, it maintains a minimally-sufficient skeleton graph that provides linkability between existing and future alerts.

Recent advances in Machine Learning have given rise to contributions focusing on pattern extraction for multi-stage attack campaigns, with various training requirements. Unsupervised solutions of interest include AECID [14]: it is format-agnostic and generates aggregated meta-alerts incrementally. Still unsupervised with a graph representation of deviations from normal, Lyu et al. [9] use network-tailored learning, at the cost of adaptability. Another expertise-independent contribution is GRAIN [19], that reconstructs IDS alerts into a causality graph, after aggregation based on similarities between alerts' attack semantics. With a small amount of expert intervention, HeAT [12] works on a set of network agnostic features and a small set of analyst defined critical alert episode relations. The authors extract and prioritise meaningful attack campaigns that cover diverse attack stages. Another method with which we share graph aspects is SAGE [13], that relies on the FlexFringe framework [17] to infer temporal and probabilistic dependencies between alerts in a suffix-based probabilistic deterministic finite automaton.

<footnote n="1">¹https://gitlab.inria.fr/resist/watch-rosca-alert-prioritisation</footnote>
The work most closely related to ours is MATE [8], which adopts graph-based aggregation and correlation, as well as the MITRE ATT&CK kill chain model. Our work builds on the recommendations of Landauer et al. [7], who evaluated approaches such as [13, 14]. In line with these insights, we adopt a graph-based representation of aggregated alerts to support contextual analysis and threat progression modelling. The originality of this contribution lies in its self-contained design and its ability to deliver results in a lightweight, fast and robust manner for easier deployment and adaptability. Indeed, ML approaches rely on complex frameworks that can cause setup, maintenance, and performance issues. ROSCA requires no expert knowledge or intervention, is entirely automatic, and does not define a “normal” baseline state that could be exploited with cleverly crafted attacks. We improve over MATE in terms of prioritisation in noisy settings, while being suitable for both endpoint and network alerts.

## 3 ROSCA pipeline

This section details the entire pipeline of ROSCA. It goes from receiving raw alert data, extracting relevant information from it to create alert objects, and correlate those objects in a graph, based on contextual field similarities. The final alert's scores reflect the topology of the obtained graph, and a prioritised list of cases that includes those alerts is ultimately forwarded to the analyst. Figure 1 details the overall pipeline of our approach.

<figure><img src="image_3.png" /><figcaption>Figure 1: Pipeline of alert processing and prioritisation</figcaption></figure>

### 3.1 Fields extraction

Many standardisation attempts have targeted the alert format problem, notably resulting in the IDMEF [2] nomenclature. We acknowledge that those standards, despite their merits, are not used systematically in practice. In consequence, we do not attempt to normalise the output of our data sources with a common format. Instead, we provide generic data extraction structures that can be leveraged transparently, and populated with source-specific field keys and extraction functions. This way, the core algorithm is agnostic to data format, and relies on custom parsing functions. For example, the tactic of an alert might not be directly extractible, because it is present as an alias to MITRE classification, or because only technique information exists. Our structure includes a tactics getter taking raw alert data and returning tactic indexes. When nothing better than an alert's textual description is usable to infer tactics, we allow relying on a Large Language Model (LLM) for such mapping.

The fields for which extraction is not possible are allocated null or stub values, in order to keep the general method flexible with as

little mandatory fields as possible. The subsequent prioritisation algorithm would lose in precision if information is missing, but still be able to process incomplete alert reports. We assume that severity information is present for every alert, which can be arbitrary, as long as it details distinct levels.

To give a better account of the entities involved in an alert, source, and destination IP addresses should be resolved to hosts whenever possible. This would help with processing alerts from multiple sources in a single report, since endpoint alerts on hosts could be compared to network alerts, usually involving IPs.

### 3.2 Graph aggregation and correlation algorithm

The goal of our approach is to sort alerts by priority, given their kill chain context, in real time. We extract selected fields from alerts, aggregate them based on MITRE ATT&CK tactic and entity information, and link obtained vertices according to common fields. The history of all alerts seen so far is split in time slots of configurable length, to group them by relevant periods of time. This section presents the data structures and algorithms used to dynamically construct and maintain a directed graph of alerts.

#### 3.2.1 History structure.
To efficiently record alerts for retrieval, the history is structured in a top-down indexing way, as shown in Figure 2. In detail, the history is composed of a queue of tuples, each of them denoted by $(t, byTacs)$, for $t$ a time slot and $byTacs$ a tuple with as many entries as there are MITRE tactics, each tactic index representing an entry.

Every field of $byTacs$ then corresponds to alert occurrences within a certain tactic. Those occurrences are grouped by field values in another tuple $byFields$, for each field used for aggregation and correlation. Then, for each field $f$, we record a mapping from its values such that for every value $fv$, we obtain the alerts with field $f$ value matching $fv$.

This approach eliminates the need to iterate over the entire history to process a new alert, thereby avoiding the associated $O((n * f)^2)$ time complexity, with $n$ alerts and $f$ considered fields for matching. Instead, correlating the history is done in $O(n * f * ts)$, with $ts$ time slots, since the maximum tactics number is a constant.

<figure><img src="image_4.png" /><figcaption>Figure 2: History structure for alert retrieval</figcaption></figure>

For example, let an alert A defined as $\{timeStamp = 0; tacticIndex = 0; source = S; destination = D\}$. It will be allocated to the first time slot, and then to the first list entry by tactics for this time slot. The source and destination fields will respectively record A under the S and D values, yielding a record as in Figure 3.
<figure><img src="image_5.png" /><figcaption>Figure 3: Example of alert in history structure</figcaption></figure>

### 3.2.2 Aggregation.
The aggregated alerts must share a common contextual provenance. For this reason, the alerts are aggregated based on their occurrence time, and allocated to their respective matching time slots. Given that we target operational environments, both user accounts and host machines represent critical assets. To capture contextual relationships, we group alerts by time slot, tactic index, source, destination, and username. This aggregation strategy—similar in spirit to the MATE and SAGE approaches [8, 13]—enables a level of granularity suited for enterprise environments with multi-account usage and complex access patterns. The source and destination fields can be IPs as well as hosts.

To prevent over-linking during lateral movement analysis, we avoid grouping alerts with different sources or destinations into the same vertex. For example, with several destinations per vertex, a single alert whose destination matches some new alert's source would trigger an edge creation between their two respective vertices, even if the other alerts' destinations in the predecessor vertex do not match the lateral movement pattern. The same problem occurs with the reverse situation of multiple sources per vertex.

A given alert might correspond to several tactics *Ts*, in which case one alert object is created for each tactic. In the final prioritised list, only the alert object with the highest tactic index among *Ts* is included. We present the aggregation technique in Algorithm 1.

Each vertex is assigned the maximum severity observed among its associated alerts. This ensures that, during graph construction, maximal local criticality is preserved. Relying on an average severity could obscure high-impact alerts and underestimate the risk associated with a given entity at a specific MITRE tactic stage.

### 3.2.3 Correlation.
After grouping alerts by MITRE tactic, related entities, and temporal proximity, historical alerts are queried to identify potential contextual links with the current ones. This step enables the detection of multi-stage attack patterns, helping analysts determine whether a given alert is part of a coordinated campaign or an isolated event. The detailed instructions are provided in Algorithm 2, and we justify our design choices below.

The scoring takes into account previous alerts along a kill chain: we iterate through time slots up to the current one as well as tactics, looking for vertices with both lower tactics and fields matching the current alert to correlate. The considered number of past time slots is configurable. Fields are, as synthesised in the aggregation step, the username, source, destination or any other field considered as useful, like filename or signature. Any field given a null value

Algorithm 1 Aggregate(A, H, Vs, tSize)

Input: A latest alert, *H* chronological history, *Vs* existing vertices, *tSize* time slot duration;

Output: *V* vertex containing *A*;

1: **if** *H* is empty **then**

2: &nbsp;&nbsp;&nbsp;&nbsp;*A.timeSlot* ← *A creationTime*

3: **else**

4: &nbsp;&nbsp;&nbsp;&nbsp;lastTimeSlot, lastRecords ← last(*H*)

5: &nbsp;&nbsp;&nbsp;&nbsp;timeSinceLast ← *A creationTime* - lastTimeSlot

6: **if** timeSinceLast < tSize **then**

7: &nbsp;&nbsp;&nbsp;&nbsp;*A.timeSlot* ← lastTimeSlot

8: &nbsp;&nbsp;&nbsp;&nbsp;*V* ← vertex in Vs such that its id corresponds to *A*

9: **if** *V* exists **then**

10: &nbsp;&nbsp;&nbsp;&nbsp;*V.ownScore* ← max(*V.ownScore*, *A.severity*)

11: **else**

12: &nbsp;&nbsp;&nbsp;&nbsp;*V* ← new vertex with *A*

13: **end if**

14: &nbsp;&nbsp;&nbsp;&nbsp;Merge mappings from fields of *A* to *A* in lastRecords[*A.tacticIdx*]

15: &nbsp;&nbsp;&nbsp;&nbsp;*V.alerts* ← *V.alerts* ∪ {*A*}

16: &nbsp;&nbsp;&nbsp;&nbsp;return *V*

17: **else**

18: &nbsp;&nbsp;&nbsp;&nbsp;*A.timeSlot* ← *A creationTime* - (timeSinceLast mod tSize)
{*A* is more recent than last time slot}

19: **end if**

20: **end if**

21: &nbsp;&nbsp;&nbsp;&nbsp;*V* ← new vertex with *A*

22: &nbsp;&nbsp;&nbsp;&nbsp;recordsByTactic ← ({} ..., for each matching field), ..., for each MITRE tactic)

23: &nbsp;&nbsp;&nbsp;&nbsp;Add mappings from fields of *A* to *A* in recordsByTactic[*A.tacticIdx*]

24: &nbsp;&nbsp;&nbsp;&nbsp;Append (*A.timeSlot*,recordsByTactic) to *H*

25: &nbsp;&nbsp;&nbsp;&nbsp;return *V*

Algorithm 2 Correlate(A, H)

Input: *A* alert in vertex *V*, *H* chronological records by time slot;

Output: *A* scored alert with an enriched context graph

1: **predecessorsCandidates** ← {}

2: **for** timeslot, tacticsByTimeSlot in *H* **do**

3: &nbsp;&nbsp;&nbsp;&nbsp;**for** *tac*=0 to size(*tacticsByTimeSlot*) - 1 **do**

4: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*alsByUsr*,*alsBySrc*,*alsByDst*,*alsByOtherFields* ← tacticsByTimeSlot[*tac*]
{Get linking candidates by matching fields, or potential machine switching.
We exclude alerts simultaneous to *A*}

5: **if** *tac* < *A.tacticIdx* **then**

6: &nbsp;&nbsp;&nbsp;&nbsp;predecessorsCandidates ← predecessorsCandidates ∪
&nbsp;&nbsp;&nbsp;&nbsp;verticesOf(*alsByUsr*.get(*A.user_name*) ∪ *alsBySrc*.get(*A.source*) ∪
&nbsp;&nbsp;&nbsp;&nbsp;*alsByDst*.get(*A.destination*) ∪
&nbsp;&nbsp;&nbsp;&nbsp;{*alsByOtherFields*[field].get(*Afield.value*)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for field in *A.otherFields*})

7: **end if**

8: &nbsp;&nbsp;&nbsp;&nbsp;predecessorsCandidates ← predecessorsCandidates ∪
&nbsp;&nbsp;&nbsp;&nbsp;verticesOf(*alsByDst*.get(*A.source*))

9: **end for**

10: **end for**

{The predecessors' ownScore attributes exclude alerts simultaneous to *A*}

11: **bestALPred** ← bestVtx(predecessorsCandidates)

12: **bestALPredScore** ← bestALPred.ownScore + bestALPred.predecessorsScore

13: **if** bestVtx({bestALPred,V.bestPredecessor}) = bestALPred **then**

14: &nbsp;&nbsp;&nbsp;&nbsp;*V.predecessorsScore* ← bestALPredScore

15: &nbsp;&nbsp;&nbsp;&nbsp;*V.tacticsSoFar* ← *A.tacticIdx* ∪ bestALPred.tacticsSoFar

16: &nbsp;&nbsp;&nbsp;&nbsp;*V.bestPredecessor* ← bestALPred

17: **end if**

18: Add the edge (bestALPred,V)

19: &nbsp;&nbsp;&nbsp;&nbsp;*A.finaScore* ← *V.ownScore* + bestALPredScore + *A.tacticIdx* +
&nbsp;&nbsp;&nbsp;&nbsp;size(bestALPred.tacticsSoFar) + min(size(*V.alerts*), *V.ownScore*)

cannot trigger an edge creation based on its value. No link can be created based on two simultaneous alerts' fields.

A vertex stores its own severity score and its predecessors' cumulative severity score. To identify the most critical vertex within a set *vtxs*, the function *bestVtx(vtxs)* selects the vertex *V* ∈ *vtxs* that maximizes the sum *V.ownScore* + *V.predecessorsScore*. In case of ties, the selection is refined using *V.tacticIdx* as a secondary criterion, and finally by the size of *V.tacticsSoFar* as a last resort. Only creating
an edge with bestVtx(vtxs) helps keeping an uncluttered graph. This approach eliminates the need for graph traversal, enabling a lightweight implementation that assigns scores efficiently.

We remark that we do not replace existing edges when a new alert in a vertex establishes its final score using a new path. This is to help analysis on every alert: each alert A in a vertex V can create one permanent path leading to V: the most critical path leading to A. Consequently, to avoid a cluttered report, not all candidate predecessors of A trigger an edge creation. Still, an incoming alert A' cannot delete the path that led to A in V.

In our design, the maximum path length corresponds to the number of tactics in the MITRE ATT&CK *Enterprise* matrix, except with lateral movement. This exception is due to the fact that an attacker can typically do reconnaissance on some host after having compromised a first machine. We then drop the tactic progression criteria to track this attacker along a chain of hosts.

As for graph maintenance with a bounded history, deleting the oldest vertices would not erase their successors' memories of past severities, allowing us to reason on old and deleted events.

*Scoring components.* The final score of an alert A has several components, reflecting its context information. The most fundamental one is the severity of the alert, added to the severities of its kill-chain predecessor vertices along a path composed of bestVtx results. A's tactic index is added to the alert's score, along with the number of tactics seen so far, meaning the current length of the kill chain.

To achieve a relevant interpretation of severity levels, we adopt an exponential scale with 4 levels: “low” given a value of 2, “medium” given 4, “high” with 8, and finally “critical” with a value of 16. Those valuations ensure a pertinent and clear distinction between severity levels, and a similar influence between severity and tactic values. Indeed, at the time of writing, the MITRE ATT&CK Enterprise matrix comprises 14 tactics. Poorly balanced severity and tactic values could lead to alerts staying in a category given by one of those fields, the other only being able to modify the category’s internal ordering. For example, a “low” severity alert with a high tactic index and some context must be able to overtake an isolated “medium” alert with low tactic index.

We could have included the tactic index in the vertex's score, but with linking over time, this could result in high severity and tactics alerts being too easily overtaken in score by lower severity and tactics ones that have even just a little context.

We also add a bounded score component based on alert count, but we do not include it in the vertex score, for the same snowballing reason as with the tactic index, and to avoid being vulnerable to scoring manipulation by the attacker. Such an adversary could craft a high number of low significance alerts in a short period of time, exploiting this score component to drown more serious alerts under trivial ones. We then ignore how many alerts there were in previous vertices, but since we retain the maximum severity as a vertex score, we preserve a notion of context criticality in the current vertex. As of now, this score cannot exceed the vertex severity score, so as not to weigh more than the worst severity at a certain point in time for a certain tactic, user, source, and destination. With a strict bound, including this alert count allows the analyst to differentiate between entities victim of similar exploits as a coincidence, and those being repeatedly targeted in an orchestrated campaign.

## 3.3 Alerts to cases

The aggregation and correlation process constructs a graph in which each vertex V, through its alerts Als, can have predecessors determined by Als. The highest-scoring path leading to an alert among Als is called the critical path of V. For any given terminal vertex Vt, a corresponding case is defined as the set of alert paths leading to Vt. The score of this case is the one of its critical path, and evolves dynamically: as new successor vertices are linked, the case may expand, effectively lengthening the associated kill chain. The final score assigned to vertex Vt corresponds to the highest in-context score among its constituent alerts—specifically, the top-scoring alert within the last vertex of the kill chain.

## 4 Experimental evaluation

We evaluate the prioritisation results based on datasets extracted from a hospital's security logs. However, the contribution described in this paper does not depend on industry-specific data.

We provide a Python implementation of both our technique and the core MATE algorithm [8]. By design, this implementation avoids the use of third-party tools or libraries to maximize deployability, explainability, maintainability, and adaptability. Simplicity is a core principle of the approach, ensuring these goals are met while also satisfying computational efficiency requirements.

We collected, anonymised, and benchmarked the alert data against MATE and our own technique. The performance of the studied implementations is measured by their respective rankings of alerts compared to the manual labels attributed by SOC analysts to those alerts. Ultimately, the objective is to assess if any given solution is suitable to give an analyst relevant prioritisation and to optimise the SOC response time in case of serious events.

### 4.1 Our datasets and data selection

This study is conducted both on endpoint and network IDS alerts. The endpoint alerts are raised by an Endpoint Detection and Response (EDR) system deployed across the organisation's hosts. The IDS is an internal one that serves as a second-line detection method between hosts of different services, in case those are compromised.

The resulting alerts have different formats, and we extract fields with by-source functions. In this work, we extract the source, destination, username and tactic, but also any provided file name or hash as additional fields for matching. We include below an anonymised alert example, and illustrate the fact that data sometimes only partly adheres to MITRE ATT&CK, as for TTP information.

```json
{
    "category": "Malware",
    "mitreTechniques": {
        "T1036.005",
        "sha256": "b346c642c18b1425342756cbb25c2aef68acd...",
        "FileName": "1457249744786818021",
        "id": "a919ce797dcdf46f67dda83252cf2b2b3c9c72e2c...",
        "severity": "low",
        "createdDateTime": "2025-03-13T13:56:03.0466667Z",
        "user": "a779bdce370d841bd8d6ffb2521f8ada25b114e...",
        "dest_host": "e2a5268fa1f3294ce07faf21bb4aeccee0..."
    }
}
```

The “Malware” mention is ambiguous and could refer to multiple tactics, without strong certainty as to which ones. Fortunately, this alert includes a specific technique T1036.005, in this case “Masserading: Match Legitimate Resource Name or Location” that maps to the Defense Evasion tactic. We present results for alerts with
enough information to certainly infer their tactics, in order to avoid biasing the results with inaccuracies that are not algorithm-related.

## 4.2 Comparison with MATE

We re-implemented the MATE [8] scoring approach for comparison purposes, and describe briefly here its basic principles:

* Aggregate alerts into vertices based on a common *Timeslot*, *tactic*, *source*, *user* tuple.

* Given an incoming alert A and its vertex VA, link other existing vertices with VA if they represent a tactic inferior or equal to A's, and contain an alert with field values that respectively match A's source, user, or any other field deemed useful, except for destination.
As for lateral movement, link an existing vertex VA' to VA if VA' contains an alert A' whose destination is equal to A's source, and A' is at least as old as A.

* A case is formed by each connected component, and its score is the cumulated severities of all alerts along the highest-severity path in the studied component, plus the number of distinct tactics along this path.

Since MATE aggregates on source but not on destination, for endpoint comparisons, we interpreted the source field to be the machine from which the alert is raised in MATE. This avoids aggregating alerts under a *null* value, as for machine information.

A crucial aspect differing from MATE here is requiring a strict progression of tactic index: if we allowed linking with same-tactic alerts, having many instances of the same recurring alert over time could lead to a very high final score, and a generally unbounded number of vertices along the selected path.

To evaluate scoring accuracy, we rely on manual SOC labels. These include “Ignored”, given when an alert appears serious enough to be forwarded to the SOC, but was ruled innocuous.

It is important to note that literal labels such as “False Positive” may not fully capture the complexity of an alert—this designation could apply both to trivial alerts and to events that warranted further investigation. Therefore, a nuanced assessment by analysts is essential to accurately evaluate the effectiveness of our prioritisation strategy. When consulted, analysts confirmed the relevance and usefulness of the scores produced by ROSCA. The correspondences between case scores and alert labels are shown in Figures 4 and 5. The “Unlabelled” status occurs with alerts that were either not forwarded to the SOC, or on which the SOC was inconclusive.

In the following, the labels presented belong to alerts in the last vertex of each case, as manual labelling is not infallible, and those end-of-kill-chain alerts are the most likely to be correctly labelled.

We present results for 382 endpoint alerts over two months, and 37 network IDS alerts in the 15-days available history. Each incoming alert is correlated with the entire history, and the most expensive aggregation and correlation process, with the endpoint alerts, terminates in 0.12 seconds, consuming 1.45MB of RAM. This is fully single-threaded and running on an i9-10900 CPU. We have also applied the algorithm on a dataset collected through a pentesting campaign that includes IPs, hosts, and lateral movement. We confirmed that kill chains were properly constructed, with few isolated vertices, in contrast to noisy everyday alerts.

The time and memory performance enables us to correlate an incoming alert with months of history, without losing the real-time aspect needed for swift analyst response. This makes our method suitable for detecting low-and-slow attack campaigns.

<figure><img src="image_6.png" /><figcaption>Figure 4: Endpoint last-vertex alert labels in percentages by case score with ROSCA</figcaption></figure>
<figure><img src="image_7.png" /><figcaption>Figure 5: Endpoint last-vertex alert labels in percentages by case score with MATE</figcaption></figure>

4.2.1 *Endpoint alerts prioritisation.* Overall, the results reveal significant differences in prioritisation between ROSCA and MATE. MATE tends to produce inflated scores due to its cumulative scoring mechanism, counting the severities of all alerts along a path

without enforcing strict adherence to tactic progression. This lack of constraint creates score “snowballing”, elevating the priority of alerts that are, in practice, labelled as low-impact or non-critical.

<figure><img src="image_8.png" /><figcaption>Figure 6: IDS last-vertex alert labels in percentages by case score with ROSCA</figcaption></figure>
In contrast, our method applies stricter linking criteria and avoids over-amplification, resulting in a more accurate prioritisation.

The top case contains an “Ignored” alert with MATE, hinting at a prioritisation problem, with a much higher score than other cases. The SOC confirmed that the alert is an unimportant recurring one, causing an artificially high score. Our technique is more resilient here, and our highest scored cases exclusively include alerts labelled “Confirmed Activity” or “Security test” in their last vertices.

### 4.2.2 IDS alerts prioritisation.
With our network IDS alerts, we observe in MATE that all vertices are isolated, and all cases get a score of 5. The aggregation on source only without destination, and the lack of linking based on destination, apart from lateral movement, are part of the reasons behind this situation. There is no significant discrimination between alerts, even though manual labels include “False positive”, “Confirmed Activity” and “Phishing”.

In contrast, a graph with edges is built with our solution, of which we present the results in Figure 6. In this bar chart, the false positives are mostly concentrated at the bottom of the prioritised list, while identified issues as phishing appear at the top.

With IDS alerts, we observe an under-linking on MATE's side, contrary to the over-linking seen with endpoint. ROSCA appears to behave well, whether we consider endpoint or IDS alerts.

## 5 Conclusions and Future Work

In this work, we introduce a lightweight, fast, and robust alert aggregation and correlation technique designed for ease of deployment. The approach operates without reliance on third-party tools and leverages the MITRE ATT&CK framework to model attack progression through successive adversarial tactics. ROSCA dynamically builds an interpretable alerts graph in real-time, according to corresponding alert fields. The algorithm outputs a prioritised list of cases, to address the most serious ones first.

Our evaluation demonstrates that we improve over comparable state-of-the-art approaches, while keeping resource usage to a level that allows to scale the alert processing in environments with many raised alerts per day. This scalability notably enables an analyst to search for correlations far in the history, and not only with few-days old alerts, for better low-and-slow attack campaign detection. We provide the implementation and anonymised case studies for reproducibility and adaptability in other environments.

Future work will focus on incorporating additional Cyber Threat Intelligence (CTI) metadata and contextual metrics to further enhance the alert prioritisation process. We also plan to expand support for diverse data sources with additional intrusion detection systems (IDS), network probes, and other security monitoring tools.

## Acknowledgments

This work has received funding from the Hospices Civils de Lyon as part of the SOC4HEALTH project. SOC4HEALTH is financed by the European Commission under grant agreement No 101127710.

## References

[1] The MITRE Corporation. 2013. MITRE ATT&CK. Available online: https://attack.mitre.org/ (accessed on 3 July 2025).

[2] Hervé Debar, David A. Curry, and Benjamin S. Feinstein. 2007. The Intrusion Detection Message Exchange Format (IDMEF). RFC 4765 (2007), 1–157. doi:10.17487/RFC4765

[3] Hervé Debar and Andreas Wespi. 2001. Aggregation and Correlation of Intrusion-Detection Alerts. In *Recent Advances in Intrusion Detection, 4th International Symposium, RAID 2001 Davis, CA, USA, October 10-12, 2001, Proceedings (Lecture Notes in Computer Science, Vol. 2212)*, Wenke Lee, Ludovic Mé, and Andreas Wespi (Eds.). Springer, 85–103. doi:10.1007/3-540-45474-8_6

[4] Gustavo Gonzalez Granadillo, Mohammed El-Barbori, and Hervé Debar. 2016. New Types of Alert Correlation for Security Information and Event Management Systems. In *8th IFIP International Conference on New Technologies, Mobility and Security, NTMS 2016, Larnaca, Cyprus, November 21-23, 2016*, Mohamad Badra, Giovanni Pau, and Vasos Vassiliou (Eds.). IEEE, 1–7. doi:10.1109/NTMS.2016.7792462

[5] Wajih Ul Hassan, Adam Bates, and Daniel Marino. 2020. Tactical Provenance Analysis for Endpoint Detection and Response Systems. In *2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, USA, May 18-21, 2020*. IEEE, 1172–1189. doi:10.1109/SP40000.2020.00096

[6] Wajih Ul Hassan, Shengjian Guo, Ding Li, Zhengzhang Chen, Kangkook Jee, Zhichun Li, and Adam Bates. 2019. NoDoze: Combatting Threat Alert Fatigue with Automated Provenance Triage. In *26th Annual Network and Distributed System Security Symposium, NDSS 2019, San Diego, California, USA, February 24-27, 2019*. The Internet Society. https://www.ndss-symposium.org/ndss-paper/nodoze-combatting-threat-alert-fatigue-with-automated-provenance-triage/

[7] Max Landauer, Florian Skopik, and Markus Wurzenberger. 2024. Introducing a New Alert Data Set for Multi-Step Attack Analysis. In *Proceedings of the 17th Cyber Security Experimentation and Test Workshop, CSET 2024, Philadelphia, PA, USA, 13 August 2024*. ACM, 41–53. doi:10.1145/3675741.3675748

[8] Derek Lin. 2022. MATE: Summarizing Alerts to Interpretable Outcomes with MITRE ATT&CK. In *IEEE International Conference on Big Data, Big Data 2022, Osaka, Japan, December 17-20, 2022*, Shusaku Tsumoto, Yukio Ohsawa, Lei Chen, Dirk Van den Poel, Xiaohua Hu, Yoichi Motomura, Takuya Takagi, Lingfei Wu, Ying Xie, Akihiro Abe, and Vijay Raghavan (Eds.). IEEE, 4295–4302. doi:10.1109/BIGDATA55660.2022.10020587

[9] Hongshuo Lyu, Jing Liu, Yingxu Lai, Beifeng Mao, and Xianting Huang. 2024. AGCM: A multi-stage attack correlation and scenario reconstruction method based on graph aggregation. *Comput. Commun.* 224 (2024), 302–313. doi:10.1016/J.COMCOM.2024.06.016

[10] Griffith Russell McRee. 2022. Improved Detection and Response via Optimized Alerts: Usability Study. *J. Cybersecur. Priv.* 2, 2 (2022), 379–401. doi:10.3390/JCP2020020

[11] Benjamin Morin, Ludovic Mé, Hervé Debar, and Mireille Ducassé. 2009. A logic-based model to support alert correlation in intrusion detection. *Inf. Fusion* 10, 4 (2009), 285–299. doi:10.1016/J.INFFUS.2009.01.005

[12] Stephen Moskal and Shanchieh Jay Yang. 2022. HeATed Alert Triage (HeAT): Transferrable Learning to Extract Multistage Attack Campaigns. *CoRR* abs/2212.13941 (2022). arXiv:2212.13941 doi:10.48550/ARXIV.2212.13941

[13] Azqa Nadeem, Sicco Verwer, Stephen Moskal, and Shanchieh Jay Yang. 2022. Alert-Driven Attack Graph Generation Using S-PDFA. *IEEE Trans. Dependable Secur.* *Comput.* 19, 2 (2022), 731–746. doi:10.1109/TDSC.2021.3117348

[14] Tom-Martijn Roelofs, Eduardo Barbaro, Svetlana Pekarskikh, Katarzyna Orz-chowska, Marta Kwapien, Jakub Tyrlik, Dinu Smadu, Michel van Eeten, and Yury Zhauniarovich. 2024. Finding Harmony in the Noise: Blending Security Alerts for Attack Detection. In *Proceedings of the 39th ACM/SIGAPP Symposium on Applied Computing, SAC 2024, Avila, Spain, April 8-12, 2024*, Jiman Hong and Juw Won Park (Eds.). ACM, 1385–1394. doi:10.1145/3605098.3635981

[15] Sathya Chandran Sundaramurthy, Alexandru G. Bardas, Jacob Case, Xinming Ou, Michael Wesch, John McHugh, and S. Raj Rajagopalan. 2015. A Human Capital Model for Mitigating Security Analyst Burnout. In *Eleventh Symposium On Usable Privacy and Security, SOUPS 2015, Ottawa, Canada, July 22-24, 2015*, Lorrie Faith Cranor, Robert Biddle, and Sunny Consolvo (Eds.). USENIX Association, 347–359. https://www.usenix.org/conference/soups2015/proceedings/presentation/sundaramurthy

[16] Shahroz Tariq, Mohan Baruwal Chhetri, Surya Nepal, and Cécile Paris. 2025. A2C: A modular multi-stage collaborative decision framework for human-AI teams. *Expert Syst. Appl.* 282 (2025), 127318. doi:10.1016/J.ESWA.2025.127318

[17] Sicco Verwer and Christian A. Hammerschmidt. 2017. flexfringe: A Passive Automaton Learning Package. In *2017 IEEE International Conference on Software Maintenance and Evolution, ICSME 2017, Shanghai, China, September 17-22, 2017*. IEEE Computer Society, 638–642. doi:10.1109/ICSME.2017.58

[18] Jouni Viinikka, Hervé Debar, Ludovic Mé, Anssi Lehikoinen, and Mika P. Tärvainen. 2009. Processing intrusion detection alert aggregates with time series modeling. *Inf. Fusion* 10, 4 (2009), 312–324. doi:10.1016/J.INFFUS.2009.01.003

[19] Fengrui Xiao, Shuangwu Chen, Jian Yang, Huasen He, Xiaofeng Jiang, Xiaobin Tan, and Dong Jin. 2025. GRAIN: Graph neural network and reinforcement learning aided causality discovery for multi-step attack scenario reconstruction. *Comput. Secur.* 148 (2025), 104180. doi:10.1016/J.COSE.2024.104180

[20] Xu-Yao Zhang, Guo-Sen Xie, Xiuli Li, Tao Mei, and Cheng-Lin Liu. 2023. A Survey on Learning to Reject. *Proc. IEEE* 111, 2 (2023), 185–215. doi:10.1109/JPROC.2023.3238024