Secure App Service

Background

Software companies release products on a regular basis. Same applies for malware. When installing a product from internet, you can never be too sure if it is a genuine product from a genuine company. Legitimate software companies depend on code signing to ensure that their products are trusted by browsers and operating systems. Users can also review the certificate used for signing the installer and ensure that it’s from a vetted vendor. Users can also verify that the installer has not been tampered with, after the code signing.

Symantec is perhaps the only company which provides an enterprise code signing management product. This product can be used by software publishers to obtain code signing certificates, sign their code, and then manage the signed code and signing certificates.

Problem

This product’s backend (certificate issuance and code signing service) is based on one of the oldest platforms in Symantec. The product’s UX is severely restricted by the platform underneath it. Users have access only to the basic functionality such as requesting certificates, uploading code, requesting signings using pre-configured signing services.

Almost all of the account configurations need to be performed in the backend system via a UI that is only accessible by Symantec’s product managers and specific support teams.

A lot of the productivity hours of the PMs go into configuring and modifying the customers’ accounts as requested by them.

The product has two hierarchies:

Service management (The parent organization)
Workgroups (departments, development teams, sibling, or child organizations)

The service management level is responsible for defining the workgroups and signing services. However, the actual configurations are done by the PMs.

Once, signing services and workgroups are configured, the workgroup members are the one who do the actual signing.

Currently, the service management account and workgroups are all treated as separate organizations, having their own individual accounts and requiring individual vetting.

The industry body CA/B Forum mandates that an organization be thoroughly vetted by a CA before it can get a code signing certificate.

In reality, if the service management account is vetted the workgroups inside it should not require vetting unless they want to sign code as a separate legal entity.

The backend also restricts how users are managed. There is no way of implementing unique identity management. A user can have multiple accounts in the application with different roles, while using the same email ID. The application uses its own internal IDs to differentiate the user accounts. If a user needs more than one roles they must be added as separate users for each role. If a user requires access to more than one workgroup, they must be added as separate users for each of the workgroups.

These limitations severely impair organizations who implement stringent identity management from easily integrating this product into their ecosystems.

The PM and UX is aware of these limitations and wants to remove them. The PM also wants to offload all the configuration activities to the customers, as far as possible.

Opportunity

Symantec CA is going through a series of systems modernization activities. The goal is to consolidate all our offerings under one umbrella product so that all these products can use our most modern vetting and certificate issuance engines.

This was a window of opportunity for us to modernize our product too.

The Certification Authority business is heavily scrutinized by the industry and governments and hence we needed to take a careful approach towards modernizing our product. We also needed to ensure that the CA can still control some configurations that are mandated by the industry.

The PM team asked UX to come up with ideas for improving the product.

Project

I was working on this product as the lead content writer, along with an interaction designer. At that time, we were both reporting to the UX design director.

We all already had a good deal of ideas for improving the product. However, we didn’t know how exactly to implement these ideas.

Our proposal was broadly meant to make improvements in the following areas, among other things:

Onboarding – Create a unified account experience for customers.
- Dissolve the current two tier hierarchy into one single account.
- Customers should have to create one service management account and then add workgroups within it as child entities. They shouldn’t have to request each workgroup as a separate entity.
- A user should require adding only once and should be visible across the entire customer account. Users should not require adding as separate entities for each workgroup and role.
Configurations – Customers should be able to configure most of the services by themselves. They should not need to rely on the PMs.
- Customers should be able to add workgroups by themselves
- Customers should be able to configure signing services and assign them to required workgroups by themselves.
Account management – Create a super admin (parallel to service management admin) role that can manage the whole account or assign others to do it.

The biggest challenges as identified by me were:

We don’t completely understand who are service management admins and workgroup admins.
We don’t completely understand how much domain knowledge these both types of admins have.
We are not really sure if any or which of these two types have the knowledge required for configuring the account.
We didn’t understand which of the configurations do customers really want to take the responsibilities for.

We also need to sell our improvement ideas to engineering and PM as the effort required for implementing our ideas was huge.

We decided to conduct user surveys to get a better understanding of these roles and to qualify whether our understanding of user challenges is real and complete. We also hoped that the findings of the research would validate and support our proposal.

I was assigned to identify the questions that we need answers to.

Approach

Step 1: Get a good understanding of the existing ecosystem.

We had the PM provide us thorough training of the backend platform that was used by this product to manage organizations, vetting, contracts, signing services, and certificate issuance.

The PMs conducted 5 weekly sessions to complete this training.

As part of this exercise, I:

Created an Excel sheet that captured all the screens and fields in the backend UI.
Had interviews with the PM to understand each of the fields and their importance from a CA’s perspective.
Identified which of these fields were actually relevant for our product and which can be dropped off. (This platform was actually the authentication and certificate issuance platform for our GeoTrust brand, so it has some functionalities that were not relevant for our product.)
Understood the configurations that are managed by the PMs and the authentication teams.
Short-listed the functionalities/responsibilities that can and should be transferred to the customers via the code signing product’s UI.

Step 2: Create a questionnaire for user interviews

I had identified the following areas that required answers

Who is the most qualified person at the customer end to manage these configurations.
If we were to create a new super admin role, who in the customer’s organization would be fit for taking it up.
Which of the responsibilities would the super admin want to retain and which of those would the super admin assign to the workgroup admins.
Do any of the existing admins, service management level or workgroup, understand the technicalities of a signing service. For example, things like key size, secure hash algorithms, certificate key models, application reputation.
What sort of autonomy can be provided to workgroup admins and what functionalities must be strictly restricted to super admins.

We also need to understand some real world scenarios such as:

How are the customers currently using our product.
Which decisions are made at service management level and which at workgroup level.
Which job roles in the customer’s organization were the admins in our product. The general understanding was that service management admins were someone managing the overall IT security of the company, people such as chief security officers or chief technology officers. Workgroup admins could be either engineering directors or managers or someone from the company’s build room.

We also needed some quantifiable data to ensure the changes in the UI were worth the effort of our engineering team. For example:

How often signing services were configured and modified.
How often new workgroups were created or edited.
How often do different sizes of companies perform code signing.
What types of applications were signed and what was the volume for each of them.
How often did users need access to multiple workgroups and signing services.

In the end, the questionnaire had 50 questions depending on the responses to the initial questions.

Once my questionnaire was ready, the UX research team created an interview script. They got both service management and workgroup admins from different size companies to volunteer for 50 minute sessions each.

Step 3: Study the survey findings.

When the survey results finally came in, they matched our understanding of the user expectations to a high degree. The key things that we learnt were:

Users hated having to log in to each workgroup separately.
Users wanted to manage all users under one account instead of having them as separate entities across the service management account and each workgroup.
Onboarding new workgroups should be possible from the UI and customers shouldn’t have to contact PMs.
Workgroup admins were technically advanced and had the abilities to configure signing services. However, the decision making on configurations rests with separate security departments which set up the corporate security policies. Some customers still want Symantec to provide pre-configured services and set the industry standards.
Customers need a way to control the number of signings in a workgroup.
We were also able to get a distinction between the responsibilities that customers expected at service management level vs. workgroup level.
We were able to identify which roles in the organizations were best suited for administering the account at both super admin and workgroup levels.

Step 4: Work with my designer to create UX stories, task flows, and wireframes for UI improvement ideas.

After having our ideas validated by customers, my designer and I set out on exploring the new platform to which we wanted our product to move. The new platform is now the authentication and certificate issuance engine for all our modern products.

We needed to understand how the system functions so that we understood the end to end flows for the new UX.

Once we had a good understanding, we created an end-to end workflow of the customer onboarding process. We listed out the activities performed by each player in the process, namely:

Sales rep
Customer contact
Operations team
Authentication team

User onboarding flow

Next, we created flows for each proposed improvement. For example:

First time flow
Account configuration
Adding workgroups
Adding users
Setting up signing services, from scratch and also by using pre-configured templates.
Follow up tasks for modifying items in the account, like editing user roles, editing signing services, etc.

Creating a signing service

After we had the user stories and flows approved, we set out on creating the mocks. The mocks were created by my designer, while I kept providing technical and business context inputs regarding the implementation and real life scenarios.

Following are some wireframe samples.

1/3

1/4

1/5

Result

As of today our proposals have been approved by the PM and added to the product backlog.

However, due to the acquisition by DigiCert, Inc., this project has been put on hold until all products move to DigiCert’s own authentication and certificate issuance engines.