How to improve the security risk assessment process in 4 steps

This is not about methodology, but about how we build the process from an initiative. I tell you what we needed to launch and support the risk assessment process, the benefits of risk assessment for us, and what methods are available to keep up with trends.

Spoiler: the case is interesting and unique in its own way, at the same time it is in the style of the latest information security trends. Our experience will be useful not only for IS analysts, risk managers, and security managers, but also for everyone who is interested in the topic of risk assessment.

An initiative becomes a process when the value and result are clear.

A small digression about the rapidly changing IS trends in recent years. We have all read about the transition from paper security to practical security. The new trend is the transition from practical IS to effective IS. The first is distinguished from the second by goal setting, which comes from management.

Another trend is the transition from complex risks to unacceptable events. This article is not about unacceptable events in the usual sense, but we have partially reassembled the concept of unacceptable events in our own way.

So, we have determined the value for ourselves in ensuring that everyone sees the overall risks, the trend towards their reduction, and is ready to commit to working on them. Management should be the first to commit, determining based on the results of our assessments what is truly unacceptable for them.

To bring this to management, we must have:

• a high percentage of our resources covered by the process;

• risks and an understanding of how we can mitigate them.

• and most importantly, explain these things in a language understandable to management.

  Read also:

  • Raspberry CM5 is an incredible New Year's gift

First round. Initiative.

Companies still often start dealing with security risks if it is:

• obligations to regulators (as in banks);

• requirements of standards that the company complies with. Both options lead to a very formal and somewhat bureaucratic approach. Unless...

...unless we are talking about a company with a certain level of maturity. But more on that later.

The path of Avito's information security team in assessing security risks is somewhat unique, at least in my experience. The uniqueness lies in the fact that risk assessment as a separate process was an initiative of the product security team.

Imagine that the IB team and product teams have already established fairly mature processes within the Secure SDLC framework, including audits and pentests. Product development teams perform threat modeling exercises, there is a fairly conscious community of Security Champions, bug bounty, involvement in risk assessment at the start of new projects/initiatives — and so on. This is practical security "by the book"! And IB comes with a new initiative: in addition to all existing activities, it has been decided to regularly assess risks.

The initiative's profit was found for everyone: product teams can understand potential security issues overall and improve their level in TMM (Team Maturity Model, self-assessment of team maturity on various criteria). The security team gets a transparent picture of risks and has the opportunity to identify and solve systemic problems.

To get started, we needed just a few components:

• willingness of IB experts to invest their time and meet with teams for joint brainstorming;

• willingness of the development teams themselves to understand and accept;

• a simple and intuitive method;

• the favorite Excel spreadsheet of risk managers with a list of resulting risks.

  Read also:

  • Raspberry CM5 is an incredible New Year's gift

We conducted the first assessments, planned tasks, and the most responsible ones took them into work.

What next? Next, we need to somehow maintain the viability of the initiative. And roll it out to everyone, because we want to get a complete picture. To do this, we need to organize the risk assessment process in a constantly growing dynamic company with 300+ teams. And it is necessary that the risk picture does not become outdated. That is, the results of the assessments need to be refreshed from time to time. The resources are still the same.

A little about how risk assessments are carried out at this stage.

To find and initially assess risks for the team, the information security expert meets with someone from the development team (usually the team lead and security champion or just someone from the developers who understands the team's processes). As a "homework assignment," the team itself makes a list of what they have, what data it is related to. The next step is questions about what bad things can happen with this information:

• what will happen if the data "leaks" where it shouldn't?

• what will happen if someone changes the information in a way that was not originally intended?

• what will happen if the asset/data in the asset is deleted or unavailable?

Some teams can immediately identify potential "bottlenecks" in their processes, especially if they have already conducted threat modeling.

At a team meeting, the expert checks the "homework" or does it together with colleagues. Then he delves deeper into possible scenarios of leaks, unauthorized changes and access, unavailability. He does this based on the specifics of the process or system. The task is to determine the significance of the already highlighted bottlenecks and find what might have fallen out of sight. A checklist with questions also helps us look at systems and processes from different angles.

Second round. Process adjustment.

It is important to understand that the transition from initiative to process implementation (i.e., value realization) is impossible without three important components:

• company maturity;

• management maturity;

• availability of resources.

Any other necessary components at this stage are more likely consequences derived from this list.

Here it becomes obvious to us that the tasks set cannot be solved by current forces and the ubiquitous Excel. Then we go further: we implement an SGRC class system. We choose from the popular solutions on the market — we adapt it to our case and process.

Having gone through fire, water, and copper pipes, the implementation process, we can manage risks and scale the process through automation.

Namely:

• create risks and tasks for them, share with product teams;

• monitor risks with expired deadlines;

• timely find those who have not yet been assessed;

• collect fresh harvest assessment results, demonstrate them to all stakeholders and highlight pains.

Working with risks has become easier, and the risk register has started to grow rapidly. At this stage, we have a register with hundreds of risks and transparency at the lower level (for product teams).

Now the new approach to risk assessment is unlocked!

As I wrote above, the initial parameters of the task are the need for regular risk assessment in 300+ teams and a limited number of information security resources.

After completing the second stage of the process, we open the possibility to choose the method of re-assessing risks. The first method (as we remember) is a meeting with an expert and brainstorming. All the artifacts of the first assessments are available to the teams. Based on this, they can answer the questions of what has changed since the last assessment and how much. For minor changes, we do the risk assessment asynchronously.

The third round. Automation.

At the third stage, we are focused on several directions at once:

• moving towards automation. We collect all assets and risk factors that can be collected without human participation. Factors can include PII, business-critical processes, APIs that provide data externally, and other similar things;

• emphasis on the autonomy of product teams. In the target picture, they can independently monitor risks and even identify them, being immersed in the context and understanding their business processes;

• metrics and metrics. For example, it is important for us to know: how relevant our risks are at any given time, whether tasks are being closed, what is the coverage of our services by the risk assessment process, and so on.

  The process is there. What's next?

  The cherry on top of the entire risk assessment process is the risk committees.

The idea is simple — we regularly present the management with a picture of the risks and tasks to reduce them. We receive commitments or objections that the existence of some risks is acceptable and permissible, and sometimes even the only correct one. Priority tasks, initiatives, directions, and goals appear. This is the movement towards effective cybersecurity.

We are still in the process of building the work scheme, now — its third stage. But the benefits of what has already been done are there and they are tangible. At the same time, it is possible that in the future we will transform the process and methodology itself.

Thank you for your time spent on the article! In the comments, I will be happy to answer questions, there you can also share stories from your personal experience about building information security processes and the difficulties that arose during this.