XDR — Network

Extending Endpoint Telemetry with Network Analysis Workflows

Problem Statement

Carbon Black Cloud was a traditional EDR, with detection and response limited to telemetry collected from the endpoint itself. The product had a huge blindspot when it came to network telemetry — Application Layer information, the ability to detect network intrusions and anomalies in network traffic, and the ability to block traffic to and from malicious IPs, ports, and domains.

The Goal

My design aimed to incorporate network data into the existing product, placing it alongside device data, and weaving it into the already familiar workflows for analysts, threat hunters, and incident responders so they could get the data where they need it without changing the way they mitigate cyber attacks.

The Process

Requirements Gathering, Planning, and Prioritization

With 18 engineering teams, and me leading a team of 5 UX designers, researchers, and content writers, it was imperative to keep the teams organized and prioritizing the right work.

• Created planning aids like Gantt charts and a Kanban board, ran discovery workshops, wrote user stories
• Established new practices for user acceptance testing, deprecating old portions of the product, and onboarding strategies future projects could use

Defining the Underlying Data Model

The first phase involved working closely with product managers and solution architects to analyze the network data. Since the primary interface centers around search, it was critical to design the data itself so it was clear and matched our users' mental models.

• Designed schemas for TLS, HTTP, DNS network connections and new detection types for network traffic anomalies and intrusions
• Determined what details to display in which contexts
• Decided what to call each field in the backend and in the UI, how to order and group them
• Helped plan and run user research sessions to validate our concept for clarity
• Research identified issues with our local/remote terminology of the sensor and how that conflicted with the source or destination of the netconn
• Iterated to address our users' concerns

Mapping User Journeys for Impacted Personas

Before jumping into design, I studied the existing user personas and spoke with a former cyber analyst to understand which personas would need the data, and how they might use it in their existing, daily workflows.

• Identified four personas with workflows that would be impacted: analysts reviewing and triaging alerts, incident responders mitigating perceived threats, threat hunters seeking unidentified threats, and developers creating and maintaining integrations
• Used information architecture and workflow diagrams to identify where and how to insert the new data without disrupting the existing structure
• Used the output to draft initial concepts, put them in front of users for feedback, and break the project into logical parts so multiple designers could own their own slice

Wireframing, Prototyping, and User Testing

Through multiple rounds of iteration and testing, we released a product in less than a year. We tested with users every step of the way, which helped prioritize the most beneficial functionality and release subsequent features over a rolling cadence.

• Analyst workflow concept research with wireframes
• Threat hunter workflow test with clickable prototype
• Usability testing with an early-access working product
• Incorporating feedback from an in-product survey
• Further usability testing with a second set of features

Enhancing Readability and Comprehension

One design problem for XDR was taking dense, complicated network telemetry and delivering it in a format that provided maximum clarity. Since cybersecurity is an industry with many junior security analysts performing critical work, it was critical to help analysts learn by giving them the right information at the right time and place.

• Ja3 fingerprints were long, numerous, and hard to parse between different components — I used both color and tone differentiation so even colorblind users could distinguish the breakpoints
• In network connection events, source and destination were confused with whether the device was local or remote — I added visual indicators to highlight directionality
• In network connection details, we were introducing a breadth of new information that changed between different subtypes of events — I organized the data so many portions maintained consistency no matter the subtype, and grouped changing information together for less jostling when comparing events
• MITRE ATT&CK is known to some analysts, but the details of each tactic and technique are often forgotten, so I provided quick-reminder access points and linked out to the full MITRE site

Designing with Agility and Pivoting Hard

A critical moment in the project was when I identified a user experience problem where our data was too buried, and I feared users would not be able to find it, let alone benefit from it.

• In taking my advice, the team decided to expand the scope of the project and update a very old portion of the product to accommodate the new features, without disrupting our customers' existing workflows
• We carefully examined what portions we could keep and what we could add to keep it familiar, but also much more powerful and flexible
• We incorporated an in-console visual walkthrough to point out the new features and help customers acclimate to the changes
• We released the product in stages, letting customers opt in at their own pace over a six-month timeframe before removing the old UI
• We achieved 96% adoption before turning off the old version of the page — our target was 75%

Challenges

We started out the project without a product manager, and once we finally hired one, she ended up quitting after a month, so the team leaned on me to set the direction and create a unified vision.

• Managing the needs of many persona- and customer-types, both highly skilled and beginner level, within the same interface
• Deprecating old portions of the product to build something more extensible and durable for this and future efforts
• Coordinating and leading the efforts of 2 other designers, 2 content writers, and 1 researcher
• Leading design workshops, quarterly planning sessions, and routine UX/ENG/PM reviews to define necessary steps and talk through implementation issues and blockers
• Collaborating across 4 continents, 7 widespread time zones, 18 engineering teams, 4 PMs/product areas, keeping everyone informed of a unified design direction
• External factors, such as a corporate acquisition that resulted in 48% of R&D leaving, so I was constantly shuffling staff, onboarding, and at times doing the job of 3 people to make sure we could still deliver in under a year

Awards and Accolades