Designing a Unified Security Interaction Model at AWS Security Services

At cloud scale, fragmented security interfaces and inconsistent interaction models slow investigation, increase cognitive load, and allow complexity itself to become a source of risk.

This project focused on designing a unified security interaction model across AWS Security Hub, GuardDuty, Inspector, and Macie, enabling consistent triage, investigation, and reasoning about aggregated risk.

My Role

I am a core member of the AWS Security Services UX team. I own the interaction models and pattern libraries that define how security findings and aggregated risk are represented and reasoned about across all AWS Security products.

The System Problem: Unifying 4 Security Services

Security customers rely on multiple AWS services to understand different dimensions of risk in their environment: GuardDuty surfaces active threats, Inspector identifies vulnerabilities, Security Hub CSPM highlights misconfigurations, and Macie detects sensitive data risks.

As findings scale, security teams are required to mentally connect all these signals to understand overall security risk: which critical resources are exposed, how issues relate, and where to take actions first. When each security finding is delivered through an independent console and fragmented interaction model, customers struggled to understand, prioritize, and act on risk across services.

Security Hub, as the new AWS unified cloud security service, is aggregating all these security findings into one console. It also needed to unify how risk is understood and remediated, as unifying data alone was insufficient without a shared interaction model.

Interaction Model as Infrastructure

In this context, the interaction model itself became infrastructure. Unifying security services required a shared way to represent findings, and multiply the impact with their relationships, so security teams could reason about risk consistently across various signals.

My work focused on establishing common structures, patterns, and behaviors that translate complex security data into actionable understanding at scale.

In practice, this often meant pushing back on feature requests from individual service teams when proposed experience would break shared interaction patterns. I prioritized preserving a consistent investigation model across services, even when it required slower alignment and cross-team negotiation.

Designing the Finding Experience and Pattern Libraries

The finding experience is the core part of the unified interaction model user experience. Findings are the primary unit through which security teams triage risk, investigate issues, and decide next actions, yet each security service historically defined them differently.

User research revealed distinct needs across roles. Security analysts prioritized speed, density, and the ability to pivot quickly across related findings during investigation, while CISOs focused on high-level exposure, trends, and overall security posture.

These insights directly shaped how information was structured across the experience, from the finding header and findings table for rapid triage, to dashboards split between executive overview and analyst triage views.

I focused on standardizing how findings are structured and represented by defining a set of reusable interaction patterns, anchored by the finding detail panel. The finding detail was intentionally designed as a side panel rather than a modal or full-page view. For security analysts, investigation usually requires high information density, and involves rapid context switching across multiple findings. Keeping the primary list visible allowed analysts to preserve context awareness while drilling into details.

This pattern established consistent structure for context: overview, severity, status, evidence, impacted resources, and recommended remediation actions, enabling users to reason about findings without relearning each source. The pattern was shaped through 10+ user studies and multiple rounds of design iterations over 2 years, first launched in Security Hub CSPM and designed to scale across GuardDuty, Inspector, and Macie as a shared foundation.

The same model was extended to resource detail panels, and aggregated finding views, so that users could pivot from a finding to an impacted resource in a coherent workflow, without encountering a different interaction logic.

To support scale and consistency, I built “mini design systems” — patterns that were formalized into a couple of Security-focused pattern libraries built on top of the AWS Cloudscape design system, including the Finding Detail library, Resource Detail library, Finding List library, Dashboard library, etc.

Schema-Adaptive Design Framework

I initially designed the finding details pattern for four categories of findings (Vulnerability, Compliance, Threat, and Sensitive Data). As security finding types continued to scale, I realized that mapping each schema to bespoke UI quickly became unscalable.

To address this, I built a schema-adaptive design framework application using AI-assisted vibe-coding tools (VS Code, Cline, Figma MCP) to translate OCSF-aligned schemas into consistent UI patterns, automatically mapping data structures to hierarchy, grouping, and emphasis, treating schema-to-interaction mapping as a first-class design challenge.

This approach significantly simplified handoff with frontend engineers by enabling teams to generate UI directly from new schemas, reducing repetitive UX work and removing the need for bespoke new design. It also allowed faster exploration of pattern consistency and testing of edge cases across services.

The Aggregated Findings

Beyond individual findings, Security Hub helps security users understand how a primary resource or environment is exposed with Exposures, correlating groups of related findings (misconfigurations, vulnerabilities, threat, and sensitive data). My focus was on shaping how this exposure model is understood and used through interaction, specifically, how traits (e.g., reachability, vulnerability, assumability, etc.), contributing signals, and potential attack paths are surfaced together to support effective risk reasoning.

Building on the same vibe coding prototyping approach (along with an internal graph visualization library), I shaped the “potential attack path”, defining how impacted resources are connected, how users pivot into resource details, and how severity, traits, and contributing signals are surfaced to support more effective investigation.

In parallel, I helped clarify how the aggregated finding model relates to Amazon GuardDuty's attack sequence findings. While both aggregate multiple signals, attack sequences represent correlated threat behavior (network, runtime events, API activity, etc.) observed over time, gaining confidence of a true positive attack.

Unlike exposure, which aggregates conditions into a spatial view of relationships, attack sequences surface events in a linear timeline that emphasizes how correlated behaviors unfold. Making this distinction explicit ensured that threat timelines and exposure attack path each support different investigation needs without conflating interaction semantics.

Outcome: Standardization Through Interaction Patterns

To scale across services and teams, these interaction models were reinforced through standardized patterns rather than one-off designs. At the pattern level, I helped define the console interaction and information architecture structures (e.g., finding/exposure/resource detail panel), while components and atoms provided reusable building blocks such as containers, graphs, and other component clusters.

In-console surveys collected showed an 89% preference for the new finding interaction pattern for its usability, simplicity, and functionality. This pattern–component–atom structure ensured that new capabilities could be added without redefining how users reason about security risk, enabling the interaction pattern to generalize across security providers and platforms.

A key example is the entity pivoting pattern: users move from a summary page to a findings list, into finding details, and further into impacted resource detail panels. The underlying interaction model remains consistent across findings, exposures, and resources, allowing security teams to investigate risk without cognitive reset.

The interaction pattern also proved adaptable with business impact. Building on the same foundation, teams were able to introduce new capabilities, such as ticket creation integrations, MITRE ATT&CK tactic mapping, and finding history, without reworking the interaction model. These additions fit naturally into the existing finding structure as Security Hub evolved. In many cases, service engineering teams could apply these patterns directly without requiring bespoke, pixel-perfect design specifications.

This unified interaction was showcased as a five-minute Security Hub demo at AWS re:Inforce 2025 opening keynote, illustrating how AWS envisions security teams reasoning about aggregated risk across services through a single-pane-of-glass coherent system.