YUNYAO Get in touch

AI-Powered Cybersecurity for Threat Prediction

Predicting cyber threats before they happen, with game-theoretic AI. A BMBF- and BSI-funded research program at GT-ARC, TU Berlin (2019 to 2024).

Industry
Cybersecurity
Responsibilities
As the sole UX/UI expert, I collaborated with the technical team to structure existing technologies and concepts, define the app’s target users and objectives, and outline its key features and user flow. A central part of my contribution was turning the team’s abstract concepts into concrete designs: identifying which data points the model needed to surface, and deciding how they should be represented so that users could understand the system quickly and act on it efficiently.
An analyst reviewing the Cosy prediction dashboard on a monitor

Most security tools tell you what just happened. Cosy tells you what is likely to happen next.

Cosy infrastructure overview: current risk, hosts, vulnerabilities, nodes, and trend

Cosy is a research cybersecurity system that uses a Reinforcement Learning agent and game-theoretic models to predict potential attack paths before they unfold. The project was developed at GT-ARC, TU Berlin, funded by the Bundesministerium für Bildung und Forschung (BMBF) from April 2019 to December 2022, and continued through BSI-funded COBRA-5G from June 2023 to November 2024.

01 · 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.

At its technical core, the project combined AI and game theory to predict cyber threats and to compute optimal response strategies for IoT and Industry 4.0 cyber-physical systems. My role was to translate that technical work into an interface that an analyst or manager could actually use.

Working with the project's machine-learning researchers, I built two personas on the back of their domain hypotheses about who would adopt such a tool: an administrator (deep technical context, needs to investigate and act) and an IT manager (oversight role, needs the situation at a glance). Treating domain experts as proxy users is not a substitute for full user research, but in a research phase with no production user, it was the appropriate approach.

The personas drove every information-architecture decision that followed: same model output, different information density, different primary actions. The result was a set of linked dashboards designed so each persona could open Cosy and see what their role needs to know.

A second core part of my role was making the concept concrete. At the start of the project, the proposition existed largely in technical terms: a reinforcement-learning agent producing risk signals that needed to become an interface. I worked with the team to identify which data points the model would actually surface, and to define how each one should be visualized so that an administrator or manager could read the system quickly and act on it without ambiguity.

From input to explainable output: demo, threat actor, simulation, prediction — and the actual screens behind each step

System administrators typically have to manually manage security processes and check for vulnerabilities, a time-consuming task prone to human error.

The app provides administrators with a comprehensive overview of the system and its infrastructure. Automated security assessments continuously detect and display new vulnerabilities or alerts. Additionally, administrators can simulate attack scenarios based on detected vulnerabilities to identify potential system weaknesses. These simulations can be initiated manually or triggered by alerts, optimizing efficiency and saving time. The app also offers predictive insights, allowing administrators to review forecasted attack paths and risks.

02 · Designing for the AI

Making a complex model legible

The central design problem in Cosy was rendering the output of a complex machine-learning model legible at the appropriate level of detail for two very different user roles.

Risk score paired with directional change. The model produces a continuous risk score. In the manager view, the score is paired with a trend indicator: the current value and the percent change since the previous period. This pairing is deliberate, since manager-level decisions are typically made on the change rather than on the snapshot. A score of 156 in isolation conveys little, while a +8.1% week-over-week shift is actionable.

To keep these two readings from blurring, risk is carried by color and confidence stays a plain number paired with its track record. Two questions, two channels.

Risk uses color, confidence stays numeric and paired with its track record
Two channels: color carries risk; confidence stays a number, paired with the model's track record on similar cases.

Information density adapted to the user role. For administrators, the same model output decomposes across a dashboard of up to twelve cards: CVSS-score distribution, vulnerable hosts over time, cluster visualization (pods, servers, ingress paths), node topology (sensors, cameras, routers, switches), triggered investigations, alarm assessments, and mitigation status. Administrators investigate the detailed breakdown, while managers work with the consolidated overview.

The administrator view (left) holds dense, investigable detail; the manager view (right) consolidates the same data to a glance
The same model output, decomposed two ways: the administrator view (left) holds dense, investigable detail; the manager view (right) consolidates the same data to a glance.

Model output integrated into the information architecture. The risk score, predicted attack paths, and detected vulnerabilities are not isolated "AI features" placed alongside a dashboard. They constitute the dashboard itself. Designing for AI in this context meant designing the information architecture first, and then placing the model output where it structurally belonged.

One reasoning chain shown consistently wherever the model makes a call
One reasoning chain, shown consistently wherever the model makes a call: what it sees, what it matched, what else it could be, how sure it is, and how to override it.
What "designing for AI" actually means here
  1. Prediction, not detection. The UI communicates possibilities, not just events. Every prediction comes with confidence, expected timing, and uncertainty.
  2. Trust is earned, not assumed. The model's track record and competing explanations are visible alongside the answer. The analyst is given the ingredients to calibrate trust, not asked to grant it.
  3. The analyst is part of the system. Overrides aren't dismissals; they are feedback. The AI gets smarter when analysts disagree with it.
03 · Design system

A system behind the screens

To keep the dashboards consistent across two roles and many views, I consolidated the design into a token set and a component library, with color split by job (risk vs brand vs interactive), type, spacing, and a shared set of components so the same model output always reads the same way.

Cosy design system: tokens and the component library that uses them
04 · Outcomes

From prototype to a continued research program

Cosy delivered a functional, operational software product, alongside a public dataset released as a research output. After the research phase, the team began commercial outreach, exploring the prototype as the basis for a productized offering for IT administrators in data centers.

The research line was then continued at scale. In June 2023, the same approach was extended in COBRA-5G (Container-based Resilient Architecture for 5G Campus Networks), a successor program funded by the Bundesamt für Sicherheit in der Informationstechnik (BSI) through November 2024. COBRA-5G applied the COSY approach to 5G campus networks, with a containerised architecture, OpenRAN integration, and the detection of jamming and network attacks. GT-ARC contributed the real-world laboratory in a Berlin-based autonomous-mobility infrastructure. My design work spans both phases of the line, from the initial COSY prototype to the COBRA-5G extension.

Being chosen by a second federal funder, and a different one (from BMBF to BSI), is the strongest validation a research-phase prototype can receive. It meant the design direction we set held up under independent review.

05 · Challenges & reflections

What I'd do differently

Domain knowledge. Joining a technical research team, I had to learn cybersecurity vocabulary, threat models, and 5G architecture in parallel with designing. In retrospect, I would invest more upfront in learning the domain deeply before proposing solutions, not because it is a prerequisite, but because it would have let me push back on technical decisions with more confidence.

AI-native design was still emerging. When the project started in 2019, "designing for AI" was not yet a discipline. Patterns like confidence display, uncertainty surfacing, and reasoning chains were not yet conventions. I made decisions case by case, sometimes well, sometimes in ways I would revise now. Looking back, I can see places where I could have made the model's uncertainty more explicit, and where I could have given analysts more direct ways to challenge the model.

Limited end-user access. As a research project, we worked primarily through domain-expert proxies rather than real security analysts. That was the right call given the constraints, but it left gaps in my understanding of operational workflows that I would want to close in a productized context.