IDS-ML: A Notebook Repository for Building Intrusion Detection Models on CICIDS2017 and CAN Data

Three Papers, One Notebook Tree, and the Audience It Actually Serves

The repository exists to publish the code behind three peer-reviewed papers from the Western OC2 Lab: a tree-based IDS for Internet of Vehicles (GLOBECOM 2019), MTH-IDS (IEEE Internet of Things Journal, 2022), and LCCDE (GLOBECOM 2022). A fourth citation, in Software Impacts, describes the repository itself as an open source code release for IDS development using machine learning. So the organising unit here is the paper, not the product. Each notebook tree reproduces the experiments of one publication.

The problem it addresses is reproducible baseline construction. Intrusion detection papers are notoriously hard to compare because preprocessing choices (which CICIDS2017 CSV files, how labels are collapsed into classes, how duplicates are removed) move reported accuracy by more than the choice of classifier does. By releasing the preprocessing alongside the models, this repository lets a reader start from the same feature matrices the authors used rather than reconstructing them from a methods paragraph.

The audience is narrow and identifiable: graduate students and researchers working on machine learning for network intrusion detection, particularly in vehicular and IoT settings. The topics list (cicids2017, autonomous-vehicles, hpo, stacking) maps onto that audience precisely. A security operations engineer looking for something to install on a span port will find nothing here.

What MTH-IDS Does in Four Tiers, and Why the Tiering Matters

MTH-IDS is the most architecturally interesting of the three systems, and the README spells out its structure. It combines a signature-based IDS with an anomaly-based IDS across four learning tiers plus two traditional ML stages (data preprocessing and feature engineering).

Tier one runs four supervised tree learners as multi-class classifiers for known attacks: decision tree, random forest, extra trees and XGBoost. Tier two adds a stacking ensemble and applies Bayesian optimization with a tree Parzen estimator (BO-TPE) to tune the supervised learners. Tier three switches to unsupervised learning: cluster labeling k-means, used for zero-day attack detection. Tier four adds two biased classifiers and tunes the unsupervised stage with Bayesian optimization using a Gaussian process (BO-GP).

The design logic is that known attacks are a supervised classification problem while unknown attacks are not, and the two need different machinery. That is a reasonable split, and it is the reason the repository ships both a supervised stack and a k-means path rather than one model. The cost is operational complexity: four tiers, two optimizers, and a cluster labeling step that has to assign semantic meaning to clusters before they can be reported as attack types. The README does not describe how cluster-to-attack mapping is validated, which is the part of any zero-day pipeline most likely to produce misleading results. Treat that as an open question in the code rather than a solved problem.

Datasets and the Evaluation Boundary

The papers evaluate on two datasets named in the README: the CAN-intrusion-dataset, representing intra-vehicle network data, and CICIDS2017, representing external vehicular network traffic. The repository topics confirm cicids2017 as a first-class target. Both are public benchmarks, which is a strength for comparison and a limitation for anyone extrapolating to a live network.

CICIDS2017 is flow-based, generated in a lab testbed, and its class distribution is heavily skewed toward benign traffic with a handful of large attack classes and several very small ones. The README does not state how the notebooks handle that imbalance, and it does not report per-class metrics in the repository text. If you plan to reuse the code, the class distribution and the label collapsing logic in the preprocessing cells are the first things to inspect, because those decisions determine what a headline detection rate means.

The CAN-intrusion-dataset is a different animal: CAN bus frames are fixed-format and low-dimensional compared with flow features, so a model that performs well there says little about performance on IP flow data, and vice versa. The repository treats them as two evaluation settings rather than one, which is the honest framing. Anyone quoting a single number across both should be asked which dataset it came from.

Running the Notebooks: Environment, Dependencies and the Absence of a Pipeline

The primary language is Jupyter Notebook, so the execution model is cell-by-cell rather than a packaged CLI. The README does not document an installation section, a requirements file, or a single entry-point command. What it does document is the algorithm inventory: decision tree, random forest, extra trees, XGBoost, LightGBM, CatBoost, k-means, stacking, the proposed LCCDE, and Bayesian optimization.

That inventory implies the dependency set you will need to assemble yourself: scikit-learn for the tree learners, k-means and stacking, plus xgboost, lightgbm and catboost as separate packages, and a Bayesian optimization library (the papers use tree Parzen estimator and Gaussian process variants, which are the two acquisition strategies implemented by common HPO libraries). The README does not pin versions, so expect to resolve version drift between the notebook code and current releases of those gradient boosting packages. That is a real cost: XGBoost and LightGBM have both changed default parameters and API details across major versions, and a notebook written against an older release may need edits before it runs.

The second dependency is data. Since no download script is described in the supplied material, you should expect to obtain CICIDS2017 and the CAN-intrusion-dataset yourself and place them where the notebooks expect. Check the path constants near the top of each notebook before running anything, because those are the values you will need to edit.

The repository is not archived and the last push is dated 2026-04-01, so it is receiving maintenance. There are no tagged releases in the material provided, which means you consume the default branch rather than a versioned artifact. For a research reproduction that is acceptable; for anything you intend to cite years from now, record the commit hash you ran.

Where the Repository Stops: No Capture, No Streaming, No Deployment

This is the limitation that matters most, and it is structural rather than a bug. Nothing in the README describes packet capture, flow generation, a message queue, a REST endpoint, or a container image. The notebooks consume pre-extracted feature CSVs. That means the repository covers the modelling half of an IDS and none of the operational half.

Concretely, if you wanted to detect attacks on a live network, you would still need to solve: capturing traffic or reading CAN frames, converting them into the exact feature schema the models were trained on, applying the same scaling and encoding, and serving predictions with acceptable latency. CICIDS2017 features come from a flow exporter (the README does not name one), so feature parity between your live pipeline and the training data is a nontrivial engineering problem that the repository does not address.

The second limitation is evaluation scope. The models are trained and tested on benchmark datasets collected in controlled settings. Performance on those datasets does not transfer automatically to production traffic, where the attack mix, background noise and traffic volume differ. The README itself frames the models as general models usable in any IDS and anomaly detection application, which is a statement about the learning methods, not a claim about deployed detection rates.

The third is the zero-day path. K-means with cluster labeling requires a human or heuristic step to decide what each cluster means. Without that step, an anomaly score is just a number. The README describes the mechanism but not the labelling procedure, so budget time for that yourself.

How It Compares to a Signature Engine and to the CNN Sibling Repo

The obvious alternative for known-attack detection is a signature engine such as Snort or Suricata. The difference in approach is fundamental. A signature engine matches observed traffic against hand-written rules for attacks someone has already characterised; it produces named alerts with essentially no training data, and it cannot detect an attack nobody has written a rule for. The MTH-IDS design inverts this: the supervised tiers learn attack classes from labelled examples and the k-means tier is meant to flag traffic that does not resemble anything seen in training. In exchange for that coverage, you take on dataset dependency, retraining when traffic shifts, and the risk of false positives on legitimate traffic that happens to sit outside the training distribution. A signature engine has no such drift problem but is blind to novel attacks. The two are complementary, which is exactly why MTH-IDS is described as hybrid rather than as a replacement.

The closer comparison is within the same lab. The README points to a sibling repository, Intrusion-Detection-System-Using-CNN-and-Transfer-Learning, which approaches the same problem with convolutional neural networks and transfer learning. The difference is representational: the tree and ensemble methods here operate on engineered tabular features, while the CNN path learns from a reshaped input representation and can reuse weights across related tasks. If your features are already tabular and your dataset is modest, the tree ensembles in this repository are the more direct fit. If you have image-like or sequence-structured inputs and limited labelled data in the target domain, the transfer learning route is the one to evaluate. A third reference the README cites, the Hyperparameter-Optimization-of-Machine-Learning-Algorithms tutorial, is worth knowing about if the BO-TPE and BO-GP cells are the part you care about, since that repository treats tuning as the subject rather than as one tier of a larger system.

Licence, Maintenance and the Cost of Keeping It Running

The licence is MIT, which is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained. That makes the code straightforward to reuse inside academic work or a commercial prototype. It does not settle anything about the datasets, which carry their own terms from their original publishers and are not distributed here. Check those separately before publishing derived data. Nothing in this paragraph is legal advice; read the licence text and the dataset terms yourself.

Maintenance cost is mostly dependency drift. The notebooks depend on a stack of fast-moving gradient boosting libraries, and no version pins are documented in the supplied material. Every time you return to the code after a gap, expect to spend time on import errors and changed default parameters before you get back to the modelling question you actually care about. The repository is active (last push 2026-04-01) but has no tagged releases, so there is no stable snapshot to pin against. Recording the commit hash with your results is the cheapest mitigation available.

The other recurring cost is data plumbing. Because the notebooks read pre-extracted CSVs, any change to your feature extraction means re-deriving the training matrices and re-running preprocessing, not just retraining a model. Plan for that as a per-dataset cost rather than a one-time setup.

Editorial conclusion

Adopt this if you are a graduate student or researcher who needs a working baseline on CICIDS2017 or the CAN-intrusion-dataset and wants the exact preprocessing the published papers used. Do not adopt it if you need a running network sensor: there is no packet capture, no streaming path and no deployment artifact in the repository. Before building on it, confirm which notebook corresponds to which paper, check that the dataset download links still resolve, and read the class-label mapping in the preprocessing cells, because that mapping is what your reported detection rates will actually depend on.

Official sources

1. Issues
2. License: MIT
3. README
4. Western-OC2-Lab/Intrusion-Detection-System-Using-Machine-Learning on GitHub