DualAC₂NN: Revisiting and Alleviating Alert Fatigue from the Detection Perspective

Abstract

The exponential expansion of Internet interconnectivity has led to a dramatic increase in cyber-attack alerts, which contain a considerable proportion of false positives. The overwhelming number of false positives cause tremendous resource consumption and delay responses to the really severe incidents, namely, alert fatigue. To cope with the challenge from alert fatigue, we focus on enhancing the capability of detectors to reduce the generation of false alerts from the detection perspective. The core idea of our work is to train a machine-learning-based detector to grasp the empirical intelligence of security analysts to estimate the feasibility of an incoming HTTP request to cause substantial threats, and integrate the estimation into the detection stage to reduce false alarms. To this end, we innovatively introduce the concept of attack feasibility to characterize the composition rationality of an inbound HTTP request as a feasible attack under static scrutinization. First, we adopt a fast request-reorganization algorithm to transform an HTTP request into the form of interface:payload pair for further alignment of structural components which can reveal the processing logic of the target program. Then, we build a dual-channel attention-based circulant convolution neural network (DualAC${}_2$NN) to integrate the attack feasibility estimation into the alert decision, by comprehensively considering the interface sensitivity, payload maliciousness, and their bipartite compatibility. Experiments on a real-world dataset show that the proposed method significantly reduces invalid alerts by around 86.37% and over 61.64% compared to a rule-based commercial WAF and several state-of-the-art methods, along with retaining a detection rate at 97.89% and a lower time overhead, which indicates that our approach can effectively mitigate alert fatigue from the detection perspective.

1. Introduction

The last decades have witnessed a rapid development of network technology and its emerging applications, paralleled by an explosion in the number of cybersecurity threats, with continued evolution and sophistication. Among those, malicious HTTP requests, such as cross-site scripting (XSS) injections, SQL injections (SQLi), and remote command execution (RCE) attacks, etc. have been one of the most prevailing threats, which constantly occupy the dominant positions in the Common Weakness Enumeration. Cyber criminals and APT groups leverage the vulnerabilities exposed on the borders of an enterprise network and construct corresponding weaponized exploits for penetration and further malicious activities.

In response to the severe security posture, various methods have been proposed to distinguish malicious HTTP requests from normal traffic, which can be categorized into knowledge-driven [1,2] and data-driven [3,4,5,6,7,8,9] detection methods. Although current methods have shown excellent performance in detecting suspicious HTTP requests, which has been extensively elaborated by previous studies, they cannot distinguish the real severe incidents from massive low-intensity attack attempts, such as brute-force and probing attacks.

According to a study report conducted by Trend Micro [10], nearly three-quarters of security operations teams are severely plagued by alert overload, and more than 51% of alerts are actually false positives. Similarly, as a survey conducted by the Cloud Security Alliance illustrated, only about 23.2% of threat alerts were real, meaning that 76.8% were false positives [11]. Consequently, as stated in FireEye’s survey [12], only an average of 4% of alerts are investigated in a timely and appropriate manner each week, due to the impact of massive fake alerts. Alert fatigue excessively consumes the limited computing resources and manpower of security operations, maintenance, and delays responses, which causes alert burnout and eventually desensitization [13], resulting in critical alerts being buried in significant numbers of invalid alerts, such as the notorious Target incident in 2013 [14].

Combating alert fatigue can be described as a “find a needle in haystack” problem, i.e., to determine the potentially real threats from massive numbers of invalid alerts. One prevalent solution is to apply data provenance analysis [15,16] on suspicious HTTP requests. Provenance analysis provides an automated and intelligent solution to perform causal analysis and context investigation on suspicious HTTP requests to scrutinize reported security incidents by integrating heterogeneous log data from various sources [17]. Although provenance analysis has shown promising performance in incident assessment, relieving the pressure of the analyst and mitigating alert fatigue to some extent, it is still a time-consuming process with prohibitively expensive overhead due to the huge volumes of pending alerts in practical application.

In contrast to previous work, which verify the captured alerts by fine-grain incident investigation, we focus on improving the capacity of classifiers and reducing the generation of false alerts in the detection stage to fundamentally relieve the pressure of further forensics or investigation. Existing detection solutions rely extensively on the recognition of attack vectors while neglecting the contextual scenario and feasibility analysis of suspicious HTTP requests, resulting in a lack of cognition on false-alert identification. Worse still, the overwhelming volume of intricate and ever-changing background traffic exacerbates the difficulty of distinguishing the “real” threats from those false alerts, causing floods of false alerts in practical deployment. To overcome the stated deficiencies, we formalize the expertise of static false-alerts scrutinizing as attack feasibility and integrate it into the detection stage, differently from Imperva Attack Analytics [18], which attempts to insert an extra module to reduce WAF false positives based on a supervised machine-learning model. Concretely, we make maximum use of the static syntax features and scenario-related information implicit in HTTP requests to tentatively measure the attack feasibility, thus enhancing the cognitive ability of the detectors.

In this paper, we are committed to revisiting the alert-fatigue problem from the detection perspective and alleviating the alert-fatigue phenomenon through enhancing the capability of front-end detectors. Our work assumes a scenario where detectors are faced with a large volume of sophisticated HTTP requests containing a massive number of suspicious attempts. These suspicious attempts usually incur considerable false alerts which are composed of unharmful scannings and tentative attacks with implausible conformation [11,12]. To cope with the alert-fatigue problem under such circumstances, we should improve the detection framework both in feature engineering and model design. For feature engineering, the literature [19] employs the DOC [20] method on traffic feature extraction. The literature [21] provides comprehensive analysis on several feature-extraction methods. The literature [22] introduces a promising embedding method on IP and port addresses. For model design, the literature [23] presents an effective contrastive-learning architecture for intrusion detection. In this paper, we propose a novel malicious HTTP-requests detection framework, incorporating the prediction of attack feasibility into the final decision, to reduce the generation of such false alerts. Inspired by aspect-based sentiment analysis [24,25] and circulant fusion mechanism [26], we disassemble the HTTP requests and conduct aspect-level alignment to maximize the use of static syntax features and scenario-related characteristics. Consequently, our framework consists of a request reorganization module and a dual-channel attention-based circulant convolution neural network (DualAC${}_2$NN) model. Compared to existing studies, the contributions of our research are highlighted as follows:

• Firstly, we innovatively introduce the concept of attack feasibility to tentatively predict the validness of a suspicious inbound HTTP request under static audits. We elaborate the principle and rationale of attack feasibility based on empirical knowledge and concrete examples. Additionally, we present a fundamental scheme to estimate the attack feasibility and integrate it into the detection stage.
• Secondly, we propose a fast request-reorganization algorithm, to extract composition properties and semantic attributes in the requests. After reorganization, we obtain a pair-form representation containing interface-related and payload-related strings to better utilize the intrinsic mechanism of attack implementation and to facilitate the alignment of the target interface and conveyed payload for further neural computations.
• Thirdly, we carry out a dual-channel attention-based circulant convolution neural network (DualAC${}_2$NN) for further neural computations and adaption to the proposed pair representation of inbound requests. We adopt an attention mechanism and convolution neural network architecture to reduce noise from irrelevant background strings. Furthermore, we incorporate payload maliciousness, resource interface sensitivity, and their bipartite compatibility through circulant fusion computation on dual-channel vectors, seek to exploit more information and obtain more reliable decisions than previous payload-centric methods.
• Finally, we evaluate the proposed methodology on a real-world HTTP traffic dataset collected from an enterprise network edge, which is used to measure the captivity of classifiers to combat alert fatigue. Comparative experiments showed that the proposed method outperforms other state-of-the-art methods, especially in the false-positive rate.

The rest of this paper is organized as follows. Section 2 elaborates the problem and motivation examples; Section 3 demonstrates the concept of attack feasibility and theoretical foundations; Section 4 illustrates the overall process of the proposed approach, especially the fast request-reorganization algorithm and the DualAC${}_2$NN model; Section 5 shows the experiments on the real-world dataset; and, finally, Section 6 concludes the paper and further discusses the future work.

2. Problem Statement

2.1. HTTP Request Structure

From the perspective of composition [27], an HTTP request message can be divided into three parts, as in Figure 1: start line, header fields, and request body, if needed. The start line declares the request method and path component that identifies the target resource on the server (uniform resource identifier, URI). Message headers provide information to the recipient about the message, the sender, and how the sender would like to communicate with the recipient. In addition, as the actual content of the message technically, the request body conveys the entity or parameter to the target resource interfaces of the recipient to accomplish some expected jobs.

Different from benign HTTP requests, as shown in Figure 2, during a malicious HTTP request, particularly in injection attacks, the attacker replaces the legitimate parameter with malicious code and then makes the victim host execute it. The attacker exploits the inappropriate request processing logic of certain vulnerable application components to make the request incorrectly interpreted, causing the malicious payload to be injected into the sensitive interfaces. This means that from the view of detection, a feasible HTTP-based attack should have a reasonable composition and conformation, implying both a path to a potentially vulnerable interface and sufficient malicious codes in the payload.

However, current learning-based methods tend to model the entire request message as streaming data [3,4,5,6,7,8,9,28,29,30,31,32,33,34], causing the individual presence of a sensitive path or malicious payload to be regarded as the prevailing decision-making factor. As existing methods neglect the implicit processing syntax and scenario-related characteristics, they cannot estimate the attack feasibility when conducting detection on captured malicious requests, which might incur further massive numbers of false alerts, especially during real-world deployment.

2.2. Motivative Examples of False Alerts

In this study, we focus on reducing false alerts that security researchers can eliminate from the perspective of static audits. Three typical examples of real-world false alerts are shown in Figure 3, Figure 4 and Figure 5 with deprivatization, respectively.

False-alert example 1 stems from a lack of cognition of the contextual scenario, or the path sensitivity, in other words. For many suspicious behaviors, such as remote command execution, current detectors often find it difficult to distinguish a legitimate remote control from the real command injection attacks, as shown in Figure 3.

False-alert example 2 originates from the over-matching of vulnerable paths but a neglect of the existence of payload maliciousness. Such overfittings mean normal accesses are falsely reported due to sharing a same URI as in the CVE-2020-9054 exploits in Figure 4. For the same reason, unharmful reconnaissance and scanning are also reported to the SOC all the time, which always occupy a prevailing portion of alerts. The vague boundary delineation to determine the maliciousness of requests increases the difficulty of real-world detection.

False-alert example 3 is caused by the incompatibility of the accessed interface and malicious payload. This type of attack is often produced by brute-force attacks or fuzzing attacks from automatic suites, as illustrated in Figure 5.

Consequently, in a real-world network environment, suspicious HTTP requests contain numerous blind attacks, invalid brute-force and fuzzing attacks, unharmful scan or reconnaissance attempts, legitimate remote controls, and normal access to vulnerable paths upon some web services might be incorrectly alarmed, which are aggregated as the main causes of alert fatigue.

3. Attack Feasibility Estimation

In this study, we propose an attack feasibility-wise detection strategy to mitigate such false alerts. The feasibility of an HTTP-based attack depends on the composition rationality of the request itself and whether the target host is vulnerable and unprotected. We focus on estimating the attack feasibility statically from detection perspectives, reducing the complexity of subsequent provenance analysis at less computational cost. Based on the discussions of practical examples mentioned in the previous section, attack feasibility is closely related to the logical semantics and scenario characteristics implicit in the hierarchically structured request, as mentioned in the literature [5]. Hence, attack feasibility in this study can be described as Definition 1 from the scope of static audits.

Definition 1 

(Attack feasibility). Attack feasibility is illustrated as the underlying composition and conformation rationality of request constituents that accords with certain feasible attack paradigms from the perspective of static analysis.

The hierarchical conformation reveals the intrinsic logic about how external malicious codes are delivered to a certain vulnerable server-side function along with a specified path or interface. This means that by examining the request messages, we might obtain some valuable clues indicating the subsequent processing logic, which can be used as significant auxiliary features.

Concretely, a feasible attack is basically supposed to possess access to a vulnerable resource and the corresponding compatible malicious payload. We can extract several refactored paths that specify some certain application component resources and the corresponding payloads from a request message. Then, the attack feasibility can be estimated based on the analysis of extracted refactored paths, payloads, and their bipartite compatibility. Therefore, we design an attack feasibility-estimation strategy based on a triadic measurement: the maliciousness of the payload, the sensitivity of the injected interface and their bipartite compatibility.

Definition 2 

(Payload maliciousness). Payload maliciousness is defined as an assessment metric to measure the sender’s intention and the underlying severity of the desired consequences.

The request payload refers to the parameter delivered to a certain front-end or back-end function of the target application. In the POST request message, the request payload can be extracted from a request body according to the specification of content type and some delimiters. In the GET request message, the request payload can be obtained from the value segment of the URI. An example of a malicious payload is shown in Figure 2, marked in orange. The malicious payloads share similar lexical and semantic features of the resembled intentions of attackers. As illustrated in Definition 1, through manual labeling, the payload maliciousness can be statistically concluded based on a learning-based algorithm [35,36]. For example, within a remote command execution attack, the frequent malicious payload organized as “wget IP:PORT/FILE; chmod + x MALFILE;./FILE” is identified as a severely dangerous behavior. Conversely, the payload which is organized as ‘echo hello’ is regarded a tentative behavior with less threat.

Definition 3 

(Interface sensitivity). Interface sensitivity is defined as a quantitative identifier to evaluate whether the accessed resource is vulnerable or prone to be vulnerable.

The interface in our work refers to the path-like strings in the request body implying the accessed resource. In a POST request message, the interface is composed of a URI and part of a path-like string in a message payload according to the content type. Whereas in GET request, the interface is just the URL (uniform resource locators) and query part.

The similarity of the path is embodied in the word formation in request strings, such as abbreviations and morphology, which reflect their intrinsic functions or code logic to a certain extent, in turn potentially reflecting similar security problems. Through a lot of work on analyzing existing web vulnerabilities, the morphological similarities of vulnerable paths can be found widely.

One of the primary causes is the over-reused code in the developing phase, especially in IoT devices, due to the convergence of functional requirements and the wide adoption of the same third-party libraries. Such a series of vulnerabilities was exposed on the SOAP-based HNAP protocol [37], known as the OpenWrt Luci command injection vulnerability and thinkphp RCE vulnerability, triggered by the controller built by MVC.

Secondly, following development conventions, codes with similar functional designs share similar naming schemes on paths; for example, the strings “/cgi-bin/*.cgi" and “/luci/" are often involved with unatuh RCE vulnerabilities. For example, exploits of CVE-2020-14472 [38] and CVE-2020-8515 [39] share the same interface, known as “/cgi-bin/mainfunction.cgi".

In addition, there are imperfect or incomplete patches from vendors, also resulting in the recurrence of vulnerabilities in the same path, such as S2-013 and S2-014, S2-005 and S2-003 [40], etc.

Such strings can be extracted from original requests to build the refactored resource interface paths, which can be utilized as an important indicator to weigh the sensibility of request behaviors and expose the latent service scenarios.

Definition 4 

(Compatibility). Compatibility refers to a variable weighing of the possibility that a certain injected interface and suspicious payload can be composed for a feasible attack.

In practice, we find that payload maliciousness and interface sensitivity cannot solely determine whether a suspicious request can lead to a feasible attack or not, as false-alert example 3 in Figure 5. Hence, we propose the concept of compatibility to predict the conformation rationality of the given interface and payload, as stated in Definition 4. After being trained on massive samples, the detector is promising to predict which attacks are feasible for a specific interface [41,42].

Overall, when estimating attack feasibility, our study mainly concerns the three aspects mentioned above. Hence, we aggregate payload maliciousness, interface sensitivity, and their bipartite compatibility to obtain a comprehensive assessment. We can construct a specified network architecture and an appropriate representation to exploit the aforementioned three properties. Through a composite analysis, we integrate part of the intuitive and empirical intelligence from static audits into the detection stage, which is promising to significantly enhance the attack feasibility-wise capacity of detectors and promisingly lower the false alerts.

4. Detection Framework

The basic assumption of our work is that we can achieve massive distinctive HTTP requests in plaintext form. In addition, our work is oriented to the real-world defensive scenario.

4.1. Overview

An overview of proposed framework is demonstrated in Figure 6. As shown, the whole pipeline contains two core phases: a data preprocessing module and a detection module. We transform every captured HTTP request into a tokenized $<S_{interface},S_{payload}>$ pair through request reorganization, generalization, and tokenization operations.

Then, we feed the pair-form inputs into a dual-channel neural detection model, namely, DualAC${}_2$NN, and gather the decision result to determine whether to generate alerts or not.

4.2. Data Preprocessing

In order to provide an appropriate representation for further neural computation with attack feasibility estimation, some preprocessing operations are conducted including request reorganization, generalization, and tokenization on a raw HTTP request input in the preprocessing phase.

4.2.1. Request Reorganization

After twice decoding the URL, we adopt a fast request-reorganization algorithm working on incoming HTTP requests. The purpose of request reorganization is to facilitate the aspect alignment of interface-related tokens and payload-related tokens for maximum utility of the logical semantics and scenario characteristics implicit in the structured conformation.

According to the specification of the HTTP RPC2616 document [27], an external parameter or payload can be transmitted through URL or a request body. The URL string contains semantic segments such as domain name, path name, and file name, which can be roughly expressed as http://hostname:hstport/p/a/t/h?query1=string1&query2=string2 (accessed on 11 May 2022). The parts of $/p/a/t/h$ and $query$ indicate the interface to submit payloads, and $string1$ and $string2$ are the externally injected payloads. Therefore, the symbol = and & can be used to separate the interface-related segments and payload-related segments. Concretely speaking, = acts as an assignment identifier to declare the corresponding payload-related segments with aforementioned paths just as the URL in Figure 7a. In addition, the & acts as a delimiter to separate the pairs of interface-related segments such as $/cgi-bin/cgi\_system?cmd$ from the corresponding payload-related segments such as $saveconfig$.

For POST requests, a request body can also carry some parameter-transmitting strings. Although there exist diverse composition paradigms on request bodies, divided by the format and parsing logic, our request-reorganization algorithm can still retain effectiveness just by adopting corresponding indicators according to the specification of $Content-Type$.

For request body with a streaming-like structure with the $Content-Type$ of $application/$$form-data$, such as the example in Figure 7a, we focus on the assignment symbols = and juxtaposition symbols &. As shown in the left half of Figure 7a, the segments are annotated. Generally, the strings behind the assignment symbols and the front of juxtaposition symbols are payload-related segments, like the strings enclosed by orange dashed curve. In addition, the strings lie behind the juxtaposition symbol and the front of the assignment symbols are interface-related segments, like the strings enclosed by blue solid curve.

For a request body with a nested structure with the $Content-Type$ of $application/text/xml$ or $application/json$, like the example in Figure 7b, we mainly consider the delimiters as < and >. As shown in the left half of Figure 7a, the segments are annotated. The strings located between < and > are regarded as interface-related segments, and the strings locate between > and < are regarded as payload-related segments.

Then, we can concatenate all the interface-realetd and payload-related segments, respectively, and obtain the interface sequence and payload sequence. Consequently, the raw streaming request strings are reorganized as the sequence pairs as shown in right half of Figure 7a,b. Here, the strings in blue colored represent the interface sequence, and the strings in orange represent the payload sequence.

Given the computational complexity and time efficiency, we design a fast request-reorganization algorithm as shown in Algorithm 1 for a trade-off on granularity and efficiency. We use head indicators and tail indicators to simply depict the delimiters to distinguish the interface-related segments and payload-related segments. For instance, we adopt = and > as head indicators and & and < as tail indicators. As shown in Algorithm 1, the time complexity of the proposed fast request algorithm is $O\left(n\right)$. Compared to subsequent processing such as REGEX-based generalization and tokenization, the extra cost from request reorganization is acceptable, which means that our algorithm is lightweight enough and can be applied in real-world scenarios.

Through request reorganization, we construct an $<St{r}_{interface},St{r}_{payload}>$ pair for characterizing interface sensitivity and payload maliciousness, respectively. Where $St{r}_{interface}$ and $St{r}_{payload}$ of $<St{r}_{interface},St{r}_{payload}>$ is composed of interface-related segments and payload-related segments. Further, we can compute the compatibility through the aspect alignment of interface sensitivity and payload maliciousness. Although it cannot completely reflect the processing logic of the target program, critical clues involving the payload-injecting logic are preserved to the maximum extent during the transformation.

Algorithm 1: Fast request-reorganization algorithm

4.2.2. Generalization and Tokenization

Generalization is aimed at eliminating isolated words, using specific indicators to substitute the attack-agnostic to avoid misidentification and interference from background strings. Compared with natural language, HTTP requests often contain website links, IP addresses, numeric strings, hash strings, encoded strings or some meaningless words, etc. To eliminate extraneous interference from those confusing characters, we utilize regular expressions to match those characters and transform them into proprietary words according to original attributes. For example, by using the generalization rules shown in

Table 1. Generalization rules.

Regex Expressions	Substitution Strings
r‘(http|https|ftp)://[a-zA-Z0-9+$\dot{]}$/’	patternURL
r‘(([01]{0,1}\d{0,1}\d|2[0-4]\d|25[0-5])\.){3}([01]{0,1}\d{0,1}\d|2[0-4] \d|25[0-5])’	patternIP
r‘[a-f0-9]{16}’	patternHASH
r‘ˆ([A-Za-z0-9\+\-+]{4}){3,}([A-Za-z0-9\+\-+]{4}|[A-Za-z0-9\+\-+]{3}=|[A-Za-z 0-9\+\-+]{2}==)$’	patternBASE64
r‘[0-9][0-9]{5,}’	patternLongNUM

, we can figure out such attack-agnostic strings and replace them with the corresponding specified words.

Notice that the word-level tokenizer is troubled by out-of-vocabulary words due to its coarse granularity. Meanwhile, the char-level tokenizer makes the data more sparse and difficult to learn long-distance dependencies. In our framework, we adopt a subword-level tokenizer based on byte pair encoding (BPE) [43]. BPE is a simple form of data-compression algorithm in which the most common pair of consecutive bytes of data is replaced with a byte that does not occur in that data. BPE brings the perfect balance between character- and word-level hybrid representations, which makes it capable of managing large corpora. By using BPE, we can mitigate the problems faced by word-based tokenization (large vocabulary size, out-of-vocabulary tokens, and different meanings of very similar words) and character-based tokenization (long sequences and less meaningful individual tokens).

After generalization and tokenization, $<St{r}_{interface},St{r}_{payload}>$ can be converted into $<S_{interface},S_{payload}>$, where $S_{interface}$ and $S_{payload}$ are composed of subwords, as $S_{interface}=[S{w}_{i,0},S{w}_{i,1},S{w}_{i,2},S{w}_{i,3},\cdots ,S{w}_{i,L-1}]$, $S_{payload}=[S{w}_{p,0},S{w}_{p,1},S{w}_{p,2},S{w}_{p,3},\cdots ,S{w}_{p,L-1}]$.

4.3. Model Design

In this section, we demonstrate our proposed DualAC${}_2$NN model adaptive to the pair-form $<S_{interface},S_{payload}>$ inputs as shown in Figure 8. We measure the payload maliciousness and interface sensitivity based on the dual-channel quantification, respectively. Then we compute the bipartite compatibility based on the ciculant matrix multiply operations. Eventually, we incorporate the threefold characteristics to integrate the attack feasibility estimation into detection decision based on the concatenation fusion for further neural computation. In addition, the attention mechanism is adopted to enhance the significant regions of the incoming request and reduce the influence from noise bytes.

4.3.1. Embedding

In order to construct an appropriate input for the neural network model, we must map the tokenized sequence into the numerical vector space. However, when dealing with network traffic data, we are often faced with a huge number of words, resulting in a large and sparse one-hot encoding vector, which significantly affects the model performance. Therefore, an embedding layer is required to convert sparse$\left|V\right|$-dimension one-hot encoding words into dense k-dimension vectors, where $\left|V\right|$ represents the volume of the vocabulary corpus and k stands for the fixed size of embedded vectors.

We build a constant embedding matrix based on the GloVe(Global Vector) [44] algorithm used as a shared embedding layer for semantic uniformity of the two parallel channels in our neural network. After embedding, tokens with similar semantics will be assigned in vectors with a close distance in the vector space. We assign every subword $S{w}_i$ in sequence with a unique index $idx$, and then look up the corresponding vectored representation $V_{idx}$ in the GloVe dictionary. Consequently, we can obtain vectorized $<V_{interface},V_{payload}>$ from $<S_{interface},S_{payload}>$.

In this study, the vector size is assigned as 128. The sizes of interface sentence and payload sentence are assigned to 128. The excess part of the input sequence is truncated and the insufficient part is filled with zero.

4.3.2. Attention Module

As Figure 8 shows, an attention layer is introduced between the input layer and the convolution layer inspired by [45]. Concretely, the attention layer is to produce a context vector for each word. The context vector is concatenated with the original word vector as a new representation of the input vector is, fed to the following dual-channel convolution layer, respectively. The core idea of the attention mechanism is to facilitate the model to concentrate on some significant regions of an incoming sentences based on the attention weights. Attention mechanism determines to which regions more attention should be paid than other regions in the sentence for the classification task. In our study, the attention mechanism is an additional MLP being jointly trained with all other components of DualAC${}_2$NN. The lilac-filled circle of the attention module or CNN module in Figure 8 represents the context vector $g_i$ as scored words combined with input words $\mathbf{w}$ in a weighted sum:

$${\mathbf{g}}_i=\sum _{j\ne i}{\alpha }_{i,j}·{\mathbf{w}}_j$$

(1)

where ${\alpha }_{i,j}$ are attention weights and satisfy that ${\alpha }_{i,j}⩾0$ and ${\sum }_j{\alpha }_{i,j}=1$ through softmax normalization. The following equations can be used to describe the attention mechanism:

$${\alpha }_{i,j}=\frac{exp\left(score\left({\mathbf{w}}_i,{\mathbf{w}}_j\right)\right)}{{\sum }_{j^{\prime }}exp\left(score\left({\mathbf{w}}_i,{\mathbf{w}}_{j^{\prime }}\right)\right)}$$

(2)

$$score\left({\mathbf{w}}_i,{\mathbf{w}}_j\right)=v_a^{\top }tanh\left(W_a\left[{\mathbf{w}}_i\oplus {\mathbf{w}}_j\right]\right)$$

(3)

where $W_a$ is provided by the MLP mentioned above. Then, we concat the word vector ${\mathbf{w}}_i$ with its context vector ${\mathbf{w}}_i$ to obtain the extended vector ${\mathbf{w}}_i^{\prime }$ respectively:

$${\mathbf{w}}_i^{\prime }={\mathbf{w}}_i\oplus {\mathbf{g}}_i$$

(4)

After the computations stated in the above equations, we can obtain the composed form $V_{interface}^{\prime }=V_{interface}\oplus Attention\left(V_{interface}\right)$ and $V_{payload}^{\prime }=V_{payload}\oplus Attention\left(V_{payload}\right)$. Then, we feed them into the following dual-channel convolution neural network module, respectively, as Figure 8 shows.

4.3.3. Dual-Channel Convolution Neural Network Module

Next, we build a dual-channel convolution neural network architecture for more accurate representation for the recognition of malicious HTTP requests. The CNN model automatically extracts data features through sliding windows and convolution operations, making full use of and mining local regional features present in data streams [29,46]. During training, by discovering distinct combinational patterns, activate the corresponding neurons and increase the importance of these patterns one by one. In this study, parallel neural networks are coordinated to learn complementary features, and, thus, a symmetry architecture is constructed. After the words from a single channel are fed into the neural network, we adopt convolution operations with multiple filters varying in the window sizes, and each convolution layer is followed by a maxpooling operation, as in Equation (5). Then, we can obtain two immediate vectors from the followed fully connection network as in Equation (6), which quantitatively demonstrates the interface sensitivity (${\nu }_{immediate,interface}$) and payload maliciousness (${\nu }_{immediate,payload}$).

$$\begin{array}{c}\hfill {\nu }_i=Pooling\left(conv1D(W_{{\theta }_i},V^{\prime },‘‘valid")\right)\end{array}$$

(5)

$${\nu }_{immediate}=F{C}_{\theta }\left(Concat\left({\left\{{\nu }_i\right\}}_{i=0}^{n-1}\right)\right)$$

(6)

In our architecture, we adopt three filters with different window sizes, which means that n is assigned as three.

4.3.4. Circulant Fusion Module

In this study, we introduce a circulant fusion module as mentioned in [26] to estimate the implicit compatibility through exploiting interactions among elements of the interface sensitivity immediate vector and the payload maliciousness immediate vector, as sketched in Figure 9.

Firstly, we expand and reshape the immediate vectors into circulant matrixs ($Cir{M}_{interface}$, $Cir{M}_{payload}$), respectively, as in Equation (7). Then, we compute the inner product between the interface sensitivity immediate vector with the payload maliciousness circulant matrix, and the inner product between payload maliciousness immediate vector with the interface sensitivity circulant matrx, and we can obtain two cross-fused vectors $C_{ip}$ and $C_{pi}$ as in Equation (8). Compared to commonly used fusion methods mainly including element-wise product, element-wise sum, or simply concatenation, circulant fusion is capable of exploring nearly all possible interactions between vectors of different modalities as each row of a matrix shifts one element. Meanwhile, based on the computation of all possible interactions, we can query all the possible aspect alignments of interface sensitivity and payload maliciousness, thus obtaining a comprehensive compatibility estimation.

After obtaining the joint representation ${\nu }_{\mathbf{joint}}$ of these two cross-fused vectors and two immediate vectors as in Equation (9), we feed it into the final fully connected layers. Through batch normalization and softmax computation, we can obtain the output determining the predicting label of the current request, Equation (10). Considering the composition of joint vectors, our method covers all threefold characteristics and integrates the attack feasibility estimation into the final determination.

$$\begin{array}{cc}\hfill & Cir{M}_{interface}=circ\left({\nu }_{immediate,interface}\right)\hfill \\ \hfill & Cir{M}_{payload}=circ\left({\nu }_{immediate,payload}\right)\hfill \end{array}$$

(7)

$$\begin{array}{cc}\hfill & C_{ip}=Cir{M}_{interface}\odot {\nu }_{immediate,payload}\hfill \\ \hfill & C_{pi}=Cir{M}_{payload}\odot {\nu }_{immediate,interface}\hfill \end{array}$$

(8)

$$\begin{array}{c}\hfill {°}_{\mathbf{joint}}={\nu }_{immediate,interface}\oplus C_{ip}\\ \hfill \oplus C_{ip}\oplus {\nu }_{immediate,payload}\end{array}$$

(9)

$$\begin{array}{c}\hfill \mathbf{Y}=Softmax\left(BatchNorm\left(F{C}_{\theta }\left({\nu }_{joint}\right)\right)\right)\end{array}$$

(10)

5. Evaluation

In order to evaluate the efficacy of our proposed framework, we conducted experiments on a real-world dataset.

• Firstly, we conducted comparative experiments to compare the detection performance of DualAC${}_2$NN with a rule-based commercial web application firewall (RWAF) to verify our conjecture that through supervised-learning methods, detectors can develop the intelligence to identify threatening attacks, see Section 5.3.
• Secondly, we conducted comparative experiments to compare our model with several state-of-the-art models to evaluate the capability of our model to reduce false alerts, see Section 5.3.
• Thirdly, we measured time overhead and appraised the practicability of proposed methods on real-world application, especially the efficiency of threat response, see Section 5.4.
• Finally, ablation experiments were conducted to further demonstrate the plausibility of our model design with every component, see Section 5.5.

5.1. Dataset Construction

Most of existing research was performed on the dataset generated from a simulated or ideal environment with very limited types of attacks. In particular, these datasets rarely contain real-world attacks, network scanning samples, and brute-force attack attempts, which are not applicable to evaluating our work.(The dataset will be available from the author upon request soon after publication.) Therefore, the dataset used in our experiment is derived from a traffic monitor system deployed on the edge of an enterprise network. With days of collection, a tremendous number of raw HTTP requests were stored, involving over 54 types of web service suites and 28 different network devices, as listed in

Table 2. Involved applications and devices in our dataset.

Type	Product
WEB service	AlienVault ossim, Apache Kylin, Apache Log4j, Apache OFBiz, Apache Shiro, Apache Solr, Apache Spark, Apache Struts, Apache Tomcat, Atlassian Confluence Server, Atlassian JIRA, Citrix Gateway, Comtrend VR, DedeCMS, Discuz, Django, Drupal, Elasticsearch Groovy, EmpireCMS, Fortinet VPN, FreePBX Framework, GlassFish, goahead, Hadoop yarn, IIS, Intellian Aptus Web, JBoss, Jenkins, Joomla, MongoDB, Nagios, Nexus CMS, Nostromo Web, OpenDreamBox, Orcale weblogic, Phpmyadmin, Phpstudy, Phpweb, SCO Openserver, Spring CMS series, Stapler, Sunhillo SureLine, Supervisord, Symantec Web Gateway, Thinkadmin, ThinkCMF, ThinkCMS, ThinkPHP5, vBulletin, vTiger CRM PHP webapps, WebSphere, Wordpress, ZeroShell, Zimbra Collaboration Suite
Network device	AVTECH DVR, Belkin LINKSYS series, Cisco Linksys E-series, Dlink router DIR-series, DrayTek Vigor series, EirD1000, GPON network gateway, Grandstream GWN7610, Grandstream UCM6200, Huawei HG532, Lilin dvr, MikroTik RouterOS, NetGear R-series, NetGear WNR-series, NETIS WF2419, Netlink GPON GT3200-4F2P, Realtek rtl81xx SDK, Shenzhen TVT DVR, Tenda AC-series, TP-Link AC-series, TP-Link W-series, Ubquiti ubnt AirCam, Vacron NVR, Xiaomi router, ZTE ZXV10 H180L, Zyxel CloudCNM SecuManager, ZyXEL NAS, ZyXEL P660HN

. Then, we sorted the plausible attacks along with unharmful or normal messages, and established a dataset based on weeks of manual labeling.

In this study, our consideration of alert fatigue mainly concentrates on the following three cases as the aforementioned motivative examples. This is also the basis and starting point for us to establish and label the dataset. Hence, to evaluate the ability of diverse methods to combat false alerts, we divided the samples into two categories, according to their threat level from the view of static audits, which was different from previous work. In

Table 3. Composition of our dataset.

Label	Type	Number
Threatening	XSS injection	603,900
	SQL injection	617,000
	RCE attack	627,040
	Sum	1,847,940
Nonthreatening	Normal	1,500,000
	Implausible attempt	220,570
	Unharmful scanning	304,000
	Sum	2,024,570

, we summarize the statistical details of our dataset.

Among those, the threatening requests contain statically valid attacks of SQL injections (T1), XSS injections (T2), and RCE attacks (T3), covering over 314 different vulnerabilities in listed applications.

The nonthreatening requests consist of numerous normal HTTP requests (N1), quite a proportion of implausible attempts (N2) and unharmful scannings (N3) which are prone to be falsely alerted just like the aforementioned examples in Section 2.2. During experiments, the dataset is divided into training and test sets according to the 7: 3 ratio, with the aim of ensuring that the training set and test set retain the same proportion of various types of samples.

5.2. Experiment Configuration

All experiments were performed under the same experiment configuration, and the details are listed in

Table 4. System configuration of the experimental setup.

Component	Description
Central processing unit	Intel Xeon E5-2678 v3
Random access memory	DDR4 128 GB
Graphics processing unit	RTX 3090

.

5.3. Performance Comparison

To evaluate the performance of the detection framework proposed in this paper, comparative experiments were conducted on the aforementioned dataset.

During our experiments, we regard the threatening as positive and nonthreatening as negative. Hence, the TP, TN, FP, and FN are abbreviations for true positive, true negative, false positive, and false negative, respectively, and the performance metrics can be obtained according to the corresponding equations as follows:

$$Accuracy(Acc.)=\frac{TP+TN}{TP+TN+FP+FN}$$

(11)

$$Precision(Prec.)=\frac{TP}{TP+FP}$$

(12)

$$DetectionRate\left(DR\right)=Recall(Rec.)=\frac{TP}{TP+FN}$$

(13)

$$F1-score(F1.)=\frac{2Precision\times Recall}{Precision+Recall}$$

(14)

$$Falsepositiverate\left(FPR\right)=\frac{FP}{TN+FP}$$

(15)

The parameter manifest of the proposed DualAC${}_2$NN model are summarized in

Table 5. Parameter manifest of proposed DualAC${}_2$NN model.

Layers	Parameters	Activation
Attention *	default additive	\
	attention
Conv1d *	filter = [128,128,128],	ReLu
	kernel = [3,4,5],
	padding = ‘valid’,
	strides = 1
Maxpooling1d *	pool_size = 4,	ReLu
	padding = ‘valid’,
	strides = 1
Concatenate *	axis = −1	\
Flatten *	\	\
Dense *	units = 32	ReLu
Regularization *	dropout (0.5)	ReLu
Circluant	element-wise product	ReLu
	circlunat as in [26]
Concatenate	axis = −1	\
Dense	units = 2	Softmax

The layers * means that the parameters are applicable to both two channels.

. The same parameters are used in both the left and right channels. During training, we set the batch size as 64, and the maximum number of epoch at 50, along with a cross-entropy loss function and an Adam optimizer with a learning rate of 0.001.

The performance comparison between a rule-based commercial WAF (RWAF) with our method is shown in

Table 6. Performance comparison with a rule-based commercial WAF on test set.

Method	Predicted Label	Threatening			Nonthreatening			DR	FPR
		T1	T2	T3	N1	N2	N3
RWAF	Threatening	172,430	152,251	158,541	1266	66,171	91,200	0.8716	0.2612
	Nonthreatening	8740	32,849	29,571	448,734	0	0
DualAC2NN	Threatening	176,702	180,201	185,758	587	16,649	4378	0.9789	0.0356
	Nonthreatening	4468	4899	2354	449,413	49,522	86,822

. The experimental results demonstrate that our proposed DualAC${}_2$NN outperform both in DR and FPR. In addition, DualAC${}_2$NN can effectively reduce the false alarms derived from N1, N2 and N3, and lower the FPR by around 86.37% along with preserving a detection rate of 97.89%. This shows that RWAF is incapable of distinguishing implausible (N2) and unharmful scanning (N3) due to the limitation of rules, along with suffering from the overalarm of certain normal requests, as depicted in Figure 3, Figure 4 and Figure 5. Through supervised training, machine-learning models can develop the empirical intelligence to deduce the attack feasibility and largely mitigate the impact of implausible attempts and unharmful scannings on alarm determination. Meanwhile, due to the generalization ability of machine-learning methods, the detection capacity of threatening samples has also been improved. This means that DualAC${}_2$NN can discover more attacks that can evade existing rules. Overall, the experiment indicates that machine-learning-based methods can effectively learn the discrepancies between nonthreatening and threatening requests under our experiment configurations.

To evaluate the capacity of our proposed model to mine and exploit the attack feasibility-related characteristics and prove the effectiveness of our model design, we compared our model with several state-of-the-art static malicious request-detection models under the same experiment configuration. The baseline models are as follows:

• SVM: bag-of-words embedding support vector machine model with default parameters.
• Random Forest (RF): bag-of-words embedding random forest model with default parametesr.
• DeepHTTP [28]: two-channel BiLSTM followed by an attention layer, fed by a pair of a content vector and a structure vector with a trainable embedding layer.
• Enhanced TextCNN (ECNN) [29]: TextCNN with word2vec [47] embedding to extract features followed by an SVM layer instead of logistic regression layer for final output.
• Resnet [30]: modify Resnet to adapt to text data with word2vec embedding.

The results in

Table 7. Performance comparison with several existing methods on test set.

Method	Embedding	Channel	Acc.	Prec.	Rec.	F1.	FPR
SVM	TF-IDF	\	0.7972	0.8076	0.7549	0.7804	0.1641
RF	TF-IDF	\	0.8879	0.8648	0.9068	0.8853	0.1294
DeepHTTP	trainable linear layer	dual	0.8921	0.8819	0.8936	0.8877	0.1093
ECNN	Word2vec	single	0.9328	0.9043	0.9608	0.9317	0.0928
Resnet	Word2vec	single	0.9138	0.8926	0.9313	0.9116	0.1022
DualAC${}_2$NN	GloVe	dual	0.9713	0.9617	0.9789	0.9702	0.0356

show that DualAC${}_2$NN significantly outperforms other baseline models in accuracy, precision, recall and f1-score, while lowering the FPR by around 61.64% along with retaining a detection rate at 97.89%. Due to the reorganization and alignment processing, and a further circulant fusion mechanism, our model has stronger estimation and reasoning capabilities than other state-of-the-art models. Further, we plot the receiver operating characteristic (ROC) curve for comparison of true positive rate (TPR) vs. false positive rate (FPR) at different classification thresholds to better examine the performance of the proposed detection model. Figure 10 shows the ROC curves for the proposed DualAC${}_2$NN with five other baseline models. DualAC${}_2$NN shows superior performance to the other models under different conditions. All the above experimental results indicate that the proposed model is able to mine and exploit hidden characteristics in request data more effectively than other baseline models in our task. In addition, it demonstrates the effectiveness of our model design.

5.4. Time Overhead

Time overhead is also an important indicator besides the detection performance. Concretely, the more alerts for real threats we can handle at the same time, the more we can shorten the response time to a severe incident, thus reducing the possibility of alert fatigue.

To ensure the same computing environment, we compared our method with three other baseline models that work on GPU calculations. We recorded the training time and testing time of each model under the same configuration. Comparison of models based on computational time is shown in

Table 8. Time consumption on the training set and test set.

Method	Traning Time (s)	Test Time (s)
DeepHTTP	184,891	952
ECNN	63,277	352
Resnet	93,130	384
DualAC${}_2$NN	34,934	303

, with the best values emphasized in bold. Our DualAC${}_2$NN showed a significant advantage in both training and test time compared with other baselines. Intuitively, DeepHttp costs more time because of its serial LSTM cells. In addition, compared to other CNN-based model such as ECNN and Resnet, we divided the whole request into two pieces, then the input size of single channel decreases by half. Therefore, we can obtain smaller networks than the original CNN architecture for inputs with the same size, which consumes less time compared to other single-channel CNN models. The experiment shows that the average time for a single requests is controlled in $2.608\times {10}^{-4}$ seconds under the configuration of this paper, which is acceptable in practical applications.

5.5. Ablation Studies

In this section, we demonstrate the effectiveness of the architecture design of our framework. Our framework is composed of three critical components: request reorganization, attention module, circulant fusion module. We conducted three groups of comparative experiments to verify the effectiveness of those components:

• Proposed request reorganization versus random reorganization;
• Attention module versus no attention module;
• Circulant fusion module versus no circulant fusion.

We notate the method with only modifying the request reorganization into random reorganization as Setting 1, the model with only removing the attention layer as Setting 2, and the model with only removing the circulant fusion module as Setting 3. Furthermore, we observed the change in performance under different settings and recorded them in

Table 9. Performance comparison under different settings on the test set.

Setting	Acc.	Prec.	Rec.	F1.
Setting 1	0.9426	0.9208	0.9625	0.9412
Setting 2	0.9653	0.9578	0.9700	0.9638
Setting 3	0.9488	0.9233	0.9735	0.9477
DualAC${}_2$NN	0.9713	0.9617	0.9789	0.9702

.

The results prove that the request reorganization and circulant fusion play an important role in our method. We can come to a conclusion that the framework’s performance will be significantly enhanced by semantic alignment and the further cross fusion. In addition, the usage of an attention mechanism can also improve the performance of our framework to a certain extent.

6. Conclusions

This paper provides a novel idea to deal with the current alert-fatigue dilemma. In contrast to previous methods, we guide the machine-learning model to develop some empirical intelligence from security analysts to reduce the false alerts. To this aim, we introduce the concept of attack feasibility covering interface sensitivity, payload maliciousness, and their bipartite compatibility. Then, we propose a fast request-reorganization algorithm and dual-channel neural network architecture, namely, DualAC${}_2$NN for neural computation that integrates the attack feasibility estimation into the alert decision. Comprehensive experiments showed the effectiveness of our method, which can outperform a commercial rule-based WAF and some certain state-of-the-art methods in previous work. Meanwhile, our method achieves a lower time overhead compared to a baseline model, implying the practicability for combating real-world alert fatigue.

Overall, our study indicates that machine-learning-based methods are capable of grasping the empirical intelligence on alert investigation to a certain extent. It is a promising direction to combine attack feasibility estimation with malicious-request detection. This enables part of the job on alarm processing to be moved forward into the detection phase, in order to reduce the generation of false positives and alleviate alert fatigue at the source. However, there still exist some limitations in our work. Due to the restriction of the input layer, the HTTP requests might be long enough. Our work will not show advantages for short requests, especially when the length of interface-related strings and payload-related strings are extremely imbalanced. Especially, the input requests must be limited to those that are unencrypted and unobfuscated. It means that we can further improve the framework architecture for adaption to more scenarios. In addition, through appropriate model design, we can mine and exploit more underlying characteristics to obtain better performance in the future.