Why conduct security risk review?

👋 Hello readers~

In our previous article, we shared about application security testing framework and how we could convert complex test results into simpler use cases for raising security awareness. Today, we’d like to share why “security risk review” should still be conducted even after a security assessment has been done.

“Security assessment refers to the evaluation of security mitigation controls that involves identifying probability of impact, threat, and vulnerability from the system defining functions. (e.g. Is your firewall strong enough? Can unauthorised connection pass through?).

Security risk review is a thorough examination of the system’s security design, conducted to determine if, how, or what is required to meet an organisation’s objectives or desired outcomes. (e.g. do you need a firewall to meet your organisation objectives?)”

In today’s context, the ability for application architecture to remain open, fast, and adaptable presents a very strong business use case for applications to constantly review their risks beyond its security benefits. One key aspect of an improved application design is the ability of the application environment to accommodate changes such as future business needs, infrastructure, and security requirements. All these factors require code modification and the impact for scalability exists (be it good or bad), which pose the greatest threats to the scalability of a software application.

Incorporating new security measures, such as input validation and/or error handling, may unknowingly undermine any level of scalability that the given application may have prior to such changes. The reality is that code modifications today are quick and dirty even when conducted through a formal change control process, which consequently allows many security risks to slip into the application unknowingly.

So what can/should development teams do?

Safer with security risk review!

A security risk review helps to provide the medium for the above situation by:

• (re-)addressing the business objectives,
• filtering all the way down to specific use cases, and
• possibly impacting the newly introduced security countermeasures or controls.

Additionally, it focuses on permission sets that may have been awarded inadvertently through design/code changes.

Since a security risk review essentially walks through software application components, a smaller degree of risk exists when changes need to take place, thereby sparing possible setbacks in software scalability.

“The key security benefit of conducting security risk review over risk assessment is that identified risks are derived from attack possibilities that are unique to application environments.”

The key security benefit of conducting risk review over risk assessment (e.g. automated scans/qualitative assessments) is that identified risks are derived from attack possibilities that are unique to application environments and not the discovered vulnerability. Motivational factors for launching specific types of attacks are conceptualised to provide the most likely description of an attack landscape for an application. In essence, application security today doesn’t truly map out the specific attack scenarios for given (or a series of) vulnerabilities associated with the assessed application. As a result, an incomplete portrayal of risk (without the risk review results) could be presented to information owners for remediation.

Presenting risk review results is a challenge. Owners may not understand the nature and likelihood of possible attack scenarios that could happen to their particular application and how likely attack vectors would be launched to introduce these risks.

Security professionals can do a walkthrough of an attack that maps to a process for easier understanding of this (some of the methods used were discussed in our previous articles). These security weak areas could be discovered prior to a production build/release with the security review efforts taking place in the early stages of the development life cycle, thereby allowing remediation of vulnerabilities to be addressed early!

Not only is security risk review able to address what security requirements must be presented across multiple levels of the application environment, it also identifies new attack vectors and potential exploits during the testing and validation efforts within the reviewing process. All these efforts take place prior to code migration into higher application environments, therefore reducing the remediation efforts and risk exposure levels. This is what we noticed by doing so — the reduction of software vulnerabilities reduces remediation time and effort, and less time translates into less cost.

However for risk review rationale to evolve from theoretical to practical, there are still many challenges when managing the stakeholders. One way to achieve this better is to collect key metric values and trends over time, such as:

• residual risk level,
• remediation time,
• number of vulnerabilities, etc.

Careful choices of these metrics can be used to sustain business value of such effort (perhaps we could share more in the future on how we conduct security risk review for our in-house products).

It’s important to add a security risk review as part of your cybersecurity effort. Security review allows teams to be engaged earlier for any potential risks, thus, improving security quality at the earlier stage of the software lifecycle. Imagine yourself driving on a road with many paths to your destination; all you need is some early effort to anticipate which route could be safer, less jam, and/or shorter, before setting off. By doing so, you allow yourself to plan ahead with a better journey — this is similar to what a security risk review could do for your project too! It is a process that allows planning ahead with lesser risks and higher security quality meeting your organisation’s objectives.

Till then, we hope you have learned something from this article! (❛ ́ ͜ʖ ́❛)✊

- Merlin 💛