Resolver’s AI-Powered Incident Management

Introducing built-in artificial intelligence to automatically tag and uncover connections in security data

the challenge

Security teams are responsible for observing, documenting, and investigating incidents that happen in and around their properties. This process is challenging as information comes from many sources— often front-line employees with minimal security training and historically high turnover. Even minor incidents (say, a chipped window) must be documented, leading to mountains of data and reports that skilled investigators must rapidly sift through. Which incidents rise to the top as actionable? With such large amounts of data it can be very difficult to process all of it, let alone to find patterns in the data. Resolver’s challenge was to use machine learning to speed up the process of identifying entities (such as people, locations, organizations, dates and times) within the big blocks of text, and ultimately to make linkages across incidents, allowing security teams to become proactive in addressing issues.

The plan

Working alongside the machine learning team, we got to work teaching the model how to recognize the various entities used in our system (people, locations, organizations, dates and times). As the machine learning team worked on using real customer data sets to improve accuracy in the model, the product and design teams conducted interviews with users about what data was most important to have correctly tagged within their systems. We wanted to learn what was an "at minimum" scenario, what was at best, and what they wished they could learn from their data if they could wave a magic wand. We also wanted to understand the typical workflow for a triage officer, and how best to present this mountain of data so as not to overwhelm, but to be flexible enough to fit different agent's workflows.

User research

When we started research we were mostly focused on speed and accuracy. Speed, a self-evident goal, would allow the triage team to process many more incident reports because they could just confirm linkages already made within the system, rather than having to seek them out. Accuracy would make the quality of the data greater. What can often happen in the Resolver incident triage system is that duplicate entities can be created if the triage officer isn't careful. A cleaner set of data would allow officers to say "this black Honda Civic has been involved in three incidents this year" with a greater level of confidence that no additional incidents were missed. 

As our research progressed, users became excited by the thought of machine learning, and really pushed our thinking on what was possible. They often felt that there had to be some amount of serendipity in finding linkages between incidents, especially if the linkages were across different stores or regions. Only when two triage officers for a nationwide department store were chatting in off-hours about a woman in a fur-lined coat who had stolen perfume bottles, did they realize it must have been the same woman, despite being in two different states. Could the model find linkages like this and make their jobs easier?

It also became clear that the system needed to be flexible enough to allow agents to follow different hunches in their investigation. While it seemed straightforward to categorize an incident and then begin looking for any similarities between incidents, that is not how human curiosity works. In a moment of excitement an officer might want to be able to flip to a similar incident, a profile on a person, or a separate location to see their train of thought through. Whatever we created needed to be flexible enough to follow that path and back again quickly. 

design principles

Incident triage can be laborious. Mountains of reports, all of which need to be processed and categorized, a Sisyphean task, as each hour new reports are being generated. While recognizing the seriousness of this task (each one represents a breach in security, after all) we wanted to make this work satisfying. We wanted triage officers to feel a sense of accomplishment and order as they progressed through their work. To achieve this we gave them a large workspace and indicators of their progress.

We also wanted to use colour strategically in order to train users to look for certain elements in every report. If each report must have a person, a location, and a date and time categorized in order to be complete, we could use different colours for each of these elements so that they could easily look at their screen and know "this report has a pink and a yellow, but is missing something blue, so it must not be complete."

This led to the design principles of: satisfaction, meaningful use of colour, and flexibility in process.

usability testing

We conducted a tremendous amount of usability testing for this project. Because this was such a new initiative, we weren't entirely sure WHAT we should be building, so we needed input and feedback all along the way. In order to get constant feedback, we showed ideas and designs at all stages of the process, sometimes just holding up a hastily sketched drawing to the camera as we got ideas mid-session.

We were able to utilize a tool called Gong, which is a meeting recording tool designed for sales teams. It was a great way to store all interviews/screen recordings for reference and for stakeholders unable to participate on the day to be able to watch later. We could tag certain parts of the recording, looping in relevant stakeholders to discuss critical moments. This led to some really illuminating conversations as different SMEs discussed their takes on what a user was saying or doing at different points. 

It was through usability testing that we realized our initial goals to speed up categorizing of intake forms was not ambitious enough. It made for a fine MVP but users were taken with the idea of what the Machine Learning could help them achieve, not just through speed but through "seeing" patterns a human could not. It was from these conversations during usability testing that we added the "Insights" tab to suggest patterns and linkages.

As we built the machine learning capability and refined our designs we began to use a combination of the real users' data on a test server and mockups on Principle. Because we went back to the same user participants, they became adept at being able to switch between these environments and focus on the things we needed feedback on (for example, we might say "As you know, this is no longer the visual "look" we are going for, but what we'd like to try now is for you to look up an old incident and re-categorize the location.") While always seeking new voices as inputs into our design and testing process, it was very rewarding to have a group of users that we could return to, making it feel truly collaborative to build this new product for Resolver together with its eventual end users.

The end result

Our first release of the Machine Learning powered incident investigation system allowed for streamlined tagging of entities, a single, clean set of data, and the first iteration of our Insights feature. To strengthen the Insights feature, we needed more data from users, but we also knew that for users to be excited about this feature, we needed to give a hint at the eventual capabilities.

Demo of machine learning functionality. Insights update as the user processes the incident report. Please note: this does not reflect final UI.