This post reviews “XNIDS: Explaining Deep Learning-based Network Intrusion Detection Systems for Active Intrusion Responses” by Feng Wei, Hongda Li, Ziming Zhao, and Hongxin Hu, published at USENIX Security 2023.

Paper link: USENIX Security 2023 - XNIDS

The paper starts from a practical frustration: deep learning-based Network Intrusion Detection Systems, or DL-NIDS, can detect difficult patterns, but their output is often just a score or a label. A network operator cannot safely block traffic just because a model says “anomaly.” They need to know what caused the alert, which entity should be acted on, and whether the response will disrupt benign traffic.

The Problem

DL-NIDS promises better detection, especially for unseen or subtle attacks, because deep models can learn complex patterns in packet and flow data. But the paper argues that detection alone is not enough for active response.

There are two gaps.

First, there is a semantic gap. A model score is not an operational interpretation. An operator needs answers like: was the source host suspicious, was it a specific TCP flow, did a set of hosts share a malicious pattern, or did a protocol field drive the alert?

Second, there is an error-cost gap. False negatives let attacks pass. False positives waste analyst time or, worse, cause response systems to block legitimate traffic. If a model is hard to explain, operators are less willing to trust automated response.

XNIDS tries to make DL-NIDS useful after detection. It explains why a model made a decision, then turns that explanation into defense rules for tools such as OpenFlow, iptables, Pfsense, and Squid.

Why Existing Explanations Are Not Enough

The paper compares XNIDS with common explanation methods such as LIME, SHAP, LEMNA, Integrated Gradients, and LRP. The key claim is not simply that those methods are bad. It is that DL-NIDS has a different input shape from many tasks where those methods work well.

Image classifiers usually explain one input image. Malware classifiers may explain one binary sample. DL-NIDS, however, often makes a decision from a current network input plus history inputs. A packet or flow is part of a time series. For example, an RNN or LSTM detector may classify xt using xt, xt-1, and earlier traffic.

The second issue is feature dependency. Network data is structured. TCP flags depend on TCP being valid. TCP and UDP can be mutually exclusive. Source IP, destination IP, port, protocol, and flag fields do not behave like independent pixels. LIME and SHAP often assume independent features, while LEMNA assumes adjacent features have similar importance. The paper argues that neither assumption fits packet header fields very well.

So XNIDS targets two problems at once:

1. explain the current decision while considering relevant history inputs;
2. preserve dependencies among structured network features.

XNIDS Explanation Design

XNIDS builds a local explanation model around one DL-NIDS decision. Its goal is to produce an explanation that is faithful, sparse, complete, and stable.

The first step is approximating history inputs. XNIDS does not assume that every previous input matters. It searches for a small set of history inputs that preserves the original model output within a small deviation. Then it removes less relevant history by host and protocol filters when that metadata is available. This is important because different attacks depend on different amounts of history. A DoS pattern and an OS scan do not necessarily need the same time window.

The second step is sampling around history inputs. XNIDS gives more weight to recent history inputs because recent traffic usually has stronger influence on the current decision. The paper uses weighted random sampling with a decay function. If all history inputs are equally important, this reduces to ordinary random sampling.

The third step is capturing feature dependencies. XNIDS groups features according to domain knowledge, the target DL-NIDS grouping strategy, or correlations in data. Then it uses sparse group lasso. This matters because sparse group lasso can select at two levels: entire feature groups and individual features within selected groups.

That design is a good fit for network data. If an explanation points to a TCP flag, it can also respect the larger TCP feature context. If a protocol group is irrelevant, it can be removed as a group. The result should be easier for an operator to read than a long list of isolated feature weights.

From Explanation To Rule

The most systems-oriented part of the paper is the defense rule generator.

XNIDS defines three rule scopes:

Scope	Meaning	Example
Per-flow	Affect one suspicious flow	Drop a specific TCP SYN flow
Per-host	Affect traffic from one host	Block a host doing OS scan behavior
Multi-host	Affect flows from several hosts	Block SSDP amplification traffic

The scope is chosen from explanation results and statistical information such as the involved IP pool, the largest number of packets from the same IP or MAC, and the largest number from the same port or protocol.

The paper also introduces two security constraints.

The first is a whitelist, so critical services are not affected by generated rules. The second is a block strategy:

Strategy	Behavior
Passive	Prefer blocking only malicious flows
Assertive	Use the inferred scope as-is
Aggressive	Prefer blocking suspicious hosts directly

Finally, XNIDS uses a unified rule representation with entity, action, priority, and timeout. This abstract rule can then be translated into concrete syntax for different enforcement tools. OpenFlow is fully supported in the paper’s evaluation, while iptables, Pfsense, and Squid are partially supported because not all of them expose the same priority or timeout semantics.

Evaluation Setup

The authors evaluate XNIDS against four DL-NIDS systems:

Target system	Model type	Dataset
Kitsune	Autoencoder-based NIDS	Kitsune dataset
ODDS	LSTM-based bot detector	CIC-DoS2017
RNN-IDS	Recurrent neural network	NSL-KDD
AE-IDS	Deep autoencoder	NSL-KDD

The baselines are LIME, SHAP, LEMNA, Integrated Gradients, and LRP. The paper evaluates explanation quality with four criteria: fidelity, sparsity, completeness, and stability.

Main Results

For fidelity, the paper modifies top-ranked benign features by replacing them with corresponding anomalous features, then observes how quickly detection accuracy drops. A steep drop means the explanation found features that truly matter. XNIDS has the lowest area under the ADA curve across the four systems:

System	Best baseline AUC	XNIDS AUC
Kitsune	0.409	0.316
ODDS	0.427	0.325
RNN-IDS	0.507	0.430
AE-IDS	0.438	0.331

For sparsity, XNIDS also performs best. Its MAZ AUC is 0.774, 0.814, 0.775, and 0.806 across the four systems, higher than all baselines. In plain terms, XNIDS assigns near-zero importance to most irrelevant features and leaves the operator with a smaller set of signals.

For completeness, the paper shows why history matters. At least 26% of anomaly samples do not contain enough information in the current input alone to produce a non-degenerated explanation. Methods that ignore history can miss parts of the attack story.

For stability, XNIDS is much more consistent than perturbation-based baselines. Its average stability scores are 0.850, 0.830, 0.914, and 0.807, while the best baseline score among LIME, SHAP, and LEMNA is 0.640.

The rule-generation evaluation is also practical. More than 90% of explanation latency is under 600 ms, and rule generation averages about 25 ms. The largest reported rule-generation latency is about 35 ms for an OpenFlow rule in the reconnaissance case.

Troubleshooting Findings

The paper’s case studies are especially useful because they show how explanations can debug a detector.

For OS scan, XNIDS highlights protocols such as LLMNR, NBNS, and SSDP, which matches the idea that scanning touches multiple discovery protocols. For HTTP flood, it identifies HTTP Referer as important, matching the attack setup where many requests use the same hyperlink.

The authors also categorize DL-NIDS errors:

Error type	Interpretation
False negative from parameter choice	The threshold or tuning may be wrong
False negative from model design	The detector may focus on insufficient features
Infected benign	Benign traffic from infected hosts is flagged
Disturbed benign	Benign traffic disturbed by network conditions is flagged
Unseen benign	New but legitimate behavior is flagged

After troubleshooting, XNIDS reduces blocked benign samples by 100% for infected benign, 65.36% for disturbed benign, and 96.79% for unseen benign in the reported experiment. The key idea is not magic retraining. Sometimes the fix is a narrower runtime rule; sometimes it is data augmentation and retraining.

What I Like

The strongest idea in XNIDS is that explanation is treated as part of response, not as a dashboard decoration. The paper does not stop at “these features mattered.” It asks whether those features can become an enforcement action with a reasonable scope.

I also like the history-input argument. Security events are rarely isolated points. A single packet may not explain an attack, but a short sequence can. XNIDS makes that observation explicit in the explanation method.

The feature-group design is another practical strength. Network data has structure, and explanation methods should respect it. Sparse group lasso is a reasonable bridge between mathematical sparsity and protocol-aware grouping.

What To Be Careful About

XNIDS is not a complete answer to autonomous defense.

First, the approach assumes access to enough model queries and relevant history data to build local explanations. In production, that may be expensive or limited by pipeline design.

Second, the rule-generation quality depends on available metadata. The paper explicitly says XNIDS does not generate defense rules if the required statistical information is unavailable.

Third, the paper’s robustness discussion is preliminary. Traffic-based adversarial examples still reach evasion rates of 33%, 49%, and 53% in the authors’ test. Considering history helps, but adversarially robust explanation remains hard.

Fourth, local explanations are still low-level. A list of important packet fields is useful, but operators often want higher-level narratives: credential stuffing, reconnaissance, botnet command traffic, or lateral movement. The paper recognizes this and mentions global explanation as future work.

My Takeaway

XNIDS is a strong paper because it connects three pieces that are often separated: deep NIDS detection, explainable AI, and active response.

Its central lesson is simple: a security model should not only say what it detected. It should help explain why, identify where response should apply, and produce a rule that is precise enough to avoid unnecessary damage.

For production systems, I would still want stronger robustness testing, more modern traffic datasets, and deployment measurements in high-throughput networks. But as a research direction, XNIDS points to the right shape of future NIDS: not just accurate models, but models that can explain themselves well enough to support careful automated action.