ExtraHop is a Network Detection and Response platform. When it is installed on a network, it sees everything; it can process traffic in real-time; it can decrypt traffic; it can look at data on the packet level. It was once a NetOps tool, but it quickly became obvious that it has the ability to detect any lateral movement on the network. I’ve worked on it for a year and was brought in to uplevel the design. I’ve worked on almost every screen in the product and revamped the styles several times. Here are a few pieces of work that I like to think about.:
Concept Art_
The original UI needed a lot of work. A fruitful exercise to do is to say, “If you didn’t have any rules, what would you do?” A lot of times, it excites people around you to see their product in a new way. Additionally, it can look at new ways to solve the problem without the overhead of concern techinical feasibility. At times, I’ve developed some concepts that might serve as a North Star. In these concepts, I was blending a few ideas. First, it seemed like a lot of the analysts were also gamers, so pulling from gaming UI was not an unbelievable source. The second was that there needed to be a feeling that there was immediate access to the data. That can be achieved by having visible layers that might allow for items to be pulled back or displayed upon click. Finally, this needs to look good on a SOC (Security Operations Center) wall and run in the background.
- Who needs this? Is this still useful to the CISO or the analyst?
- Is this the best way to view this data? Geomaps are common, but do they still do an effective job at visualizing this data?
- What needs to be shown? What might be useless?
- Are you tracking this now, and if so, how?
- How will we review this? Who will review this? When is this useful?
- What does the customer think this should be showing?
When these questions were answered sufficiently to begin concepting. I consulted with the lead developer to learn about what is possible to construct in the UI and what is not.
Detection Optimization Guide_
The product gets better performance right away by configuring a few key things on the system. I created a guide that directs people to provide background, resources, and direction areas inside the product to optimize. It is designed to be both educational and functional as a checklist.
The guide has two states – a larger to be more legible view or a mini guide size that allows the user to view more of the screen. The user can navigate inside by clicking the topics on the left side. There are options for the customer to “Go There Now” and “Mark Reviewed.” The first takes you to the topic screen and changes the guide state to the mini view to allow for more workspace. The second allows all users on the system to mark if the topic is complete and can be unchecked later if it needs to be assigned to another team member by the admin.
This was a cross-functional, content-rich project that required me to work with the technical documentation team, the training team, sales engineers, and finally, reviewing prototype concepts with customers. Also included was the first in-product lead generation request to view an IDS module. I worked that pipeline out with the sales team and later reviewed its effectiveness after 6 months. Telemetry was also added to track tasks and usage.
Useful questions to start were:
- What are the common tasks our customers are having?
- What is the best way to engage the customer while in the product?
- What are the things that need to be updated over time?
- Who will be using this? What are their permission levels? How and when are they using it?
- With the sales funnel, who is receiving this? How best does this work within their current or proposed system? What is success, and when do we review it?
Color Map and Themes_
The color system was very unorganized. Variables had been created, but the amount of custom colors that had been coded into the product by various teams over the years had grown exponentially. Below is an image of just a small section of color varieties. I had a goal of creating not only a unified color system but also one that ensured accessibility.
Elements in the UI are stacked on top of color fields. The hierarchy of content is visible by the nesting of colors. In the dark theme, content that is higher in hierarchy is on a single color panel. A small detail might be on a lighter color that is stacked on top of a darker color. The text strings inside those fields need to have enough contrast to be visible against the background. For that, I did some color experimentation and came up with a system that applied shades to color mapping that were not even steps from light to dark. The spacing of the color constants was shorter near the edges of the shade gradient, and accessibility standards were met for contrast. I also created a high contrast theme that was more exaggerated in contrast, which not only helped accessibility but looked great on bad monitors and projectors with failing light bulbs.
This became extremely helpful when we did a branding update, and I had to remap the colors of the UI to stay on brand. I was able to quickly remap the colors. Additionally, I had previously included an extension of unused colors in our variables, like pinks and purples, to make a full rainbow of colors. That investment helped because the new branding used it, and we also had some additional tags and notification colors that were used when the system became more mature.
Some of the questions I had were:
- Is there a current color system?
- What needs to be done to make this consistent?
- Who is this for? What are the goals for the standards?
- How is this organized? How will this be translated to the devs in a usable system?
- What do I need to account for in the future?
kubernetes_
To monitor activities inside a cluster, the system needed to have a way to deploy its own Pod with several agents to connect to the sensor. The admin needs to create a YAML or Helm chart that contains configuration information. API key issuing and storage are as complicated as the configuration, leading to a multi-phase solution.
• Phase 1 – API key will populate (or not) it inside to the configuration file
• Phase 2 – Limit management of API key and consolidate steps
Steps:
> Collect customer requirement > Review PRD with technical lead
> Create Happy Path
> Review with tech leads, customer focus group
> Modify and prep for delivery
Some of the questions I had were:
- Who is configuring this, and what’s their comfort level with configuration?
- What do we need to show the user in terms of an API key? What do we need to not show other users with access to the same configuration screen?
- What is the long-term goal for how we are going to manage the keys?
- How can this technology scale and what are its limitations?
- What is the least number of steps needed to make this a forgiving experience?
The first configuration flow. It was very intensive based on the location of the API key associated with the integration. This was a single page that was used to issue an API key and have it be automatically included in the YAML file. A lot of hard work and several security updates, was able to reduce the steps to be three major steps.
SecOps Report_
The Security Operation Report was created over a period of different iterations. The product has had different types of reports. This report is created to replace what was called the Executive Report, which was used to show a lot of the features of the product in a leave-behind, PDF format. After talking to many analysts, it became apparent that it was being used to report to executives about the state of security using data from the product. What was different was that I chose to build a report that would devote the first few pages of the report to the major areas of focus for the product. It could grow to include more data granularity later, but the first pages would be high-level.
Focusing on the main sections of Attack Surface, Threat Coverage, Attack Detection, Investigation and Response, and Security Hardening, I pulled out content from each section based on customer conversations with CISOs and analysts, sales engineers, and customer service engineers. Capturing these aspects in a report was challenging as there are a lot of ways to frame content. To finally decide what needed to be on each page, focusing on the drivers of each section informed if it would resonate and if it would provide value to customers. Learning that the report is usually shared via presentation, had formatted the layout to fit a standard presentation slide, while formatting it for print as well.
Some of the questions I had were:
- Who is the audience of the report?
- How is the report consumed?
- What are the drivers for each consumer role?
- What can we do better than other reports?
Detection Diagrams_
For every detection in the detection library, if it reached a threshold of being an attack vs a caution detection, it warranted a diagram to explain the attack background. From talking to analysts from the CISO level down, one of the first things I had noticed is that when talking about different attacks, they would have to replay the attack in their head to remember it. I had helped drive a project to create a glossary of attack information so customers would not have to leave the product to remember how it works.
I would meet regularly with detection teams and try to visualize the moment an attack has a “smoking gun” and show the action associated with it. These could be used to describe everything from simple recon all the way up to actions on the objective. Connecting these could also help customers visualize a campaign. This would be displayed with the attack background in the product.
Adding another layer of fun (I loved diagraming these by the way), I turned it into a card deck where the face values denote, much like the level of risk or area level in the kill chain. The idea being, if you have a full house, it’s all the steps to have a completely compromised target.
Icons, Logos, and Threat Briefings_
I’ve made the icons for the product, presentations, architecture illustrations, and logos for the Threat Briefings. Icons in the product could be functional as either a role, activity, or wayfinder. Icons inside detection diagrams create a visual library of meanings to describe elements of an attack. The threat briefing logos came from attackers taking pride in their attacks and creating their own mark for the attack. I thought there might be some fun in returning to the practice and trying to get more SEO hits with our logos if they were included in blog logos. The first one is for Bad Neighbor, which was the first threat briefing, and it came out on Halloween.
Threat briefings are usually associated with threat events or attacks that are sent to customers to help show coverage. They consist of attack backgrounds, links to CVEs or resource documents, detections, and records associated with the event. I would work with the detection team to learn about the attack and create a narrative illustration or logo that would appear at the top of the threat briefing. This is also in a thumbnail version with the listing on the Overview Landing screen of the product and in the threat briefing catalog/archive.
Appliance Branding, diagrams, and status window_
The smallest appliance of the ExtraHop family is usually in a place that has a lot of traffic. While I provide designs for all of the different appliances, this one has the most options for customization on the chassis. I work with the hardware team and vendors directly to get specs and find out what’s available within budget to provide branding and a great out-of-the-box experience. I feel this is a great way to begin a relationship well by making the package easy to install. I’ve included diagrams on the interior of the box to also show the level of detail that makes our delivery appear thoughtful.
