Predicting cyber threats before they happen, with reinforcement learning. A BMBF- and BSI-funded research program at GT-ARC, TU Berlin (2019 to 2024).
Industry
Cybersecurity
Responsibilities
Sole UX/UI designer, 2019 to 2024. Users and objectives, information architecture, interaction, visual design, design system. My part was the product; the model was the research team’s.
01 · Problem and solution
Reading an attack before it happens
Most security tools tell you what just happened. A security team reads the alert after the damage, and the attacker has already moved on to the next host.
Cosy computes the attack paths most likely to be taken next across IoT and Industry 4.0 infrastructure. My job was turning that output into something a security team can read in seconds and act on.
02 · Process
Designing in a research setting
Cosy started as a research project, not a product brief. The team's open-ended question was: how effectively can machine learning be used to detect and defend against cyberattacks early? Without a defined end-user, structured thinking became the primary design tool.
There was no design spec. Nothing was written down for me to build against. The requirements came out of sitting with the engineers and working out together which of the model's outputs a person could actually use: which data points had to surface at all, and what shape each one needed to take on screen. That translation — from the team's abstract concepts to something concrete enough to build — was most of the design work here.
Working with the model's researchers, I built two personas from their domain hypotheses, and checked them with the person who defends our own institute's servers, after a real attack. They decided the information architecture.
User personas
Two people, one screen
The administrator
Defends the infrastructure, day to day
Scenario
An alert comes in at 09:20. The call has to be made within minutes: is this the beginning of a path the model has already seen, or is it noise?
Goals
Know which attack path the model expects next
Act before it happens, not after
Keep the model honest when it is wrong
Motivation
Wants the reasoning, not just the verdict
Trusts a number that comes with its track record
Would rather simulate than guess
Challenges
Twelve cards of signal, one screen
In 2019 there was no convention for showing confidence
Overruling the model has to feel like feedback, not like a dismissal
The IT manager
Owns the risk, not the terminal
Scenario
Monday morning, fifteen minutes before a management meeting. One sentence is needed about where the infrastructure stands.
Goals
Know whether today is worse than last week
Decide whether this needs attention at all
Be able to say it out loud in one sentence
Motivation
Wants the state, not the investigation
Reads a trend faster than a table
Escalates early when the direction is clear
Challenges
A raw risk score means nothing without a delta
No time to read twelve cards
Has to trust a system they do not operate themselves
The decision that follows
Same model output, different density, different primary action. One screen serves both,
read to different depths, instead of two products.
From input to explainable output
03 · Designing for the AI
Making a complex model legible
The number at the top does the work. 156 means little on its own; +8.1 per cent week over week is something you can act on. Underneath it, up to twelve cards carry the investigation: CVSS distribution, vulnerable hosts over time, cluster and node topology, running investigations, mitigation status.
Two tabs of the same overview: infrastructure state on the left, feature-level activity on the right.
The model output is the dashboard. Risk score, predicted paths and vulnerabilities are not AI features placed next to a dashboard. Designing for AI here meant designing the information architecture first, then putting the model output where it belonged.
The reasoning chain on the real screen: what the model saw, the pattern it matched, the competing explanations with their odds, the confidence next to its track record, and the way to disagree. Below 40 per cent it says it does not know instead of forcing a classification.
Colour is reserved for risk. Confidence stays a plain number with its track record next to it, so a confident low-risk call never looks like a high-risk one.
The three principles
Prediction, not detection. The UI shows what may still happen, with confidence, expected timing and uncertainty attached to every call.
Trust has to be checkable. Nothing the model says arrives alone: the competing explanations come with it, and the analyst decides how much weight the answer gets.
The analyst is part of the system. An override is recorded as feedback, so the model gets sharper every time an analyst disagrees with it.
04 · Design system
A system behind the screens
Risk is the only thing colour is allowed to mean. Everything else — brand, interactive states, the type scale, the grid — had to get out of its way.
Outcome
Shipped as working software
Plus a public dataset as a research output of the programme.
Continued as COBRA-5G
A BSI-funded successor applied the approach to 5G campus networks, with GT-ARC contributing the real-world lab. My design work spans both phases.
Taken forward as a product
The team explored the prototype as the basis for a product for data-centre administrators.
05 · Challenges & reflections
What I'd do differently
Domain knowledge. I learned cybersecurity vocabulary, threat models and 5G architecture while designing. I would now invest more upfront, not as a prerequisite, but so I could push back on technical decisions earlier.
AI-native design was still emerging. In 2019 there were no conventions for confidence display, uncertainty, or reasoning chains. I decided case by case. Looking back, I would make the model's uncertainty more explicit, and give analysts more direct ways to challenge it.
