ISACA Journal Author Blog

ISACA > Journal > Practically Speaking Blog > Posts > A Practical Assessment of Application Security Risk

A Practical Assessment of Application Security Risk

Shubhamangala B.R. and Snehanshu Saha, Ph.D.
| Published: 4/4/2016 8:41 AM | Permalink | Email this Post | Comments (0)

Application security risk (ASR) is a measure of an application’s susceptibility toward attack and the associated impact. Security breaches deter organizations from attempting to meet their objectives, therefore, securing applications is a top priority in organizations. While the art of securing applications largely depends on the awareness of the security risk levels in applications, various methodologies, frameworks and benchmarks compete with each other in estimation and mitigation of application security risk. However, are the assessments and benchmark self-contained? Do we trust the strategies used for computing risk assessed through current technology and heave a sigh of relief that they are safe from breach? Practically, the answer is no.

There are a few reasons for this. The persistent occurrence of breaches worldwide unveils the shortcomings in current risk assessment methodologies and reiterates the pressing importance of accurate measurement of ASR. The generic formula used (with slight variations) to measure risk is an algebraic product of probability of attack and the impact of attack.

Considering this equation, the impact of an attack is relatively easy and straightforward to assess. The term “probability of attack” indicates how likely it is that the attack occurs. The calculation of the probability of an attack has practical limitations. The probability of simple situations (e.g., tossing a coin, picking a card, throwing dice) can be derived from the first principles. Evaluating the probability of real-time events (e.g., weather incidents, hurricanes and earthquakes) is possible based on historical records. But in the case of attacks, probability does not work because attackers do not follow any statistical pattern. For instance, consider the retailer Home Depot and the security breach it experienced in 2014. There is no previous history of breaches at Home Depot. What was the probability of a Home Depot breach before it happened, and what is the probability of a Home Depot breach again in the future? Can probability predict that Home Depot will be breached again or never again? Even if probability provides an answer, will it match with reality? It is clear that a risk formula has limited value in the field of application security. Additionally, this formula does not provide the risk measure present in applications as it focuses on the likelihood of attack. Hence, organizations require a realistic application risk measurement paradigm that is independent of the probability of attack.

Our recent Journal article illustrates this concept. Application security is made up of 4 factors: vulnerability, countermeasure, breach impact and compliance. Four principle factors that may detect application security risk are breach cost (Bc), vulnerability density (Vd), countermeasure efficiency (Ce) and compliance index (CI). CI is the ratio of a number of compliance requirements met with a total number of compliance requirements in the application. Vd is the ratio of the number of vulnerabilities to the size of software. Ce is the measure of implementation efficiency of countermeasures. Bc is the assessment of likelihood of cost that would be incurred in case of an attack. Figure 1 represents this model that evolved embodying the principal factors. The model considers Bc, Vd and CI as inputs and defines a benchmark, application security risk metric (ASRM), a measure for the risk of application security. Our Journal article illustrates the approach of designing the metric in detail.

Figure 1—Factors in the ASRM
 
Source:  Shubhamangala B.R . and Snehanshu Saha. Reprinted with permission.

Read Shubhamangala B.R. and Snehanshu Saha’s recent Journal article:
Application Security Risk,” ISACA Journal, volume 2, 2016.

Comments

There are no comments yet for this post.
Email