Kiteworks reduced its security exposure by enabling customers to reduce theirs

Identify user / business needs

The primary motivation was to protect the Kiteworks organization from its customers' opening risk exposure due to misunderstanding specific security features, which meant that it was a high priority for the CEO, VP of product, and company stockholders.

Customers who were using features in a way that could be impacted needed to know about it to either change or confirm the security settings.

Product definition

Framework to inform admins about security settings that could impact the risk exposure of their system, including an overlay wizard to guide the user over the list of settings and an email campaign to inform ahead of time, and when one of the admins confirms a security setting.

Brainstorming

During the initial brainstorming sessions, the team agreed on the overall interaction model of the wizard that uses an overlay dialog to enable the user to complete specific tasks.

Early on the project, we didn't know the exact settings that were going to be targeted; however, the requirement from the beginning was to create a framework that could contain different levels of risk based on the Common Vulnerability Scoring System referenced by the Kiteworks security team when reviwing each setting in detail.

Later on, the requirements expanded to include an email campaign that would prepare the targeted admins ahead of time, guide them once it was available, and share the information among relevant admins within each organization.

User research

We identified the customers that were going to be impacted to reach out to a handful we already had a cooperation relationship, we initially focused on understanding their specific motivations to use the settings in that way.

Problem / Solution validation

Once we had a prototype, we met again with the same group of admins to test the prototype and get their feedback. The goal was to identify wheter they think the workflow too aggrasive, if they can understand what's expected from them, and if something they expected was missing. We met a couple more times after that before the release to test over the iterations and the further extensions like the email campaign.

Team alignment

I held multiple meetings depending on the stage of the project, with multiple memebers of different teams; once in a while, I would bring the larger group to inform the progress and discuss contradictory opinions from stake-holders. The majority of the sessions were with the relevant people in smaller groups.

Explorations

The first version of the prototype showcased the wizard model with a couple of different levels of risk associated with two distinct settings.

First version of prototype.

One of the interactions that required multiple iterations was around the process of confirming a security setting. The goals were:

• Present succinct information so that admins can make an informed security decision.
• Confirm the identity of the admin who interacted with the security setting.
• Create friction that ensures that the admin is concious of the changes applied.

Early version of confirmation method using password.

One early concept explored was, forcing the admin to confirm the decisdion by entering their password; this was dismissed as something too aggresive and not necessary from the security perspective.

Iterations

The majority of the iterations happened on the wizard interaction model and the copy writting; we started with a model of multiple levels of risk displayed at once and ended focusing only on 4 settings, all very high-risk.

The first few iterations focused only on the wizard approach; all the components created were new and unique to the wizard.

Wizard accordion without reference to existing UI.

The first release of this feature focused on high-risk settings only; therefore, we only presented one group of settings at high risk and prioritized them top to bottom depending on their score. Another early idea was to add contextual information boxes next to sensitive settings even if they were not activated so that admins could learn about the best practices.

Accordion with information boxes in context.

We had some versions where the grouping of the settings would simplify one view but overcomplicate others; this version shows a badge to recognize the number of settings under each line.

List of security settings grouped by type.

When the admin navigates into a group of settings, the accordion will allow displaying one versus the other, and when one is completed, it disappears from the wizard.

Accordion with warning boxes in context.

Final solution

The wizard landing page explains to the admin the list of settings that need attention, shows the context of each setting and allows for interaction on a single setting basis so that the confirmation log is per setting.

Final wizard top page for list of security settings.

Admins can take two paths on each security setting. They can either change the setting to disengage the risk and save, or they can go through the process of confirming the risk, by navigating over multiple friction points to make sure the admin understands what's happening.

Change settings. Setting details without warnig boxes.

Confirm risk. Setting details with overlay checkboxes.

When the admin dismisses the wizard, information is presented to put some time pressure on the interaction, stressing the urgency of this matter.

Modal asking the admin to confirm that wants to exit the wizard.

The same components created in wizard context were also extended to the pages where each setting is located; this allows the admin to confirm the setting from the context that she is familiar with.

Inline setting page new interaction to change or confirm security settings.

Success metrics

More than 80% of customers engaged with the interaction and completed the workflow; this caused a minimal impact on the customer support organization, and as planned a customer support representative helped the remaining customers.

There are fewer customers out there with potential security exposures, and for those remaining now, there is a record of someone manually confirming the setting in case of a dispute.

Learnings

I learned new cybersecurity concepts and implications; I was able to bring a large group of people together on a high-stake project to deliver on time.

As a team, we developed the beginning of a framework to educate the admin about the system's set up so that it is protected. We were able to start the library of components for the design system, and the first set of those components is applied to this UI.

Future iterations

The new interaction model used by the wizard could be used for any other that required immediate and focused attention from the admin; at the same time, while working on the security feature, the same stakeholders pushed for the implementation of the "What's new! modal to inform admins about the recently installed version."

What's new modal.

In a future release, a new project to update contacts from the customer used the same interaction and wizard screen.

Update contacts form.