Attack Simulation showed how an attacker could move through a cloud environment. But analysts also needed to investigate from other starting points: an exposed identity, an account at risk, a critical asset, or a third-party connection.
The challenge was to give them those different views while keeping each one connected to the underlying attack scenarios.
Attack Simulation had been built before I joined. I improved its layout and security context, then designed the supporting views that let users investigate the same attack data from different starting points.
Cloud security analysts investigating exposure, understanding possible attack paths, and deciding what to fix.
An analyst could start with a question about an account or identity, then open the related attack scenarios to understand the wider context.
We aimed to understand how investigators think and work.
Shows how an attacker could move from one cloud account to another.
I worked on both list and graph views. The graph helped explain the relationships between accounts, while the list supported reviewing and comparing individual connections.
How users investigate at-risk source and target accounts, trace attack paths, and identify fixes.
See which source accounts could give an attacker access to target accounts, with attack scenario counts for each connection.
See how those connections fit together, with directional paths showing how a compromised account could put others at risk.
Explore how an attacker could move between the selected accounts, with attack paths showing the steps and potential impact.
Review recommended policy and permission changes, and generate ready-to-use scripts to reduce the related attack scenarios. Both side panels are accessible from the list and graph views.
This view focuses on exposed admin targets and how an attacker could use their privileges to reach critical assets. Admin access has a wider reach than a regular user’s access, making it a valuable target for attackers.
Users can review targets by takeover type, such as Organization Admin, Global Admin, or Account Admin, then explore the related attack scenarios and paths to understand what could be reached.
The view also connects these risks to recommended fixes and policy remediation. Users can review the proposed changes and generate scripts to run in their cloud environment.
Each remediation action opens in a side panel with a plain-language explanation of what to change and where. I worked with Engineering and Research to make the guidance easier to understand, keeping technical details available when needed.
Highlights exposed admin targets, such as Organization, Global, and Account Admins, and shows how an attacker could use their reach to access critical assets.
For each admin target, users can review the policies that need fixing and generate a remediation script, connecting the identified risk with a concrete next step.
I designed additional views for Identities, Toxic Risk Priority, Assets, Supply Chain, and Threat Actors. Each gives analysts a different starting point—from an identity’s privileges to a risky combination of findings or a third-party connection—with access to related attack scenarios for deeper investigation.
The work expanded Red Team beyond a single scenario-based starting point.
Users could approach the same attack data through accounts, identities, assets, or specific risks, then follow those connections into the attack scenarios.
The key design decision was giving each view a clear purpose while keeping the investigation connected.