Furkan Barış — machine learning for network security

Hello, world

Sun, 30 Aug 2026 00:00:00 GMT

I have spent the last two years training models on security data — network captures from medical devices, phishing URLs, documents fed into a retrieval system. Most of what I learned in that time never made it out of a notebook or a thesis draft. This site is where I fix that.

What goes here

Three kinds of posts, roughly:

Working notes. The thing I tried, the number it produced, and whether I believed the number. Failed experiments count — they are usually the more useful half.
Explanations. Methods I had to read three papers to understand, written the way I wish someone had written them for me.
Build logs. Shipping a RAG platform to production taught me more about retrieval than any benchmark did. That kind of thing.

What will not be here: tutorials rewritten from documentation, or benchmark numbers without the setup that produced them.

On numbers

Every accuracy figure I publish comes with the dataset, the split, and the class balance. This matters more in security than almost anywhere else, because the interesting class is always the rare one:

# An "accurate" model on a realistic intrusion dataset.
attacks = 1_000
benign  = 99_000

predict_benign_always = benign / (benign + attacks)
print(f"{predict_benign_always:.3f}")  # 0.990 — and it catches nothing

Ninety-nine percent accuracy, zero detections. So when I write down 0.97, I will also write down what it was measured against, and what it looked like on the minority class.

Elsewhere

The code behind most of what I write about is on GitHub. If something here is wrong or unclear, my inbox is open — the address is on the about page.

One-class detection for IoMT network traffic

Mon, 24 Aug 2026 00:00:00 GMT

Internet of Medical Things networks have a property that makes supervised intrusion detection awkward: you can collect as much normal traffic as you like, and almost none of the other kind. An infusion pump talking to a monitoring server produces the same handful of patterns for months. The attack you actually care about has not happened yet — and when it does, it will probably not look like anything in your training set.

This is the setting for my thesis, and it pushed me away from classification and toward one-class modelling.

Why not just train a classifier

The obvious approach is to label traffic as benign or malicious and train a binary classifier. Two things go wrong.

The first is arithmetic. Attack traffic is rare, so accuracy stops meaning anything — a model that predicts “benign” for everything scores well and detects nothing. I wrote about that in the first post on this site.

The second is worse. A supervised model learns the boundary between the normal traffic you have and the specific attacks you have. Deploy it against a technique that was not in the training set and it has no reason to flag anything. You have built a detector for yesterday’s attacks.

One-class models invert the question. Instead of learning what an attack looks like, they learn a tight boundary around normal behaviour and treat everything outside it as suspicious. You never have to enumerate the attacks. That fits the data you can actually collect from a hospital network.

Turning flows into small images

I used DROCC — Deep Robust One-Class Classification — with a convolutional backbone, which means the model wants something image-shaped as input. Network flow records are not image-shaped; they are a row of numbers.

So each flow’s 36 features get reshaped into a 6×6 single-channel grid and treated as a tiny grayscale image. Convolution then sees small neighbourhoods of features at once rather than one long flat vector.

This is a real modelling decision, not just plumbing: a convolution over a 6×6 grid only ever mixes features that ended up adjacent, so the ordering of the columns matters. Features that belong together should sit together. It is the part of the pipeline I would poke at first if the numbers were disappointing.

The collapse problem

One-class objectives have an obvious degenerate solution. If the only instruction is “map normal data somewhere consistent”, the network can satisfy it by mapping everything — normal traffic, attacks, random noise — to a single point. Loss goes to zero. The model has learned nothing. This is representation collapse, and it is the reason naive one-class training often produces something that looks trained and detects nothing.

DROCC’s answer is to make the trivial solution impossible. It assumes normal points lie on a locally linear, low-dimensional manifold, then generates adversarial negative points by gradient ascent in a shell just outside each training point — close enough to be plausible, far enough to be wrong. The model is trained to separate real points from those synthetic near-misses.

A constant function cannot do that. To push the fake points away while keeping the real ones, the boundary has to actually hug the shape of normal traffic. That is the mechanism, and it is what makes the approach work at all rather than just appear to.

Results

Two public datasets, one from IoMT device traffic and one from a healthcare monitoring testbed:

Dataset	Domain	Accuracy
CIC-IoMT-2024	IoMT device traffic	0.92
WUSTL-EHMS-2020	Healthcare monitoring system	0.97

The gap between the two is the interesting part. WUSTL-EHMS-2020 comes from a smaller, more constrained testbed, so “normal” is a tighter target and the boundary can be drawn closer around it. CIC-IoMT-2024 covers a wider variety of devices and behaviours, so normal is a bigger, messier region — and a bigger region is harder to wrap tightly without letting attacks inside it.

That is the general shape of the tradeoff in one-class detection. The more varied your normal traffic, the looser your boundary, and the more attacks slip through it.

What I would want next

Accuracy is the headline number, but it is not the number that decides whether a detector is deployable. For an intrusion detection system what matters is the false positive rate at a useful detection rate — a model that flags 3% of a hospital’s normal traffic is switched off in a week, whatever its accuracy is. A full ROC curve, and per-attack-family recall, would say much more than a single figure.

Code: github.com/ffurkanbaris/anomaly-detection

Three branches and an attention layer: QR phishing detection

Tue, 18 Aug 2026 00:00:00 GMT

A malicious QR code hides its URL behind a picture. That is the whole problem. A phishing link in an email can be read, hovered over, and doubted before it is clicked; the same link inside a QR code is a grid of squares until a phone has already decoded it and opened the page. The usual defence — look at where it goes before you go there — is gone.

So the detector has to work on what is available before the user commits. The question I wanted to answer was where that signal actually lives: in the URL string, in the structure of the code itself, or in the relationship between the two.

Three branches

The answer I settled on was to not choose. PhishFusion runs three encoders in parallel, one per view of the same object:

Branch	Input	Encoder
Lexical	URL character sequence	Transformer encoder
URL	Structural URL features	MLP
QR	QR structural features	MLP

The lexical branch reads the URL as a character sequence. This is where the classic phishing tells live — brand names spliced into subdomains, character substitutions, absurd path depth, hyphen soup. A Transformer suits it because those patterns are positional and contextual: paypal early in a hostname means something different from paypal buried in a path segment, and self-attention can represent that distinction directly.

The two structural branches are deliberately not sequence models. They take engineered features — counts, lengths, ratios, encoding properties — and an MLP is the right tool for a fixed-width feature vector. Handing those to a Transformer would be architecture for its own sake.

Each branch emits a 32-dimensional embedding. Three views, one common width.

Why attention instead of concatenation

The cheap way to combine three embeddings is to glue them into a 96-dimensional vector and put a classifier on top. That works, and it is the baseline any fusion model has to beat.

What it cannot do is weight the branches per sample. Concatenation learns one fixed set of weights over the three views and applies it to every input. But the views are not equally informative for every URL. A shortened link is lexically almost empty — there is nothing to read, which is itself the signal — and the structural branches have to carry the decision. A long, hand-crafted lookalike hostname is the opposite case: the lexical branch has plenty to work with.

Cross-modal attention across the three 32-dimensional embeddings lets each branch attend to the others, so the model can learn conditional relationships — a suspicious QR structure matters more when the URL is also unusual, and an unremarkable URL is less reassuring when the code it came from is malformed. The weighting is computed from the input rather than fixed at training time.

That interaction is the actual claim of the architecture. Whether it earns its complexity is an empirical question, and the honest way to answer it is single-branch and concatenation baselines measured on the same split.

Results

0.96 binary classification accuracy on an imbalanced phishing dataset.

The word doing the work in that sentence is imbalanced, and it is worth being blunt about what the number therefore does not tell you. On a skewed set, accuracy is dominated by the majority class; a model can look strong while missing a large share of the phishing it was built to catch. Precision and recall on the phishing class are the figures that decide whether the thing is useful, and they are what I would put in front of the accuracy if I were presenting this as a deployable system rather than a study.

I am stating the metric I measured, not the metric I wish I had measured. That distinction seems worth keeping.

What the setup does not cover

Two limits worth naming. The model sees a decoded URL plus structural features — it never sees the page, so a phishing site that hides behind a clean-looking domain and a redirect chain is out of scope. And QR phishing in the wild is largely a physical-world attack: stickers over legitimate codes on parking meters, restaurant tables, EV chargers. None of the context that makes those convincing is in the dataset.

A detector like this belongs in the layer that inspects a link before the browser follows it, not as the last line of defence.

Code: github.com/ffurkanbaris/phishfusion