Summary

Respond Events List

Respond is the incident management portion of the RSA NetWitness platform. It allows an analyst to see a prioritized list of potentially malicious incidents that NetWitness has detected for them. The first task of an analyst when faced with this incident queue is triage, in other words figure out:

• What happened?

• How serious is it?

• What do I do next?

The longer an attacker is in the environment, the more damage they can do. The analyst is under a constant time pressure and is expected to triage incidents in just minutes. One readily available source of information the analyst can use to answer the above questions is the list of events that make up the incident. I redesigned this events list so that it could incorporate a new data source.

The Problem

We were integrating a new Endpoint agent into the platform allowing us to collect rich data from any device - from servers to employee laptops. This agent sends back different data than the other events previously shown in the Respond events list, and simply plugging the data in to the previous format would result in a lot of empty fields and not a lot of useful information. The analyst would have to pivot, context switch, and waste precious time to get the information they need. Or worse they may gloss over the events and miss malicious threats.

The events list needs to display the most relevant data in an easy to understand way that allows the analyst to quickly understand what has happened and how serious it is, so that they can figure out what to do next. Enabling the analyst to triage incidents more quickly means they can get through more data to find the real and most dangerous threats and remediate them more quickly. Meaning that attackers can do less damage and the network is better protected.

One of my biggest challenges on this project was the diversity of the data. We have events coming in from different sources which contain wildly different data sets, and we have very little control over how any of it is organized or what it contains. In other words, how do you design for data when you have no idea what it is going to look like?

The Process

E-mail me to request access to full case study featuring details of process

• Discovery

• Wireframing

• Usability Testing

• Visual Design

• Animation Design

• Componentization

The Solution

I designed an events list that featured a compact card style format, that allowed us to customize the fields shown according to the data source and show the analyst the most relevant fields. I paired a top row of the most important key-value pairs with a summary table clearly showing the source and target information so that the analyst can quickly see where the potential attack is coming from and what or who they are targeting.

On click, this summarized view expands out to see the full event details without the context switch of opening a new page. The details were split across columns to allow the analyst to quickly scan the information without having to scroll. The first two columns were organized again into source and target, and the remaining columns were grouped according to the hierarchical structure in the data to preserve precious contextual information.

This events list was then componentized and adapted for reuse elsewhere in the product.