🐠 (Auto) Remediations

I reduced time on task 50-65% by proposing a change to the roadmap and set the stage for automation, while keeping cross-service consistency in mind.

Context

Expel has a litany of actions we can recommend to the customer to fix a potential breach. These are called remediation actions. Expel automated some of these remediations. For example, we can automatically disable a computer on behalf of the customer.

The phishing team had gotten many requests to automate “remove malicious email.” Customers wanted us to automatically and immediately remove a malicious email. However…

My role

I knew there needed to be some core changes to where remediations appeared in our UI. I advocated for this change and was responsible for using existing patterns and styles to determine

• How remediations would function earlier in the analyst workflow

• How that would look

• How that would affect our customer communications

• How this would be configured

• Rinse and repeat, but make it automated

Proposing change

At Expel, there are three stages an alert can go through. They are

1. Alert - An analyst looks at this

2. Investigation - An analyst decides they need more time to determine what happened with the email

3. Incident - There is an active security breach

Remediations were only officially available in Incidents. However, most of the time phishing analysts were only manually recommending remediations in the Investigation state.

Automating them would only be automating them in Incidents, not Investigations. This wouldn’t benefit the analyst or the customer.

I proposed to my team we delay automation to introduce remediations into Investigations. Once integrated, we would automate the remediations simultaneously.

Remediations in investigations

I was able to re-use the UI for creating remediations, but because there is a difference of severity between Investigations and Incidents, I worked with the analysts to define which remediations needed to be available in Investigations. I also worked on merging existing MDR remediations and phishing remediations together, and created net new remediations that were phishing specific.

remediations -notifications strategy

A primary concern of our customer facing team was the number of notifications the customer would receive upon creation of a remediation.

I was able to take a format for an existing notification and repurpose it for our needs, specified the notification defaults, and outlined the ways in which the customer could react to the notification.

The result was that the customer was informed of the remediations in the same convenient manual way they had in the past, but in a trackable way they could use to cue off their own tickets. This was more efficient and convenient for internal analysts and customers.

remediations - User Testing & collaboration

The designs and workflows I made were tested with our analysts to make sure it met or exceeded expectations.

As I had been working on the designs, I was also constantly checking in with the engineers to ensure technical feasibility.

remediations - Service Consistency

I knew introducing remediations into phishing investigations would eventually lead to analysts and customers requesting the same from the MDR service teams, and that we should strive for consistency between the services.

Before embarking on this project I validated that MDR also wanted remediations in Investigations. The designs and the I created were intentionally also applicable to the MDR service. I kept the PM, designer, and analyst leadership updated throughout my process.

automating remediations

With remediations in investigations under development, I began discovery work with both customers and internal users around how to design Auto remove malicious email.

automating remediations - design iterations

Because the MDR service already had reusable UI components for auto remediations, I reused the design with a few changes.

However, after launch and as time went on, it became apparent that phishing and MDR had different needs. Typically, MDR’s use cases were more complex. However in the case of remediation, phishing was more complex.

I redesigned this UI to account for phishing specific challenges. These changes were also beneficial for the MDR use cases, as I designed it to be more scalable.

Automating Remediations - Notification strategy

Automations require their own set of customer communications for when they succeed or fail. I created workflows and figured out the possible paths the remediation could take, adjusted the existing notifications accordingly, and defined the notification defaults, which were quite different from MDR auto remediations.

Remediations in investigations was a success.

• Analyst cycle time went from 15-20 minutes to 7 minutes, which is a 50-65% decrease.

• Phishing analysts can officially create remediations in a trackable way for the customer

• Customers are notified of remediations they must complete, in a concise, aggregated way that does not inundate them with notifications

Unfortunately, MDR had to prioritize other projects so the services are not consistent with each other. However, MDR analysts have been requesting the same design in their investigations as well, and much of the base design is covered in my work.

The design of Auto remove malicious email has gone through a couple iterations due to suddenly gaining much larger and more complex customers. The latest iteration is much more scalable and applicable for both services, and is due to complete development in 2024.