How to implement application risk profiling

Many security articles, blogs and books focus on defense and how certain vulnerabilities can be mitigated or transferred. In this day and age of abundant cyberattacks, advanced and less advanced, this is of course critically important. We also experience this at our customers where security teams are more and more aware of the necessity to improve their organization’s security maturity to prevent their doomsday scenario(s) from happening. Examples of these scenarios can be attackers modifying data in a finance company for their own profit, stolen or leaked sensitive and personally identifiable information (PII) in an HR services company or the inability to treat patients in a hospital. In your specific organization, the doomsday scenario may yet be another one.

However, although less often, we also see teams at well-funded organizations willing to improve the security of certain systems, where one starts to think: “Isn’t that too much for this application?” or “Should we be spending more resources on another application”. Can there be too much security? Yes. But these questions may not lead to a qualified answer. Enter application risk profiling.

The activity of application risk profiling consists of, as the name suggests, classifying applications according to their risk level. Based on the risk level of the application, we can then define which type of security controls should be implemented. A list of predefined controls can be created for every risk profile. As such, for application teams, it is clear what is expected from a security point of view. And for the to be built applications, this input can be used in the security requirement, helping to achieve security by design (see also my blog on security requirements).

The specifics of implementing application risk profiling will be different in every organization, but in the next paragraphs I will share how to implement application risk profiling successfully in just 3 steps

To secure what you have, you should first know what you have. It all starts with an overview of the applications that are running in your organization. This may be easier in a start-up with just 12 applications, but in a large enterprise, there may be thousands of applications. In these environments there is typically a central overview of the applications, either centrally or per business unit. Connect with the people responsible for that list. This could be the risk and compliance team, the application management team, or another team, depending on your organization. Should there be no list or an incomplete list, then your first job would be to create a complete list, working with the relevant people in your organization.

Once you have a central list, either in a spreadsheet or a specific application, then integrate the application risk profiling part into that system. If that is not possible, then implement a standalone application risk profiling system (this could also be a spreadsheet). The end goal is to get a risk value for every application, e.g., high-medium-low. We can define the correct risk value by asking the right questions and give a predefined score to every possible answer. The total amount of points then defines the risk level. These questions, possible answers and corresponding scores need to be defined for every organization in their specific context. Here are already some ideas about aspects that could be asked for.

• Compliance requirements
• Monetary value of the data
• Sensitivity of the data
• External or internal facing
• Hosting location
• Reputational impact
• Availability requirements

• Number of developers
• Security knowledge and skills of developers
• Number of users
• Types of users
• Dependencies and vulnerabilities
• Safety (in case of applications with human impact in the physical world)

Now, let me give you an example of the result of a profiling exercise in a fictitious hospital, where I discuss some of the characteristics mentioned here above. The three example applications might have an intuitive score, however, in a real-life context, this is certainly not always the case!

• The electronic health record software (EHR), to store patient data and to support the care process.
• The logistics application, to manage the medical material stock.
• The lunch order application, for staff to order their lunch.

Of course, when you create an application risk profiling program, you cannot respond to all these questions yourself. Therefore, you will need to work with, e.g., the application owner. It is however your responsibility, as owner of the application risk profiling program, to create questions that are simple enough so all application owners can answer these. If you need to explain every question to every application owner, the program will not scale nor succeed. In addition, you need to verify the answers and challenge those, based on knowledge of the internal context. In the end, the reason to run this program is to avoid having too much or too little security. If we get incorrect answers, we cannot achieve this.

It is important to update the answers to your questions regularly because no application is static. There are always things that change to the application itself or the context of the application: the hosting location, the developers, the business use case, the libraries, etc. Therefore, once all or most applications have received an answer, you can repeat the exercise at a regular interval. You can also agree with other teams to get proactive updates when things are changing or look at the output of scanners to update the information on code and dependency vulnerabilities.

I hope these directions help you to set up a successful application risk profiling program.

For further reference, I can share with you OWASP Security Assurance Maturity Model (SAMM), mentioning application risk profiling. Industry specific standards, such as NTA 8120 for the energy sector refer to this. Noteworthy as well is the OWASP Application Security Verification Standard (ASVS), working with three verification levels, depending on the criticality of the app, resulting in different security requirements.