This post reviews “Enhancing network intrusion detection systems with combined network and host traffic features using deep learning: deep learning and IoT perspective” by Estabraq Saleem Abduljabbar Alars and Sefer Kurnaz, published in Discover Computing in 2024.

Paper link: Springer DOI 10.1007/s10791-024-09480-3

The paper’s central idea is easy to state: a Network Intrusion Detection System should not only look at packets and flows. It should also look at host-side behavior such as logs, user activity, application events, and login patterns. The authors combine these network and host features, then train deep learning models for intrusion detection.

The Problem

Traditional NIDS usually falls into two broad families.

Signature-based systems are precise when an attack is already known, but they struggle with new or modified attacks. Anomaly-based systems can catch unfamiliar behavior, but they often produce too many false positives.

The paper argues that another limitation is just as important: many NIDS pipelines focus mainly on network traffic. That view is useful, but incomplete. A real intrusion may leave weak traces in packets while leaving stronger traces on the host: repeated login attempts, unusual file access, changed privileges, application-level anomalies, or suspicious system activity.

The paper’s research question is therefore:

Can intrusion detection improve if network traffic features and host traffic features are merged before deep learning classification?

Method Overview

The proposed pipeline has five stages.

1. Collect network traffic features from TCP/IP dump records.
2. Collect host activity features from system logs and user/application records.
3. Preprocess the data with cleaning, normalization, categorical encoding, and train/validation/test splitting.
4. Reduce and select features using correlation analysis, PCA, and recursive feature elimination.
5. Train deep learning models using CNN and LSTM-based architectures.

The dataset is the Kaggle Network Intrusion Detection dataset referenced by the paper. It contains connection records with 41 features and labels for benign traffic or attack classes. The paper describes the setting as a military-style LAN simulation with TCP/IP connection records, which is the familiar shape of KDD-style intrusion detection datasets.

Why Combine Network and Host Features?

The most useful part of the paper is the feature-level framing.

Network features describe what happens on the wire:

Feature family	Examples
Basic connection features	duration, protocol type, service, flag
Content features	failed login attempts, hot indicators, shell-like behavior
Time-based traffic features	recent connections to similar hosts or services
Host-based traffic features	activity associated with target hosts over broader windows

Host features describe what happens inside or around the endpoint:

Feature family	Examples
System activity	system calls, process behavior, application events
User behavior	login attempts, file operations, privilege changes
Application logs	web server events, database transactions, service-level activity

This matters because attacks are not purely network events. A brute-force attempt, privilege escalation, malware execution, or lateral movement campaign may be easier to recognize when host-side and network-side signals are seen together.

Model Architecture

The paper discusses both CNN and LSTM components.

CNNs are used because they can learn local patterns in feature representations. In intrusion detection, this means the model may learn combinations of traffic and host attributes that tend to appear together during attacks.

LSTMs are used because network activity has a temporal structure. Connections, login attempts, and service requests happen in sequences, and the order can matter.

The intended architecture is therefore a hybrid deep learning model:

Component	Role
CNN	Extract spatial or local feature patterns
LSTM	Capture temporal and sequential behavior
Dense classifier	Predict benign or attack traffic

The paper reports the following training setup in different sections: Adam optimizer, learning rate 0.001, 50 epochs, categorical cross-entropy, ReLU/softmax activations, and dropout. One detail to watch is that the paper mentions batch size 64 in one table and 128 in another section.

Reported Results

The headline result is strong. The paper reports that the proposed approach reaches 98.5% accuracy, with high precision, recall, F1-score, and AUC.

Metric	Reported value
Accuracy	98.5%
Precision	97.8%
Recall	96.9%
F1-score	97.3%
AUC	0.99

The paper also compares CNN, LSTM, and hybrid variants:

Model	Accuracy	Precision	Recall	F1-score	AUC
Proposed CNN-LSTM	98.5%	97.8%	96.9%	97.3%	0.99
Standalone CNN	95.4%	94.2%	92.7%	93.4%	0.94
Standalone LSTM	91.8%	89.5%	88.4%	88.9%	0.91
CNN-RNN hybrid	96.7%	95.3%	94.2%	94.7%	0.96

The authors also report 10-fold cross-validation metrics:

Metric	Mean value
Accuracy	94.5%
Precision	93.2%
Recall	94.1%
F1-score	93.6%

This is important. The 10-fold cross-validation result is lower than the headline 98.5% result, so a careful reader should treat 98.5% as the best reported setup rather than the whole story.

What The Paper Does Well

The paper’s main strength is that it pushes NIDS away from a packet-only view.

Combining network and host signals is a reasonable direction for modern intrusion detection. Real attacks often span multiple layers, and a detector that sees only one layer may miss context. The paper’s framing is useful for IoT and enterprise environments where traffic patterns and endpoint behavior both matter.

The second strength is the use of multiple evaluation metrics. Accuracy alone is dangerous in intrusion detection because datasets can be imbalanced. Precision, recall, F1-score, confusion matrix analysis, and ROC/AUC give a better picture of detection quality.

The third strength is the practical pipeline. Cleaning, normalization, encoding, feature selection, PCA, RFE, train/test split, and cross-validation are all standard steps. The paper presents a complete experimental workflow rather than only a model diagram.

What Needs Careful Reading

The paper also has several limitations.

First, the dataset is narrow. The paper uses a known intrusion detection dataset with 41 features. That makes comparison easier, but it does not prove that the model will work equally well on modern encrypted traffic, cloud workloads, IoT fleets, or adversarially adapted attacks.

Second, the paper’s results are not perfectly consistent across sections. The abstract emphasizes 98.5% accuracy. The cross-validation table reports 94.5% mean accuracy. The model description alternates between CNN, LSTM, and CNN-LSTM wording. Batch size is also reported differently in different places. None of this invalidates the idea, but it does mean the implementation details would need to be checked before reproducing the result.

Third, the paper does not deeply address deployment cost. A CNN-LSTM model may be practical in an offline or centralized pipeline, but real-time NIDS has latency, throughput, memory, and update constraints.

Fourth, interpretability is still limited. The paper includes feature importance, but a production security analyst needs more than a classification label. They need to know which signals caused the alert, how stable the explanation is, and whether the model can be trusted under drift.

My Takeaway

This paper is useful less because it proves that one specific CNN-LSTM model is the final answer, and more because it reinforces a good systems-security direction:

NIDS should become more context-aware.

Packets alone are often not enough. Host behavior alone is also incomplete. The interesting direction is the fusion layer between network evidence and endpoint evidence.

For future work, I would want to see this idea tested on:

1. modern datasets with encrypted traffic and cloud-native workloads,
2. real-time streaming pipelines,
3. adversarial or evasive attack traffic,
4. cross-dataset generalization,
5. analyst-facing explanations for each alert.

The paper’s strongest lesson is architectural: network security models should not be trapped at one observation point. Better detection will likely come from combining multiple weak signals into a stronger, better-contextualized view of the attack.