🐠 (Auto) Remediations

Context

Expel’s primary MDR service 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 introduce “Auto remove malicious email” into the service. Once we determined an email was malicious, customers wanted us to automatically and immediately remove the malicious email from their environment for them.

My role

Before we could automate remediations, 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. Phishing inherited this structure from the MDR service. However, due to the nature of phishing, most of the time analysts were only manually recommending remediations in the Investigation state.

I recognized that we needed to officially introduce remediations earlier into the analyst workflow, because just automating existing remediations would have little impact. It was also a hole in our service delivery. I advocated to and with the product manager, engineering manager, and analyst stakeholders to make this change.

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. At the time, every remediation sent a notification to the customer immediately, so that the customer could remedy their environment ASAP.

Phishing is generally considered a much lower level threat, and we did not want the customer receiving individual notifications to immediately remediate if the threat was not imminent.

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

Although the phishing service had its own feature team and its own security analysts, the phishing service and Expel’s primary MDR service share the same UI. 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 met with the designer and product manager of the MDR service to ensure these UI changes would not interrupt anything on their end. The designs and the notifications I created were intentionally also applicable to the MDR service.

Although remediations in investigations were a standalone feature for phishing, my team and I set up the MDR service so they could eventually have remediations in investigations as well.

automating remediations - user testing

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 auto remediations and a component for how to display those, 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.

• Phishing analysts save about 13 minutes of their time with remediations

• 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 unforeseen challenges that came with 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.