Bringing Security to Digital Product Design

One of the biggest problems in digital product development today is the failure to collaborate with InfoSec or DevSecOps teams. Unfortunately, threats are ubiquitous and increasingly sophisticated. But did you know that there is a way to reduce the time spent remediating security issues by up to 50%? 

In 2016, the State of DevOps Report published its research indicating that high-performing teams spent less than half the time fixing security issues compared to low-performing teams. And the solution to this is to move left.

Today, most companies go through a development cycle that includes at least four stages: analysis/design, coding, testing, and deployment. In a more traditional environment, security enters the third phase, as one of the testing tasks. 

In practice, this means that teams discover coding or architectural flaws when these problems are already too expensive to fix. So, the metaphor for the solution goes like this: if we map the four previously presented stages on a Kanban board, moving to the left means anticipating discussions, doubts, and risk assessments. This way, these issues will be addressed in more robust, effective, and cheap ways for the product.

We are aware that prioritizing security is a common challenge. Even though it is a critical issue, most leaders behind the development of new products are not interested in prioritizing this type of matter. Whenever possible, they try to focus the team's efforts on features. For this reason, there is often no room for this type of discussion. So what should we do?

Fortunately, there are multiple possible solutions. One way to approach the topic is to take advantage of the opportunity of a collaborative and immersive session such as product discovery. That is the perfect time to dedicate time and energy to the topic, together with everyone present. So, let me show you two ways to identify and address threats and vulnerabilities: through the creation of personas and also by identifying opportunities in user journeys.

Hostile Personas and Their Journeys

The first technique that can be used is the creation of personas with a hostile or opportunistic profile. For example, think of a situation in which a freelance professional and his assistant share a password for an online service. This is a very common case in the healthcare sector, where doctors' secretaries do a lot of the work in building relationships with patients and health insurance plans. 

If, for some reason, the business relationship is broken off in an unfriendly manner, there is a chance that the person will use these credentials in a way that causes some kind of damage. In this type of situation, we could have harmful actions such as important changes in payment settings, unwanted contact with different patients, and altering schedules or diagnoses.

Usually, in a product discovery session, there is a proposed activity to map personas. To map this kind of behavior, I recommend using the same persona model that is suggested. From there, go deeper into hostility characteristics in sections such as bio, objectives, interests, and frustrations, as in the figure above.

After the personas have been described, it is important to deepen the discussion by mapping journeys. The goal here is to identify actions and behaviors that provide ideas on how to correctly deal with threats. Remember that when using an assailant actor, the materials should be written from its perspective. With this, we will usually have the description of unwanted events of multiple natures, which can threaten, for example, confidentiality, integrity, or availability of data of users of the solution.

Depending on the type of dynamic you are participating in, there may be space to write some user stories. If this is your case, it is essential that the session facilitator properly conducts the activity by bringing everybody present together. In general, security team members do not always know how to write stories and will, therefore, need help to bring their contributions.

Attacker Actions in Other User Journeys

Complementing the user journey with likely attacker actions is another technique that helps software development teams map, plan, and address security as early as possible. In this approach, we leverage the user journey materials created and add a new row in the insights zone. Attacker actions will behave similarly to opportunities, as shown in the figure below.

By using the journey mapping process to illustrate the user experience, we have a great opportunity to highlight points of potential vulnerabilities. As insights and ideas emerge from discussions, they should be documented and positioned in relation to the points of interaction between the user and the system. 

At this moment, don't be economical: if there is already an understanding of the software architecture components, flag them as well. This will be important so that in future design discussion sessions, trade-offs become clear, generating better discussions on how to manage the problem and propose the most appropriate solution for the moment.

Adapted User Journey Model, focusing on Attacker Actions

In the figure above, we see the journey of a financial institution customer in his goal of making a transaction with a friend. A relatively simple operation for people literate on banking, it has several elements that can be analyzed from the perspective of an attacker's actions. To simplify, we took only four steps in the journey and identified three possibilities for deepening the conversation from a security perspective.

Based on these identifications, we must establish action points to mitigate the risks raised. It is the facilitator's role to encourage questions to further stress the subject and establish moments of conversation that generate input for a more robust solution.  

Now, think about some of your products and their journeys. Can you identify what opportunities an attacker could exploit?

Wrapping up

Before finishing, let's take the opportunity to highlight the importance of correctly planning these kinds of sessions. If your team is inexperienced in the subject, an alternative is a preparation meeting for the design with an exclusive focus on fundamental information security concepts. And during the activities, examples will be well received by the development team.

Additionally, the role of the facilitator is very important. He/she will be responsible for contextualizing the objectives of bringing security issues into the design process. It is extremely important that participants understand what will be expected of them.

I hope you will keep safety in mind when designing your next project. Feel free to use any of the techniques above and share your results!