A Lightweight Cascade-Based Farmework for Real-Time Zero-Day Attack Detection

Abstract

Zero-day intrusion detection is still a difficult task because of the difference between high laboratory precision and real-time deployability under strict operational constraints. This paper proposes a lightweight two-stage cascade architecture that is specifically designed for CPU-only environments and strict zero-day evaluation. The proposed architecture only uses statistical and flow-level metadata attributes, which are independent of payload analysis, to ensure compatibility with encrypted traffic. The first stage of the proposed architecture is precision oriented to detect potentially malicious traffic with a low decision threshold, and the second stage is precision oriented to enhance classification and remove false positives. To avoid optimistic bias, a strict attack-type separation protocol is employed, where testing attack types are strictly prohibited from training. The proposed method is tested on three benchmark datasets: CSIC 2012 (HTTP level), UNSW-NB15 (intra-domain), and CSE-CIC-IDS2018 (cross-domain). The experimental results show the excellent intra-domain zero-day detection capability (up to 94.81% accuracy with 0.50% FPR), controllable performance degradation in the cross-domain setting (80.53% accuracy with near-zero FPR), and extremely low FP rates on all datasets. The system provides microsecond-level inference latency (0.002–0.006 ms), a throughput of up to 470,000 requests per second, and memory usage below 6.2 MB without GPU support. These results confirm the significance of architectural optimization and thorough evaluation in building efficient zero-day detection systems.

1. Introduction

Contemporary networked and web-based systems are characterized by highly dynamic and heterogeneous environments, where new attack methods are constantly being developed. Among the most difficult cybersecurity tasks in such environments is the detection of zero-day attacks [1]. Zero-day attacks are based on vulnerabilities that are not known to defenders at the time of attack deployment, which means that signature-based detection and known patterns of past attacks are not enough.

Recent breakthroughs in machine learning and deep learning have greatly improved the performance of intrusion detection in controlled laboratory experiments [2]. However, in practical implementation, there are other constraints. Deep learning-based intrusion detection systems (IDSs) are often characterized by the need for large amounts of labeled data, GPU computing, and large memory capacity. In addition, in practical implementations, high false positive rates (FPRs) are often reported, which can interfere with normal operations [3].

In enterprise networks, cloud infrastructure, edge computing, and web applications, detection systems must meet stringent real-time constraints, including low inference latency, high throughput, predictability, and low memory usage [4]. In such settings, small gains in detection accuracy may be of secondary concern compared to strong control over false positives and efficiency. Thus, there is an emerging need for lightweight and explainable IDS architectures that can also perform well on traditional CPU-based infrastructure [5].

Cascade-based IDS architectures have been identified as a promising approach in this regard [6]. By breaking down decision making into a series of steps, cascade models can achieve high recall and low false positives. Usually, a first stage is designed to be forgiving to prevent false negatives, and the rest of the stages use stronger separation to reduce false positives. Recent works suggest that such architectures can enhance robustness while encouraging efficiency.

Despite these improvements, a major drawback still exists in the evaluation methodology of most existing studies on zero-day attack detection. A major part of the existing literature uses random train–test splits, which implicitly assume that the distribution of attacks is stationary over time. However, such schemes can cause overly optimistic estimates of performance and do not represent real-world zero-day attack settings, where new categories of attacks emerge after system deployment [7]. In reality, a good IDS needs to generalize to strictly unseen attack types.

To fill this research gap, this paper presents a new two-stage cascade architecture, named Lightweight-TSC, for strict zero-day intrusion detection [8]. The proposed scheme combines efficient statistical and flow metadata features with two clearly distinguished objectives: recall-focused detection in Stage 1 and precision-focused refinement in Stage 2. Unlike payload-focused schemes, the proposed system is designed to operate solely on metadata-level features, which makes it fully compatible with encrypted traffic and resource-limited settings.

The application-driven motivation for this research is simple: existing zero-day detection methods are often optimized for the lab and rely on computationally expensive deep learning models that are hard to deploy in high-speed, large-scale settings [9]. There is a need for systems that can function well under strict evaluation settings while remaining efficient in real-time settings.

To achieve this goal, the following research challenges must be addressed systematically:

−

Constructing a lightweight feature representation that can efficiently process encrypted and high-speed traffic without deep packet inspection.

−

Developing a two-stage cascade model that clearly distinguishes between recall maximization and precision refinement to manage false positives under strict zero-day settings.

−

Following a strict zero-day evaluation protocol based on full attack-type separation to avoid optimistic bias.

−

Evaluating real-time deployability by measuring strict latency, throughput, and memory overheads.

Though cascade-based and lightweight IDS designs have been explored in the previous literature, the existing methods either (i) rely on conventional random splitting, (ii) do not make a strict separation of attack types during zero-day evaluation, (iii) emphasize accuracy without providing operational details, or (iv) demand GPU support for acceptable performance.

The novelty of this research work does not lie in proposing a new classifier but in using deployment-oriented design guidelines in a holistic framework:

• Strict separation of attack types between the training and testing phases for practical zero-day generalization performance evaluation.
• Proper separation of recall and precision with asymmetric thresholds (θ₁ and θ₂) for stable false positive control.
• Comprehensive operational evaluation, including inference delay, throughput, and memory usage during CPU-only execution.
• Cross-domain zero-day evaluation, emphasizing the constraints of semantic transfer with stable operational performance.
• Deployment-oriented optimization, prioritizing robustness and false positive reduction rather than seeking further improvement in maximum laboratory accuracy.

From the experimental evaluation carried out on the CSIC 2012 [10], UNSW-NB15 [11], and CSE-CIC-IDS2018 [12] datasets based on the cascade models for zero-day attacks, it is clear that properly designed cascade models with stringent zero-day evaluation criteria can ensure the deployability and efficiency of zero-day attacks without the need for large-scale deep learning systems.

2. Related Works

Recent studies on zero-day intrusion detection have revealed a substantial improvement in accuracy using deep learning, hybrid approaches, and ensemble techniques. However, despite the progress made, some practical and technical issues are still inadequately addressed.

A wide residual quantum dilated convolutional neural network, named WR-QDCNN, proposed by Sameera et al. [1], is tested on the UNSW-NB15 and CIC-IDS2018 datasets, showing better performance in zero-day detection. Although the network has high detection accuracy in benchmarking, it is computationally complex and deep, requiring intensive training resources without directly considering real-time latency and memory usage. Therefore, its applicability in CPU-only systems is unclear.

Subramanian et al. [3] and Zhou et al. [4] propose deep neural networks that are optimized for better accuracy and fewer false alarms for CSIC 2012 datasets. While they achieve better accuracy, their methods rely on deep learning, which not only raises the bar for inference complexity but also makes them less suitable for high-throughput systems. Furthermore, the evaluation methods are typically random splits of the training and testing sets, potentially overestimating the zero-day generalization capabilities.

Hybrid approaches like ZeroDefense [5] and multi-layered IDS designs [6] combine anomaly-based and signature-based detection. Although these methods enhance the robustness of detection, they may also add complexity to the design and may need signature updates or domain knowledge, thus hindering scalability.

Spatial specialization and scheduling techniques described in [7] enhance resilience while adding system-level overhead and do not directly tackle the zero-day evaluation constraint under attack-type separation. The phishing and URL detection frameworks like PhishingRTDS [8] target a particular attack type and cannot be generalized for multi-domain intrusion detection.

The accuracy rate of detection with a rate of 95–99% or higher has been referred to in comparative studies [13,14]. However, these rates are normally attained in a controlled lab environment with randomly mixed attack distributions. This is because, as claimed in [14], these approaches tend to make overly optimistic estimates of performance and do not reflect real-world scenarios of zero-day attacks where the type of attack is not encountered during training.

Guo [15] critically states that most machine learning-based IDSs have strong benchmarking performance but high false positive rates in practical scenarios, which are often above 1–5%, which is unacceptable for inline IDSs/WAF systems. This is still one of the biggest open issues in the literature.

The cascaded IDS architecture proposed by Ahamed & Karim in [6] is an example that shows how multi-stage detection can offer a 30–50% reduction in false positives over single-stage classifiers. However, the analysis is only conducted on known attack types and does not strictly separate attack types to reflect real zero-day attacks.

Deep learning-based web protection solutions employing LSTM, GRU, and autoencoders [16,17,18,19] improve the ability to abstract features but incur a large amount of computational complexity and are typically GPU accelerated to ensure reasonable throughput. They hardly ever measure latency or memory consumption in the microsecond order on the CPU-only platform.

The study [20] proposes a multiclass machine learning-based IDS to detect KRACK and Kr00k Wi-Fi attacks in IoT environments. Using advanced feature selection and a stacked ensemble model, it achieved 98% accuracy with a 2% false positive rate on the AWID3 dataset.

Flow feature analysis works and gradient boosting-based anomaly detection methods like [21,22] highlight interpretability and efficiency but are generally concerned with anomaly detection rather than structured cascade-based zero-day filtering. Moreover, cross-domain zero-day evaluation is not commonly performed.

Benchmark datasets like CSIC 2012 [10], UNSW-NB15 [11], and CSE-CIC-IDS2018 [12] offer various attack scenarios; however, most research papers assess models on mixed attack distributions instead of strict attack-type exclusion protocols.

Touré et al. [23] introduce flow-level anomaly modeling for zero-day attacks, focusing on behavioral abstraction. Although efficient for anomaly detection, the paper fails to address operational metrics like throughput and real-time latency.

Hence, the papers [13,14,15,16] indicate exemplary benchmarks in terms of detection efficacy, architectural ideas, and analytic understanding of zero-day intrusion detection. These papers indicate the capability of state-of-the-art machine learning approaches, in addition to pointing towards some of the most essential challenges in current approaches.

What makes our work different is as follows:

➢

CPU-only and low memory: full-featured zero-day detection without GPU acceleration; deployable on standard servers and edge devices.

➢

Operational efficiency: microsecond latency performance (0.002–0.006 ms), high throughput of up to 470k req/s, and memory usage below 6.2 MB.

➢

Strict zero-day evaluation: attack-type separation with HTTP-level, domain-level, and cross-domain communication.

➢

Balanced recall–precision design: two-stage cascade with separately optimized thresholds (θ₁ = 0.15; θ₂ = 0.85).

➢

Accuracy–operability trade-off: with 80.5–95.1% zero-day accuracy, we intentionally trade off a few percentage points of accuracy compared to the SOTA accuracy of the DL-based systems.

The slight degradation of 4–7% in peak accuracy over [14] is a deliberate compromise for deployability. Although [14] achieves 97–99% accuracy with computationally intensive deep learning-based approaches and more relaxed evaluation settings, our design focuses on strict separation of attack types, extremely low FPR, microsecond latency, high throughput, and low memory footprint on CPU-only platforms. Therefore, a slight loss of maximum accuracy is a worthwhile compromise for enhanced real-time viability, robustness, and zero-day resilience.

In conclusion, while the existing work is close to the limits of the maximum possible detection accuracy, our innovation lies in the proposed CASCADE structure that is lightweight, explainable, and deployable, which has good performance for the detection of ZEROS and is therefore highly apt for integration with an RTS and an HISWAF setup, respectively.

3. Dataset Description

In order to provide a full and realistic assessment of the proposed cascade-based zero-day intrusion detection system, experiments were carried out on three publicly available benchmark datasets, which represent different domains of heterogeneous traffic. The chosen datasets vary in terms of the protocol layer, attack variety, representation of features, and volume of traffic, thus allowing for assessment to be carried out at the HTTP level, within a domain, and across domains for zero-day scenarios.

Table 1 presents the essential features of the datasets used in this research.

Table 1. Summary of datasets used in the experiments.

Dataset	Traffic Level	Sample Size	Attack Diversity	Zero-Day Role
CSIC 2012	HTTP level	~36,000	Web attacks	HTTP zero-day
UNSW-NB15	Flow level	~175,000	9 attack types	Intra-domain
CSE-CIC-IDS2018	Flow level	>6,000,000	Multi-domain	Cross-domain

The utilization of multiple datasets is beneficial for two main reasons:

(i)

To verify the capability of generalization over different traffic environments;

(ii)

To evaluate the robustness of zero-day detection under different attack distributions.

3.1. CSIC 2012 Dataset

The CSIC 2012 HTTP dataset was created by the Information Security Institute of CSIC. The dataset includes synthetically generated but realistic HTTP traffic that includes both legitimate requests and web application attacks (SQL injection, XSS, path traversal, buffer overflow, and parameter tampering).

This dataset is commonly employed to test web application firewalls and HTTP-based anomaly detection solutions. Because it provides request-level structural and statistical information, it is appropriate for testing zero-day detection at the application layer.

In this research, the CSIC 2012 dataset is employed to test zero-day detection at the HTTP layer, with unseen web attack categories removed from the training data and employed only in the testing phase.

3.2. UNSW-NB15 Dataset

The UNSW-NB15 dataset is created using the IXIA PerfectStorm tool and contains real-world modern network traffic with a variety of attack types (Fuzzers, Analysis, Backdoors, DoS, Exploits, Generic, Reconnaissance, Shellcode, and Worms).

The dataset contains statistical, flow volume, temporal, and activity-related features extracted from network flows.

In this paper, the UNSW-NB15 dataset is employed for intra-domain zero-day testing. In particular:

-

Training data contains the chosen attack types (e.g., Fuzzers and DoS);

-

Testing data contains unseen but related attack types (e.g., Exploits and Worms).

3.3. CSE-CIC-IDS2018 Dataset

The CSE-CIC-IDS2018 dataset is a large-scale network intrusion detection dataset developed by the Canadian Institute for Cybersecurity. It includes modern attack (DoS, DDoS, brute force, botnet, infiltration, SQL injection, and so on) scenarios, which represent modern network threats.

The CSE-CIC-IDS2018 dataset is much larger and more diverse compared to the previous two datasets. It includes both volumetric attacks and application-layer attacks, which makes it suitable for cross-domain generalization evaluation.

In this work, the CSE-CIC-IDS2018 dataset is employed for both:

-

Intra-domain zero-day experiments;

-

Cross-domain zero-day evaluation, where volumetric attacks are employed for training and application-layer attacks (SQL injection, infiltration, and so on) are employed exclusively for testing.

This setup is a strict and realistic zero-day attack setting, where the attack behavior in the testing phase is significantly different from the attack behavior in the training phase.

3.4. Rationale for Multi-Dataset Evaluation

The choice of heterogeneous datasets remedies a common problem in the field of intrusion detection, where the performance of models is typically assessed on a single dataset with a predefined distribution of attacks.

The inclusion of the following types of traffic in the evaluation framework:

-

Application-layer HTTP traffic,

-

Medium-scale structured network flows, and

-

Large-scale heterogeneous multi-domain traffic,

ensures a realistic assessment of the performance of zero-day detection.

4. Proposed Methodology

To achieve the stated objectives, the proposed methodology is structured to systematically address four core research challenges:

• Development of a lightweight feature representation suitable for encrypted and high-speed traffic;
• Design and optimization of a two-stage cascade architecture balancing recall and precision;
• Implementation of a strict zero-day evaluation protocol to eliminate optimistic bias;
• Verification of real-time feasibility through measurable operational metrics.

The overall methodological framework is illustrated in Figure 1.

Figure 1. Suggested two-stage cascade structure for real-time detection of zero-day attacks.

The overall methodological framework, as shown in Figure 1, provides a systematic pipeline for real-time zero-day attack detection. The incoming network or HTTP traffic is first converted into a compact statistical and flow-level feature representation, followed by normalization to ensure systematic model behavior for heterogeneous datasets. The processed features are then fed into a two-stage cascade architecture: Stage 1 emphasizes high recall with a low decision threshold to identify potentially malicious samples, followed by Stage 2 with a stricter precision-focused threshold. Finally, the system provides the attack decision and operational metrics, allowing for both zero-day generalization capability evaluation and real-time performance assessment under strict attack-type separation constraints.

4.1. Lightweight Feature Representation

One of the basic requirements for contemporary intrusion detection systems is compatibility with encrypted traffic and high-throughput networks. Deep packet inspection is often impossible in the presence of encryption (for example, TLS 1.3) or privacy constraints [24,25]. In this respect, following recent research on zero-day detection [26], the proposed system will use only numerical features.

Two types of characteristics are used:

-

HTTP-level features, obtained from request metadata without message body inspection;

-

Flow-level features, which are packet/byte-level statistics aggregated over network flows.

This is beneficial because it is compatible with encrypted traffic. Moreover, it saves computational overhead. Therefore, it is suitable for real-time applications.

The categories of features that the proposed approach uses are given by Table 2 below.

Table 2. Categories of features used in the proposed technique.

Feature Category	Description
Structural	Request length, URL depth, parameter count
Statistical	Character ratios, entropy-based indicators
Flow Volume	Packet counts, byte volumes
Temporal	Flow duration, packets per second
Activity	Active/idle time statistics

Compact statistical flow representations retain the behavioral patterns and ensure computational efficiency at the same time [27]. This method helps in reducing the overhead of feature extraction and supports microsecond-level inference.

The design of the feature processing phase was adapted to the particular characteristics of the datasets employed in this research.

• For flow-level datasets, such as UNSW-NB15 and CSE-CIC-IDS2018:

First, non-numeric and identifier columns—namely Flow ID, Timestamp, IP addresses, ports, protocol, and attack category—were discarded to promote the generalization capability of the model. As a result, only numeric flow features were considered for further processing. It is worth noting that no payload analysis was conducted in this step, preserving the system’s lightweight property.

2.

For the HTTP-level dataset (CSIC 2012):

The feature extraction step was divided into two separate categories. On the one hand, a number of statistical handcrafted features were designed, including request length, request and payload entropy, URL depth, parameter number, digit ratio, and the occurrence rate of malicious keywords. On the other hand, character-level TF-IDF features were extracted to identify structural patterns. More specifically, a character-level analyzer was used with an n-gram range of (3, 5) and a maximum of 400 features.

Lastly, all extracted features were combined using a sparse representation to efficiently handle memory usage.

4.2. Feature Normalization and Stability

In order to prevent the disproportionate influence of individual features during the classification process, each feature vector was normalized prior to model training [28]. Let

$$x=\left[x_1, x_2, \dots ,x_n\right]$$

(1)

denote the raw feature vector. Standard normalization is applied as follows:

$$x_i^{\prime }={\displaystyle \frac{x_i-{\mu }_i}{{\sigma }_i}}$$

(2)

where ${\mu }_i$ and ${\sigma }_i$ represent the mean and standard deviation of the i-th feature computed on the training set.

Although tree-based models such as XGBoost are generally robust to feature scaling [28], normalization enhances stability across heterogeneous datasets and improves reproducibility.

4.3. Two-Stage Cascade Detection Model

To address the limitations of single-stage classifiers in zero-day attack detection, a two-stage cascade classification strategy is employed. In this framework, each stage is optimized for a distinct objective. Among various approaches for constructing multi-stage models, the cascade of classifiers is particularly effective in scenarios requiring both high detection accuracy and low latency, such as computer security applications. As illustrated in Figure 1, the system operates sequentially.

In Stage 1, a recall-oriented classifier functions as an initial screening mechanism for incoming traffic. Only samples identified as suspicious are forwarded to Stage 2, where a precision-oriented classifier performs a more detailed analysis. This design ensures that benign traffic is processed rapidly, thereby avoiding unnecessary computational overhead, while computational resources are selectively allocated to potentially malicious samples. Consequently, the cascade architecture achieves an effective balance between detection sensitivity, precision, and operational efficiency.

4.3.1. Stage 1: Recall-Oriented Detection

The first phase is aimed at maximizing recall, which ensures that potentially malicious, never-before-observed attacks are not discarded.

Define f₁(x) ∈ [0, 1] as the probability output of the Stage 1 classifier given the input sample x. A sample is labeled as suspicious whenever:

f₁(x) > θ₁

(3)

where θ₁ is a threshold value for recall, set to emphasize recall, and is given as 0.15 based on empirical values. This is to ensure that benign anomalies are allowed to proceed to the next stage.

For Stage 1, a gradient boosting decision tree approach named XGBoost is used [29] because of:

-

Strong performance on tabular intrusion detection data;

-

Low inference latency;

-

CPU efficiency compared to deep neural models.

4.3.2. Stage 2: Precision-Oriented Refinement

The second stage aims at reducing false positives by using more stringent decision thresholds in pre-filtered samples from Stage 1.

Let f₂(x) ∈ [0, 1] be the Stage 2 output. The final attack decision is declared if:

f₂(x) > θ₂

(4)

where θ₂ is a threshold focused on high precision. In all experiments, θ₂ is set to 0.85 to be more conservative by reducing false positives, as done in recent real-time IDS studies.

Furthermore, Stage 2 is trained only on those samples that go beyond the Stage 1 threshold at the time of training. This selective training approach enhances the ability to distinguish near the decision boundary, as in the cascade optimization research articles.

4.3.3. Cascade Optimization Strategy

It follows that the cascade model is trained step by step:

Picked-up Stage 1 training utilizes the complete training dataset and is optimized for recall.

Stage 2 training uses samples only flagged by Stage 1 and is optimized for precision.

The hyperparameters of both classifiers are optimized via grid search combined with cross-validation, whereas the decision thresholds θ₁ and θ₂ are optimized separately to reflect their different goals.

This division of optimization goals helps to enhance stability in zero-day settings.

4.3.4. Cascade Model Configuration

The two-stage cascade model used XGBoost (gradient boosting decision trees) in both stages. To make the results fully reproducible, a random seed (random_state = 42) was fixed, and parallel processing was turned on by setting n_jobs = −1.

Stage 1—Recall-Oriented Detection

The goal of Stage 1 is to achieve maximum recall and prevent the rejection of possible zero-day attacks early on. The model was set up as follows:

-

n_estimators = 300;

-

max_depth = 6;

-

learning_rate = 0.1;

-

subsample = 0.9;

-

colsample_bytree = 0.9;

-

scale_pos_weight = N_neg/N_pos;

-

eval_metric = logloss.

To address the issue of class imbalance, scale_pos_weight was calculated dynamically based on the training data.

A conservative threshold value of θ₁ = 0.15 was set; thus, any given sample x for which f₁(x) > 0.15 is passed on to the next level for further validation.

Stage 2—Precision Oriented

Stage 2 aims to reduce the number of false positives among the candidate samples. The parameters for Stage 2 are:

-

n_estimators = 400;

-

max_depth = 4;

-

learning_rate = 0.05;

-

gamma = 1.0;

-

reg_alpha = 0.5;

-

reg_lambda = 1.0;

-

eval_metric = logloss.

The final decision threshold was set to a stricter value of θ₂ = 0.85. It is pertinent to note that Stage 2 was trained only on the set of samples that had successfully passed the Stage 1 threshold during the training process. This targeted training enables the second classifier to identify decision boundaries around regions of ambiguity.

4.3.5. Training Procedure

The cascade training process was carried out in the following order:

• Strict zero-day attack-type separation was performed before preprocessing.
• StandardScaler was fitted solely on the training data.
• Stage 1 was trained on the entire training set.
• Stage 1 probabilities were calculated on the training set.
• Stage 2 was trained only on instances that met the condition f₁(x) > θ₁.
• At prediction time, sequential thresholding (θ₁, θ₂) was used.

This is a well-organized procedure that maintains methodological rigor, avoids data leakage, and is fully reproducible.

4.4. Strict Zero-Day Evaluation Protocol

One of the most important methodological aspects of this research is the use of a strict zero-day evaluation protocol that helps to avoid optimistic bias and provides a realistic assessment of the capability of generalization. This section will clearly explain what the protocol is, why it is needed, and how it is used.

Most of the evaluations of intrusion detection systems are carried out using random splits of the training and testing data, where instances belonging to the same category of attacks can be found in both datasets. Although these approaches to evaluating systems tend to have high accuracy, they are not very representative of real-world scenarios. In real-world scenarios, zero-day attacks are considered to be new categories of attacks and not new instances of known attacks.

Most of the previous work has emphasized the problem of evaluation that does not strictly separate attack types, leading to overestimation of performance and a lack of understanding of real-world robustness [1]. When models are trained on the statistical footprint of an attack type, even if it is partial, they are likely to learn attack-specific artifacts rather than general attack behavior patterns.

Thus, to avoid overestimation of zero-day resilience, we apply an attack-type separation protocol to strictly separate attack types between the training and testing phases.

In this paper, a zero-day attack is considered as an attack category that is not present in the training set at all but only in the testing set.

It is important to note that this definition is generated at the attack-type level, not at the sample level. This is to ensure that the classifier does not learn patterns from the same attack type.

4.4.1. Protocol Description (Step-by-Step Implementation)

The strict zero-day protocol involves the following steps:

Step 1—Dataset Cleaning and Label Standardization

All datasets are preprocessed to ensure standardized attack-type labeling. Duplicate entries and flawed samples are eliminated.

Step 2—Attack-Type Partitioning

Attack types are partitioned into two mutually exclusive sets:

-

Training Attack Set;

-

Testing (Zero-Day) Attack Set.

No attack type is shared between the two sets.

Step 3—Training Set Construction

The training set includes:

-

All benign traffic samples;

-

Only the attack types belonging to the Training Attack Set.

Step 4—Testing Set Construction

The testing set includes:

-

All benign traffic samples;

-

Only the attack types belonging to the Testing (Zero-Day) Attack Set.

In this way, zero-day attack-type leakage is strictly avoided.

4.4.2. Dataset-Specific Configurations

The evaluation protocol is applied consistently across three benchmark datasets: CSIC 2012 (HTTP-level), UNSW-NB15 (intra-domain), and CSE-CIC-IDS2018 (cross-domain). Table 3 summarizes the zero-day evaluation configurations implemented in this study. These configurations are specifically designed to simulate HTTP-level, intra-domain, and cross-domain zero-day scenarios, thereby enabling a systematic assessment of the model’s generalization capability under varying levels of domain shift and operational complexity.

Table 3. Zero-day evaluation setups across datasets.

Dataset	Zero-Day Type	Training Attacks	Testing Attacks
CSIC 2012	HTTP level	Known web attacks	Unseen web attacks
UNSW-NB15	Intra-domain	DoS, Fuzzers	Exploits, Worms
CIC-IDS2018	Cross-domain	DoS, DDoS, brute force	SQLi, Bot, infiltration

The evaluation demonstrates that the cascade model generalizes effectively within the same domain and remains robust under cross-domain conditions. However, as expected, a moderate performance decline is observed in the cross-domain setting due to increased distributional shift and domain variability.

4.4.3. HTTP-Level Zero-Day Evaluation

The evaluation framework employed in this study consists of three test scenarios, each representing a progressively increasing level of generalization. These scenarios include HTTP-level zero-day detection, intra-domain zero-day detection, and cross-domain zero-day detection. In the cross-domain setting, the model is required to detect attacks originating from domains that differ significantly from those used during training, thereby imposing the most challenging generalization conditions. The scenarios are organized hierarchically, with the level of generalization difficulty increasing from the first to the third test. This structured design enables a systematic assessment of the model’s robustness and adaptability under varying degrees of domain shift.

4.4.4. Intra-Domain Zero-Day Evaluation

In the intra-domain zero-day evaluation setting, both training and testing attacks belong to the same high-level behavioral domain (e.g., network-layer or application-layer attacks) but differ in specific attack categories. This configuration assesses the model’s ability to generalize from known attack types to previously unseen attacks that exhibit similar behavioral characteristics. For instance, a model trained on denial-of-service and fuzzing attacks may be evaluated on exploit- or worm-based attacks that share comparable traffic patterns while differing in operational implementation. Such scenarios are particularly realistic, as adversaries often modify or extend existing techniques rather than introduce entirely novel attack paradigms.

Recent research suggests that intra-domain zero-day detection is achievable when models effectively learn underlying behavioral patterns instead of relying on attack-specific signatures. Consequently, this evaluation setting serves as an essential baseline for measuring generalization capability within a consistent traffic domain.

4.4.5. Cross-Domain Zero-Day Evaluation

Cross-domain zero-day evaluation represents a more demanding and realistic assessment scenario. In this setting, the model is trained on attacks from one behavioral domain and evaluated on attacks originating from a different domain. For example, training may focus on volumetric or brute-force attacks, whereas testing may involve application-layer threats such as SQL injection or botnet activity. Prior research highlights that cross-domain zero-day detection remains a significant challenge, particularly for flow-based intrusion detection systems that lack deep visibility into application-layer behavior. Performance degradation under such conditions reflects the inherent difficulty of transferring learned patterns across fundamentally different attack categories.

Despite these challenges, cross-domain evaluation is essential for assessing the robustness and real-world applicability of intrusion detection systems operating in complex, multi-layered environments. Empirical studies demonstrate that models performing well under single-domain conditions may experience substantial performance declines when exposed to entirely novel attack behaviors. Consequently, cross-domain evaluation serves as a critical benchmark for measuring true generalization capability.

4.4.6. Stringency of the Protocol

The protocol is regarded as strict because:

• There is no overlap of attack categories between the training and testing datasets.
• There is no leakage of information at the sample level through random splitting.
• The evaluation is realistic because new attack types emerge after the model has been trained.
• Cross-domain evaluation is used to test generalization in behavior.

This is different from the normal evaluation process that assumes a stable distribution of attacks over time.

4.4.7. Performance Considerations Under Strict Protocol

Because the model is not trained on the test attack categories, several important implications are derived. First, the accuracy is a true measure of the model’s generalization ability. In addition, it must be pointed out that the accuracy values may be lower than those that would be achieved by a random split. As a result, the false positive rate (FPR) becomes a more important measure of operational performance.

This protocol prevents improvements in accuracy from being attributed to overlap or memorization.

The zero-day evaluation protocol used in this study not only avoids optimistic bias due to random data splitting but also strictly separates attack types. Moreover, the evaluation of both intra-domain and cross-domain generalization in this study ultimately provides a realistic assessment of deployment readiness.

The zero-day definition at the attack-type level and the strict separation of training and testing categories provide a more reliable benchmark for the assessment of zero-day detection systems.

4.5. Algorithm Summary

The detection procedure is described in Algorithm 1. It formally describes the two-stage cascade decision process. The model accepts a traffic sample x as input and generates a predicted label $\widehat{y}\in \left\{\mathrm{0,1}\right\}$ as output, where 0 and 1 denote normal and malicious traffic, respectively.

Algorithm 1. Two-stage cascade zero-day detection

1. Extract lightweight metadata features (x). 2. Normalize features ($x_i^{\prime }$). 3. Compute $f_1\left(x^{\prime }\right)$ using the Stage 1 classifier. 4. If $f_1\left(x^{\prime }\right)$ is less than or equal to θ1, it is classified as normal. 5. Otherwise, compute $f_2\left(x^{\prime }\right)$ using the Stage 2 classifier. 6. If $f_2\left(x^{\prime }\right)$ is greater than θ2, it is classified as an attack $(\widehat{y}=1)$; otherwise, it is classified as normal $(\widehat{y}=0)$. 7. Return $\widehat{y}$.

This formalized procedure allows for efficient filtering, keeps false positives low, and offers excellent zero-day detection capabilities in real-world scenarios.

4.6. Real-Time Performance Optimization

The final methodological objective of the study is the appropriateness of the proposed approach for real-time deployment in high-speed and resource-constrained settings. To this end, the system is explicitly designed to minimize computational overhead. This is achieved by a design that avoids payload inspection, thus eliminating any need for deep packet analysis; filtering of benign traffic earlier in the cascade, which reduces unnecessary processing; and tree-based ensemble models featuring low inference latency and maintained strong classification performance.

In addition to the accuracy of detection, the system is gauged on the operational performance metrics, which best describe the system’s deployability in practice. Here, latency is measured with the average inference time per sample, throughput quantifies the number of samples that are processed per second, and memory consumption describes the resident memory needed during inference. Together, these metrics form a comprehensive assessment of the feasibility of the system for practical applications.

Moreover, the proposed solution encompasses various methodologies that are currently considered best practices. Specifically, it shows high resistance to zero-day attacks without relying on signatures, improvements in terms of precision, as well as a lightweight solution that can be applied in real time. Moreover, there is a robust evaluation process of zero-day attacks both inside and outside domains, taking into consideration a realistic validation process of its generalization performance.

Such properties make the proposed solution different from many existing zero-day detection systems, in which the aim of accuracy may come into conflict with the goals of system stability. The proposed solution takes a balanced approach in terms of detection, efficiency, and strength in the context of intrusion detection and web application firewalls.

5. Results

The contribution of this section is to present the experimental design and results related to the proposed cascade-based zero-day attack detection system. This section is organized to be consistent with the key research challenges formulated in Introduction section which evaluates the method’s effectiveness step by step: feature representation, cascade detection performance, strict zero-day generalization, and real-time operational feasibility.

All the experiments were conducted on three publicly available benchmark datasets, which include a scenario of HTTP-level, flow-level, and cross-domain traffic. The flow of experiments in Figure 2 consists of dataset preprocessing, feature normalization, clear separation between attack types, cascade model training, and thorough performance evaluation. This aims to avoid any potential information leakage from the training to the testing phase. This is also desired to be as close as possible to real-world zero-day deployment scenarios.

Figure 2. Experimental workflow: data preprocessing, separation of the zero-day type of attack, training the cascaded classifier, and evaluation.

This is the manner in which we continue: we cleanse the set of attacks, we normalize all the features, we divide all the various kinds of attacks, we build the cascade model, and we test it on fresh attacks that have not been seen before.

5.1. Lightweight Feature Representation for High-Speed and Encrypted Traffic

So that we can test different environments, we have worked with three popular datasets (CSIC 2012, UNSW-NB15, and CSE-CIC-IDS2018) for the public environments. These datasets contain a variety of attack surfaces and details.

Table 4 summarizes the key features of the datasets used.

Table 4. Key features of the datasets used in the experiments.

Dataset	Traffic Type	Attack Scope	No. of Samples
CSIC 2012	HTTP level	Web attacks	~36,000
UNSW-NB15	Flow level	Network attacks	~175,000
CSE-CIC-IDS2018	Flow level	Multi-domain attacks	>6 million

The initial research problem is related to the development of the feature representation itself, which should work well under the circumstances of encrypted traffic as well as high volumes. To tackle the problem, the solution will use solely the small statistical/structural/flow-level features, thereby skipping the packet inspection functionality.

Using this design enables compatibility with encrypted protocols. It also ensures that the extraction overhead is minimal. The feature vectors that were extracted had normalization performed before being used for training.

The effectiveness of such a representation is evidenced by consistent detection performance on diversified datasets ranging from application-layer HTTP traffic (CSIC 2012) and massive network traffic (UNSW-NB15 and CSE-CIC-IDS2018). The proposed system could even achieve a considerable level of detection performance under cross-domain zero-day attack scenarios. This further supports that such features can describe general behavioral characteristics and not attack-centered markers.

All the experiments were written and executed using the Python 3.10 programming language with the scikit-learn and XGBoost libraries. The choice of the models was dictated by the necessity to succeed in the balance between the performance on the detection task and efficiency. The above models belong to the class of tree.

The architecture of the cascade system remained the same as described in Section 3. Stage 1 emphasized recall. Stage 2 highlighted precision. The threshold levels for selection have been determined based on experimentation and past research conducted on cascade-based IDSs.

For replicability, experiments were conducted with a normal workstation without dedicated acceleration support.

The above setup in Table 5 demonstrates a real-world deployment environment presented in real-time IDS/WAF solutions running on conventional servers or edge devices.

Table 5. Experimental hardware and software setup.

Component	Specification
CPU	Intel Core i7 (8 cores)
RAM	32 GB
GPU	None
OS	Windows (64-bit)
Python	3.10+
Libraries	scikit-learn, XGBoost

5.2. Evaluation Metrics

The performance of the proposed cascade-based zero-day detection system was evaluated with a wide range of metrics that measure both detection effectiveness and real-time operational feasibility. Following recent best practices in intrusion detection research, the evaluation framework combines traditional classification metrics with system-level performance indicators. This combination reflects realistic deployment conditions.

This dual-metric evaluation approach is crucial. High detection accuracy alone does not suffice for practical intrusion detection systems operating in high-throughput environments. In those cases, latency, memory usage, and false positive rates greatly affect operational stability.

5.2.1. Detection Metrics

Detection performance was assessed using accuracy, false positive rates (FPRs), and the confusion matrix. These metrics are often used in intrusion detection research and provide different perspectives on how effective and reliable the classification is [30].

Accuracy looks at the overall proportion of correctly classified samples and is calculated as

$$Accuracy={\displaystyle \frac{TP+TN}{TP+TN+FP+FN}}$$

(5)

In this formula, TP, TN, FP, and FN represent the numbers of true positives (TP), true negatives (TN), false positives (FP), and false negatives (FN).

While accuracy offers a general sense of detection performance, it can be misleading in highly unbalanced datasets, which are common in intrusion detection scenarios. Thus, it should be considered alongside metrics that focus on false positives.

The false positive rate measures the volume of benign traffic incorrectly flagged as malicious and is calculated as

$$FPR={\displaystyle \frac{FP}{FP+TN}}$$

(6)

FPR is an important metric for real-world applications, especially in inline IDSs and WAF systems, where false alarms can disrupt normal services and harm user experience.

In practical IDSs, false positives can cause service interruption, analyst fatigue, and operational overhead. Therefore, it is generally considered a key requirement for practical IDSs to keep the false positive rate low [1,15].

From the existing literature, it has been observed that keeping the FPR low is more important than achieving high recall.

The confusion matrix provides a detailed overview of classification results, displaying the counts of true positives, true negatives, false positives, and false negatives. It enables a thorough analysis of detection behavior and error distribution, especially when evaluating zero-day threats.

By examining the confusion matrix, one can assess the balance between detection sensitivity and false alarm reduction. This is essential for understanding system performance beyond summary metrics.

These metrics evaluate detection capability and operational stability.

5.2.2. Real-Time Performance Metrics

In addition to detection performance, we assessed the system using real-time operational metrics. We wanted to see if it works well in high-speed and resource-limited environments. Recent research on intrusion detection has paid more attention to these metrics.

Latency refers to the average time needed to process a single traffic sample. It is calculated as follows:

$$Latency={\displaystyle \frac{T_{\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{e}\mathrm{r}}}{N}}$$

(7)

In this equation, $T_{\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{e}\mathrm{r}}$ is the total inference time, and N is the number of samples processed.

Low latency is essential for real-time intrusion detection systems operating in inline or near-inline modes. Any delay in decision making can weaken security effectiveness.

Throughput measures how many samples can be processed each second. It is calculated as

$$Throughput={\displaystyle \frac{1000}{Latency}}$$

(8)

This metric reflects how scalable the system is during periods of high traffic. It is particularly important for use in backbone networks and large-scale web services.

Memory consumption is indicated by the resident set size (RSS) of the detection system during inference. This measures the actual memory usage under real operational conditions.

Memory efficiency is crucial for deployment on edge devices, virtualized environments, and cloud infrastructures, where resource limits may restrict the use of complex models.

Table 6 summarizes the evaluation metrics used in this study along with their objectives.

Table 6. Evaluation metrics and their operational relevance.

Metric Category	Metric	Objective
Detection	Accuracy	Overall classification correctness
Detection	False Positive Rate	Operational stability
Detection	Confusion Matrix	Error distribution analysis
Real Time	Latency	Real-time feasibility
Real Time	Throughput	Scalability under high traffic
Real Time	Memory Usage	Resource efficiency

These metrics check if deployment can happen in high-speed, resource-limited settings.

To provide context for performance, we compared the proposed cascade architecture with standard classical and deep learning intrusion detection models. This includes Random Forest, standalone XGBoost, and autoencoder-based anomaly detection. These baselines represent methods often used in recent studies on zero-day detection.

5.3. Evaluation of the Two-Stage Cascade Model

The second research challenge is how to control recall and precision when detecting zero-day malware. This issue can be solved using the proposed two-stage cascade model. In this model, Stage 1 gives higher priority to recall, and then Stage 2 makes the final decision to eliminate the problem of false alarms.

Table 7 shows the performance of our zero-day detection on various datasets.

Table 7. Zero-day detection performance across datasets.

Dataset	Zero-Day Type	Accuracy (%)	FPR (%)	Latency (ms)	Throughput (req/s)	Memory (MB)
CSIC 2012	HTTP level	89.22	1.00900	5 × 10−3	2.0 × 105	0.82
UNSW-NB15	Intra-domain	94.81	0.50000	3.6 × 10−3	2.8 × 105	1.09
CSE-CIC-IDS2018	Cross-domain	80.53	0.00200	6.3 × 10−3	1.6 × 105	6.21
CSE-CIC-IDS2018	Intra-domain	99.99	0.00057	2.3 × 10−3	4.3 × 105	4.05

Table 7 reports both detection and operational metrics to provide a deployment-oriented evaluation. Latency represents the average inference time per traffic sample under CPU-only execution. Throughput is derived from measured latency and reflects the number of samples processed per second. Memory corresponds to the RSS during inference.

Across all datasets, inference latency remains within 0.002–0.006 ms per sample, corresponding to 115k–471k processed requests per second. Memory consumption ranges from 0.8 MB to 6.2 MB, confirming that the proposed architecture operates with minimal computational overhead.

These results demonstrate that the cascade filtering strategy enables high-speed processing while maintaining near-zero false positive rates, making the system suitable for inline IDS and WAF deployment without hardware acceleration.

The effectiveness of the approach can be observed through the ROC and precision–recall curves in Figure 3 on the UNSW-NB15 dataset, where a good balance between sensitivity and precision can be appreciated.

Figure 3. ROC and precision–recall curves for zero-day attack detection on UNSW-NB15.

5.4. Strict Zero-Day Evaluation and Generalization Analysis

The third research challenge is related to the zero-day assessment. To avoid overestimation, a strict attack-type separation protocol was required. This means that attack types used for model training could not be involved in the test stages at all.

In the CSIC 2012 dataset, the performance of the proposed system on the unseen types of web attacks demonstrated stable accuracy in the range of 89–91%. This is due to the difficulty in accurately identifying application-layer zero-day attacks by using simple statistical features.

However, the system had a low false positive ratio, proving its appropriateness for the web application firewall task where service continuity is essential. These results are in line with previous research, indicating that HTTP-level anomalousness identification is very sensitive to traffic fluctuations and normal request variation.

In the case of UNSW-NB15 data, the new design was found to generalize quite well to intra-domain zero-day attacks, with 95.13% accuracy and an FPR of 0.47%. This reveals that new attack types with similar behavioral patterns to known attacks can be well identified by cascading design patterns.

From Figure 3, it is shown that the ROC curve and precision–recall curve provide a proper trade-off between the sensitivity in identifying malicious traffic and the mitigation of false alarms. This is revealed by the high area under the ROC curve as well as the precision–recall curve, which is similar to other recent research on the same topic using the cascade approach [31].

The most challenging experiment would be the cross-domain zero-day test on the CSE-CIC-IDS2018 dataset. When trained with volumetric attacks and brute-force attacks and tested with application-layer attacks such as SQL injection attacks, botnet attacks, and infiltration attacks, it was able to yield an accuracy of 80.53% with a near-zero FPR.

These findings indicate that there is a dependence on the semantic similarity between the domains. When operating inside the domain, meaning that the attack samples for training and test procedures have SEMIC features, it performed well, with an accuracy of 95.13%. However, the accuracy for zero-day detection across the domain is slightly lower, at 80.5%.

To be more specific, it must be pointed out that difficulty is involved in generalizing performance on attack types, whose features differ greatly. Despite this, the nearly zero rate of false positives is kept not only within the same domain but also in cross-domain testing. This demonstrates the robustness of the strategy of cascade decisions.

5.5. Real-Time Performance and Deployment Feasibility

The last challenge for the research was real-time deployability. Besides detection accuracy, other evaluation criteria involved in system evaluation included latency, throughput, and memory usage, which will be discussed in Table 8 below.

Table 8. Real-time feature of the proposed system.

Metric	Observed Range
Latency	0.002–0.006 ms
Throughput	150,000–470,000 req/s
Memory Usage	0.8–6.2 MB

The results show microsecond levels of inference latency over all datasets, thus supporting the assertion that the cascade decision pipeline causes little processing latency. Throughput levels above 150,000 requests per second show compatibility with high-speed links and web services.

The memory usage is kept below 7 MB for all cases. This is considerably lower compared to the other intrusion detection systems based on deep learning. It makes this system less hardware dependent for implementation on servers or edges.

5.6. Summary of Experimental Findings

The results of the experiment have confirmed that the proposed solution overcomes all four challenges of the research:

• Representation of lightweight features enables encrypted and quick traffic analysis.
• The two-stage cascade architecture meets the requirement of balancing recall and precision simultaneously, which reduces the false positive rates without increasing any computational complexity.
• Evaluation with strict zero-days allows for getting a realistic idea about generalization ability, as well as sensitivity to the domain.
• Real-time optimization offers low latency, high throughput, and a small memory footprint.

The experimental design and the results together confirm the vital role of architectural design and evaluation approach in zero-day attacks irrespective of being hampered by nominal accuracy gain in classification.

The code used to obtain these results and the datasets are available at [32].

6. Comparative and Cross-Dataset Analysis

In order to fully assess the effectiveness of the proposed two-stage cascade architecture, a series of baseline, ablation, and threshold sensitivity studies were performed on three vastly different intrusion detection datasets: CSE-CIC-IDS2018 (flow level, large scale), UNSW-NB15 (flow level, intra-domain zero-day), and CSIC-2012 (HTTP level, application layer).

Each experiment strictly adheres to the attack-type separation protocol outlined in Section 4.4, which ensures that test attack types are completely removed from the training set.

6.1. Baseline vs. Cascade Across Datasets

The results of the comparative analysis are presented in Table 9.

Table 9. Comparative evaluation across datasets.

Dataset	Model	Accuracy (%)	FPR (%)	Latency (ms)
CSE-CIC-IDS2018	Single stage	80.44	0.14	0.0078
	Full cascade	80.53	0.0019	0.0063
UNSW-NB15	Single stage	93.96	7.91	0.0035
	Full cascade	94.81	0.50	0.0036
CSIC-2012	Single stage	91.19	8.60	0.0051
	Full cascade	89.22	1.01	0.0050

6.2. Quantitative Architectural Impact

The cascade is successful in reducing the false positive rates without any impact on the latency.

CSE-CIC-IDS2018 (cross-domain):

-

FPR reduced by ~70× (0.14% → 0.0019%).

-

Accuracy unchanged.

-

Large domain shift robustness shown.

UNSW-NB15 (intra-domain zero-day):

-

FPR reduced from 7.91% to 0.50% (≈16× reduction).

-

Accuracy slightly improved.

-

An unstable baseline system turned into a useful IDS.

CSIC-2012 (HTTP level, semantic attacks):

-

FPR reduced from 8.60% to 1.01% (≈8× reduction).

-

Accuracy slightly deteriorated, but system stability improved drastically.

-

Precision–recall curve regulated in application-layer scenario.

In all datasets, the latency is maintained in the range of 0.003–0.007 ms, thus confirming that the cascade does not introduce any computational latency.

6.3. Ablation Analysis

The Stage 1 model alone (recall oriented) resulted in unacceptably high false positives:

-

UNSW: FPR ≈ 23.9%;

-

CSIC: FPR ≈ 23.8%.

This validates that the precision refinement in Stage 2 is not an optional component but a necessity. The decoupling of the recall and precision sub-problems is the key to robustness.

6.4. Threshold Sensitivity and Operational Trade-Off

The sensitivity analysis of the parameters θ₁ and θ₂ demonstrates that the operating points remain well controlled, as reported in Table 10 and Table 11 for the UNSW-NB15 and CSIC-2012 datasets.

Table 10. Example (UNSW-NB15).

θ1	θ2	Accuracy (%)	FPR (%)
0.15	0.70	97.04	1.79
0.15	0.85	94.81	0.50
0.15	0.95	87.00	0.07

Table 11. Example (CSIC-2012).

θ1	θ2	Accuracy (%)	FPR (%)
0.15	0.65	89.22	1.01
0.15	0.80	87.69	0.12

These results confirm that:

-

A monotonically decreasing FPR is obtained by an increasing value of θ₂.

-

The system provides controllable deployment options.

-

Performance gains are not the result of random chance but rather the design of the system.

This is particularly relevant to the issue of static thresholds, as the system enables adaptive adjustment during deployment.

6.5. Domain Sensitivity and Generalization

Performance is dependent on domain similarity:

-

Cross-domain (CSE): lower accuracy but near-zero FPR.

-

Intra-domain (UNSW): high accuracy and low FPR.

-

Application layer (CSIC): this is a standard covariate shift problem in statistical learning, where domain transfer restrictions are imposed.

The performance degradation in cross-domain settings is primarily because of the absence of semantic application-layer data, rather than the potential instability of the classifier.

The system is intended to prioritize robustness over functionality rather than optimizing detection. In practical IDSs/WAF systems, high FP rates lead to service degradation and alert fatigue; therefore, a low FPR is critical for real-time systems [1,15].

6.6. Accuracy–Operability Trade-Off

In contrast to deep learning strategies aiming at >97–99% accuracy on random splits, our strategy deliberately sacrifices accuracy in strict zero-day settings for:

-

Dramatic FPR reduction (up to 70×);

-

Microsecond latency;

-

Throughput > 200k req/s;

-

CPU-only feasibility;

-

Strict attack-type separation protocol.

The 4–7% accuracy trade-off: This trade-off is deliberate, and the accuracy loss is offset by gains in operational robustness.

On varying datasets and traffic patterns, the cascade architecture:

-

Dramatically reduces false positives;

-

Supports real-time processing;

-

Shows robustness to domain shift;

-

Offers controllable operating points;

-

Resists strongly optimistic evaluation bias.

These findings validate the hypothesis that architectural design and strict evaluation protocol design are more relevant to zero-day attacks than accuracy optimization as an end in itself.

For each dataset, the cascade architecture supported:

-

80.53% accuracy at 0.002% FPR (cross-domain, CSE-CIC-IDS2018),

-

94.81% accuracy at 0.500% FPR (intra-domain, UNSW-NB15), and

-

89.22% accuracy at 1.009% FPR (HTTP level, CSIC-2012),

with microsecond latency (0.003–0.006 ms).

7. Comparative Analysis with Existing Cascade-Based Architectures

There have been some recent works on the use of cascade or multi-stage architectures for intrusion detection to improve the stability of detection and minimize false positives. Most of the existing cascade-based architectures are designed and tested using conventional train and test splits or are more focused on known attacks rather than zero-day attacks.

In ref. [16], a cascaded architecture for an intrusion detection system is designed to minimize false positives using multi-stage filtering. The authors claim a 30–50% reduction in the FPR over single-stage classifiers. However, the experiment design does not strictly separate attack types, and the system is tested mainly on known attack types. Hence, its ability to generalize to novel attack types is unclear.

Likewise, a multi-stage hybrid IDS is proposed in [9] that combines anomaly-based and signature-based approaches. Although the proposed system is efficient in identifying known and unknown attacks, the design relies partially on signature elements, making it less applicable in a pure zero-day attack scenario where the patterns of the attacks are completely absent during training.

The design proposed in [30] uses cascaded machine learning classifiers optimized for heterogeneous networks. Although the design has a multi-layer structure that enhances accuracy, the experiment is performed using traditional random splits, which may cause optimistic estimates of performance.

Table 12 summarizes the comparison.

Table 12. Comparison with existing cascade-based IDS approaches.

Study	Cascade Design	Zero-Day Protocol	Real-Time Metrics	FPR Control	Hardware
Ref. [9]	Hybrid multi-stage	Partial	Not reported	Moderate	Mixed
Ref. [13]	Multi-stage ML	No strict separation	Not reported	Reduced vs. baseline	Not specified
Ref. [23]	Layered cascade	Random split	Not emphasized	Improved precision	Not specified
Proposed	Two-stage recall/precision	Strict attack-type separation	Latency 0.002–0.006 ms	<1% (≈0%)	CPU only

The proposed two-stage cascade architecture has four distinct differences from the existing approaches: a strict zero-day assessment protocol that avoids any overlap between training and testing attack classes, a clear recall–precision decoupling approach using separately optimized low (θ₁ = 0.15) and high (θ₁ = 0.85) thresholds, CPU-only real-time optimization that supports ultra-low latency (up to 0.006 ms) and high throughput with low memory (up to 6.2 MB), and robustness in cross-domain assessment, which maintains stability and near-zero FPRs even when encountering novel threat classes.

8. Analysis and Discussion

The experimental results have given a clear insight into the performance of the proposed lightweight two-stage cascade architecture under strict zero-day attacks. Instead of discussing the results, this section will try to discuss architectural trends, domain sensitivity, and implications.

8.1. Benchmark Relevance and Evaluation Realism

Notwithstanding the fact that the evaluation is based on popular benchmark datasets (CSIC 2012, UNSW-NB15, and CSE-CIC-IDS2018), which may not be representative of the nature of the newly emerging obfuscation methods as evident in the 2025–2026 traffic, the framework is still relevant given its focus on statistical and flow-level metadata rather than payload analysis. Since the system is not reliant on deep packet inspection or signature-based detection, it is naturally robust against encryption attacks, shallow payload polymorphism attacks, and simple traffic manipulation attacks.

More importantly, the strict attack-type separation protocol accurately portrays the real-world post-deployment scenario where new attack types begin to emerge after the system has been deployed. The evaluation framework mitigates the issue of optimistic bias and further enhances the confidence level of the evaluated zero-day generalization performance. Nevertheless, its relevance to contemporary encrypted traffic traces and adversarially designed settings is an area of high importance for future research.

8.2. Zero-Day Generalization and Domain Sensitivity

The result of the experiment indicates that the performance of the cascade-based detection system differs between intra-domain and cross-domain scenarios, which is very helpful for behavioral modeling.

In the case of intra-domain zero-day attacks, the system generalizes attack behaviors based on structural similarity to known attacks. This means that distinguishing recall-oriented filtering from precision-oriented refinement is helpful in making stable discrimination between behaviorally similar zero-day attacks.

In the case of cross-domain attacks, the system demonstrates performance degradation when the semantics of attacks are significantly different between the training and testing domains. This weakness is not caused by the instability of the classifiers but by the inherent limitation of flow-level statistical features in abstracting application-layer semantics. In other words, the problem is in feature abstraction, not model capacity.

The “new classes of attacks” are used to strictly denote the classes that are completely left out of the training process in the zero-day attack scenario. For example, in the experiment of CSE-CIC-IDS2018, volumetric attacks were used for training, and application-layer attacks such as SQL injection, Bot, and infiltration were left out for testing only. This is a true zero-day attack scenario, not a random split.

8.3. False Positive Control as a Design Priority

One of the key design considerations in this project is the control of false positives versus aggressive recall maximization. In practical scenarios of IDSs/WAF systems, too many false alarms can lead to service degradation, alert fatigue, and higher operational expenses. In previous works, it has been highlighted that in practical settings, the cost of false positives can be higher than the cost of false negatives [1,15].

The cascade structure tackles this problem by separating the sensitivity and precision goals into two stages. The first stage is responsible for ensuring that potential malicious instances are not eliminated too early, while the second stage uses more stringent discrimination to reduce false alarms. This approach sidesteps the traditional single-stage trade-off, where improving sensitivity necessarily leads to an increase in false positives.

The ability to maintain low false positive rates on diverse datasets is proof that the proposed structure promotes operational stability rather than overfitting accuracy.

8.4. Architectural Implications of the Two-Stage Cascade

The strength of the cascade model lies in its hierarchical decision-making process. By training Stage 2 on samples close to the decision boundary discovered by Stage 1, the model is able to focus its learning capacity on regions of the feature space that are most in doubt. This focused improvement helps to minimize unnecessary computational complexity while improving the accuracy of borderline examples.

In contrast to monolithic classifiers, the cascade model provides modular interpretability and flexibility. The parameters controlling recall and precision can be set independently, enabling system architects to customize the model’s behavior based on the application at hand without requiring retraining of the entire model.

This simplicity, combined with rigorous evaluation, proves that high-quality zero-day detection is not necessarily dependent on the use of deep neural networks or GPUs.

8.5. Real-Time Deployment and Computational Feasibility

In terms of deployment, the system satisfies very strict real-time constraints without using any specialized hardware. Decision latency at the microsecond level and high throughput are achieved through lightweight feature extraction, early benign filtering, and tree-based ensemble inference.

Unlike deep learning-based IDSs that demand large memory and GPU resources, the proposed system is very resource efficient. This is especially important for edge deployments, hybrid IDSs/WAF systems, and cloud-based systems where latency, scalability, and memory are of utmost importance.

The computational efficiency shown in this work gives credence to the idea that architectural optimization can be as important as predictive accuracy in security-critical systems.

8.6. Static Thresholds and Adaptive Extensions

The existing solution uses fixed thresholds for recall- and precision-based stages. Although fixed thresholds have the advantage of ensuring the clarity and reproducibility of the solution during the controlled assessment, their efficiency might be affected in non-stationary traffic patterns.

In practical applications, traffic patterns might change due to bursts, seasonal changes, or a gradual concept drift, which might result in an increase in the number of false positives or false negatives. In such cases, adaptive thresholding techniques, such as rolling statistical calibration or percentile-based adjustment, could be used to maintain a fixed false positive rate without requiring retraining of the model.

Adaptive thresholding, therefore, is a promising technique for improving the long-term efficiency of the solution.

8.7. Encrypted Traffic and TLS 1.3 Considerations

The framework is also compatible with encrypted traffic because it only relies on metadata and flow-level behavioral features. The reliance on TLS 1.3 also reduces visibility into some handshake parameters; however, the proposed system is independent of certificate contents and application-layer parsing.

Instead, it relies on transport-level information such as packet counts, byte counts, inter-arrival times, flow durations, and activity statistics, features that are still visible in TLS 1.3. Although semantic application-layer features are less visible, behavioral features at the flow level are still available as discriminative features.

Future work may include the use of advanced timing analysis or adaptive behavioral profiling to enhance robustness against increasingly privacy-preserving network protocols.

8.8. Overall Interpretation

The above experimental results verify the overall hypothesis of this paper: architectural simplicity, strict zero-day evaluation, and operational optimization can enable a deployable zero-day detection system independent of heavy deep learning infrastructure.

Instead of seeking the highest possible laboratory precision, the proposed cascade system seeks a well-balanced trade-off between detection power, false positive control, computational complexity, and robustness against strict attack-type isolation. The performance difference between the intra-domain and cross-domain experiments reflects the challenges of semantic modeling in flow-based intrusion detection, and the low false positive rates and real-time efficiency verify the feasibility.

In conclusion, the new approach moves the state of the art of zero-day intrusion detection from accuracy-oriented optimization to operational robustness and rigorous evaluation.

9. Conclusions

This paper offered a lightweight two-stage cascade architecture for real-time zero-day intrusion detection in network and web traffic scenarios. The proposed system was particularly developed to fill the existing gap between highly accurate laboratory IDS models and operationally deployable IDSs that need to meet very strict latency, throughput, and false positive requirements in CPU-only infrastructures.

The major contribution of this paper is in decoupling the recall and precision goals of the system in a strict zero-day evaluation setting following attack-type separation. The second stage of the system is trained only on the suspicious instances selected by a recall-focused first stage, and this approach enables the system to maintain stable false positive rates while preserving detection performance across diverse domains. The experiments on the CSIC 2012, UNSW-NB15, and CSE-CIC-IDS2018 datasets demonstrated that the cascade architecture generalizes well in intra-domain scenarios and remains robust in operation even in cross-domain zero-day settings.

In contrast to most deep learning-based IDS solutions, the proposed solution does not depend on payload analysis, GPU computing, or complex models. Rather, it is based on lightweight statistical and flow-level metadata, which allows the solution to be compatible with encrypted traffic, including TLS 1.3 networks. The results show that zero-day robustness, microsecond-level inference times, high throughput, and low memory requirements can be achieved simultaneously through architectural optimization, rather than solely through the complexity of the model.

A trade-off was made between operational stability and false positive mitigation, rather than pursuing optimal lab accuracy. This is because the solution is intended for real-world IDS and WAF system deployments, where high levels of false positives can negatively impact service functionality and operational expenses. The results indicate that simplicity in architecture and strict evaluation criteria can lead to a deployable and robust zero-day detection system.

However, there are still some limitations. The cross-domain generalization is restricted by the expressiveness of flow-level features, and the fixed decision thresholds may not be optimal in the non-stationary traffic environment. Future work may include domain adaptation and learning strategies for improving the robustness of cross-domain generalization, adaptive threshold strategies in the non-stationary traffic environment [33], and further experiments on modern encrypted traffic data and adversarial attack environments.

In summary, this paper has shown that zero-day intrusion detection does not necessarily require heavyweight deep learning-based approaches. Instead, a carefully designed cascade architecture and thorough evaluation can offer a comprehensive, efficient, and deployable solution for real-time cybersecurity systems.