Network Intrusion Detection with CICIDS2017 (Monday baseline vs Tuesday brute-force traffic)

1.

MIDTERM PROJECT • NETWORK SECURITY
Scope
Network Intrusion Detection
with CICIDS2017
Monday baseline vs Tuesday brute-force
traffic
Monday + Tuesday
Data
CSV flow logs + optional PCAP
context
Output
cleaning summary • EDA
model comparison
A compact, defensible workflow:
clean the flow logs, visualize the traffic, then compare
anomaly detection with a supervised baseline.
Design • Code • Defense
Team placeholders: Student 1 • Student 2 • Student 3

2.

Why CICIDS2017 works for this midterm
5 days
02 / 10
Monday
Normal-only day → the cleanest baseline for “what
good traffic looks like.”
Tuesday
Normal traffic + FTP brute-force + SSH brute-force → a
focused first attack scenario.
captured Monday–Friday
Realistic enterprise-style background traffic plus attack
windows.
80+
flow features
Enough signal for traffic analysis, anomaly detection, and
supervised learning.
PCAP + CSV
two levels of evidence
You can model the CSVs and still discuss raw packet
capture if asked.
Wed–Thu DoS, Heartbleed, Web Attack, and Infiltration → good
extensions for future work.
Friday
Bot, PortScan, and DDoS → broader attack families
after the midterm scope.
Our live defense is easier if we keep the story tight: learn normal
behavior on Monday, then test whether the pipeline separates benign
from Tuesday’s brute-force traffic.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)

3.

Data audit and cleaning outcomes
03 / 10
5.1%
5.4%
9,152
Monday duplicates removed
Tuesday duplicates removed
Tuesday attacks after cleaning
26,935 rows removed from 529,918 raw flows.
24,065 rows removed from 445,909 raw flows.
The positive class is still present for testing.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)

4.

What the traffic tells us before modeling
04 / 10
Key
interpretation
• The combined cleaned set is almost all benign (about 99.0%), so accuracy alone will overstate model quality.
• Tuesday’s raw attack labels concentrate into FTP-Patator and SSH-Patator, which makes the scenario easy to explain during
the defense.
• We also observed INF values in Flow Bytes/s, so cleaning is a real modeling step—not a formality.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)

5.

Detection pipeline: one anomaly path, one
supervised path
Monday
baseline
benign-only flows
used to learn normal
behavior
Preprocess
strip spaces
replace INF
keep numeric features
05 / 10
Isolation
Forest
Tuesday
evaluation
unsupervised
anomaly detector
421,844 cleaned flows
412,692 benign / 9,152 attack
Why this design is defensible
Monday is officially the normal-only day, so the
anomaly model has a clear baseline. Tuesday then
introduces a narrow attack family (FTP/SSH brute
force) without changing the dataset ecosystem.
Combined
cleaned data
Train / test split
Random Forest
Artifacts
Monday + Tuesday
with binary attack labels
70/30 split
stratified by label
supervised baseline
for known attack labels
metrics.txt
confusion matrix
feature importance
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)

6.

Isolation Forest result: high accuracy, zero attack
recovery
06 / 10
92.38%
0.00
accuracy
precision
0.00
0.00
recall
F1-score
What this means
• The model marked some Tuesday flows as anomalous, but
none of the true attacks were recovered.
• Class imbalance kept accuracy high because most flows
were benign.
• This is exactly why the defense should emphasize recall,
precision, and class balance—not accuracy alone.
train rows 200,000 • test rows 421,844 • features 78 • contamination 0.05
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)

7.

Why we keep both models in the story
Unsupervised path
Isolation Forest
• Needs only normal traffic for training.
• Good story for unknown or novel behavior.
• Struggled here because Tuesday brute-force
flows still looked close to benign short
connections.
Supervised path
Random Forest
baseline
• Uses the labeled Monday + Tuesday data.
• Gives a practical benchmark for known attack
families.
• Your local run already produced metrics, a
confusion matrix, and a feature-importance
plot for the live demo.
Defense message
A mature IDS workflow rarely bets on one model. Unsupervised detection helps surface unknown behavior;
supervised learning is stronger when the attack family is already labeled. That comparison itself is a design
strength.
For the live defense, open outputs/metrics/random_forest_metrics.txt on your laptop and read the exact values aloud if the instructor asks for them.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)
07 / 10

8.

Security recommendations from the scoped
Tuesday scenario
01 Apply rate limiting, account lockout rules, and MFA on
Protect authentication services
SSH/FTP-facing services—especially where repeated
login attempts are visible.
per-service flow stats
02 Baseline
Track flow duration, packets/s, and bytes/s by service
so unusual bursts stand out before analysts inspect raw
packets.
03 Brute-force traffic often appears as repeated connection
Alert on repeated auth bursts
attempts to the same service. Even if payloads are not
inspected, flow repetition is a strong signal.
unnecessary exposure
04 Reduce
Segment sensitive services and disable unused
protocols. The easiest attack to detect is the one that
cannot reach the service at all.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)
08 / 10
Operational takeaway
This scoped demo is not about
volumetric DoS or malware beaconing.
It is an authentication-focused threat
story, so the recommendations should
stay tightly connected to access
control and traffic baselining.
Why the recommendations are
credible
They are tied directly to the Tuesday
attack family (FTP-Patator and SSHPatator), rather than generic “secure
everything” advice.

9.

Likely live-defense questions — and the answers to
practice
Q Why train on Monday?
Because the official dataset description marks Monday as the
normal-only day, making it the cleanest baseline for benign
behavior.
Q Why is accuracy misleading here?
Attacks are under 1% of the combined cleaned data. A model
can look “accurate” while still failing to recover the positives.
Q Why keep Random Forest if Isolation Forest
already ran?
It provides a labeled benchmark. Comparing unsupervised vs
supervised detection is itself a strong design choice.
Practice tip
Q What caused weak recall in Isolation Forest?
Brute-force flows can still resemble normal short-lived
connections when you look only at aggregated flow statistics.
Q What are the main limitations?
Only Monday and Tuesday were used in the scoped demo,
and the core pipeline is flow-based rather than packet-deep.
Q What would you improve next?
Tune thresholds, test on more attack days, select features
more aggressively, and validate suspicious flows with PCAP
inspection.
Each teammate should be able to explain the dataset choice, the cleaning logic, the class imbalance
problem, and the difference between anomaly detection and supervised classification.
Network Security Midterm • CICIDS2017 (Monday + Tuesday scope)
09 / 10

10.

KEY TAKEAWAY
CICIDS2017 let us model normal traffic first,
then test whether our pipeline could
separate
benign from Tuesday’s brute-force activity.
Thank you — ready for questions
Bring the local outputs/metrics folder to the defense so you can reference the exact Random
Forest numbers if asked.
1
clean the logs
2
visualize the traffic
3
compare models
4
defend the choices