Getting from Risk to Action

Helping security teams figure out what needs attention and what to do next

Censys · Senior Product Designer · 2022

Finding the risk was only the beginning

Censys helped security teams find exposed systems and vulnerabilities. But finding a risk still left people with plenty of work: understanding what it meant, deciding what needed fixing, and finding whoever could fix it.

One prospective enterprise customer described spending 10–20 hours a week tracking down the people responsible for affected IP addresses and servers. He was hesitant to subscribe because identifying more vulnerabilities didn’t solve that problem.

I worked with our Product Manager and Engineering Team Lead on Risk Context. The project started with a broad request to give customers more information. I wanted to find out which information would actually help them do their jobs.

Agree on what people need to accomplish

I mapped the investigation flow and used discovery interviews to find where people needed more help. We agreed on a working hypothesis: customers should have enough information in Censys to decide whether they needed to act.

That gave us something more useful to work toward than “more information.” I brought the findings into a collaborative sketching workshop with product and engineering so we could work through possible solutions together.

We focused on questions people needed answered: How urgent is this? How long has it been open? What should I do about it?

Make the information easier to use

I brought organization-specific tags into the main risk table, replacing the category column so teams could see their own context while scanning risks. A risk’s importance depended on the organization, and tags gave teams a way to add their own context. The design also allowed rules built with our search language to tag new risks automatically.

I changed “Open since” to “Open for” so people could see how long a risk had been waiting without calculating it themselves.

Make the list easier to scan

Earlier design

Revised design

Details from the original desktop designs. Select an image to open the full screenshot.

For outdated software, I kept the version information customers requested and added a recommended upgrade path. I also designed the table to change with the selected risk type, showing relevant details without putting every possible field in every view.

Show the upgrade path

Version context

Upgrade recommendation

Details from the original desktop designs. Select an image to open the full screenshot.

Work within the limits

We weren’t sure how much external information we could bring into the product. I included direct links to vulnerability references and Censys Search rather than making the design depend on those integrations.

People would sometimes need to leave the app, but they would have a useful starting point for their investigation.

Keep the next step close

Details from the original desktop designs. Select an image to open the full screenshot.

Take it back to the customer

In follow-up calls, I showed the customer the prototype. He said it could nearly eliminate the time he’d described and asked whether it was live so he could subscribe.

The work also pointed toward another opportunity: connecting assets with the teams responsible for them, then automatically assigning matching risks. That was a possible next step beyond the Risk Context design.

Risk Context was in development when I was laid off, before launch. I didn’t get to measure the time saved afterward, but the prototype conversations gave us direct feedback that we were addressing a problem this customer was willing to pay to solve.

Want to discuss this project? Contact Joe at josephnewell90@gmail.com.