Presenting application vulnerabilities as business risks.

Technology has always been a double-edged weapon where in it helps organizations leverage on their business products in a quicker time to market on the one end and at the same time due to flexibility of approach to the customers, gives room for high threat on security and confidentiality of the business houses and their customers. This has invariably put the business organizations be extra cautious when it comes to the security of software applications.
The IT and Test managers recommend multiple testes to iron out security issues which are at times will be of significantly higher risk due to vulnerabilities, however most often the magnitude of the risk is not articulated by the business managers as they cannot view the customer and revenue implications due to these vulnerabilities. Furthermore, the Information security & risk managers also tend to lose out on the business case as there might be a process level gap in measuring the business risk arising due to vulnerability.
In order to bring out the actual magnitude of business loss, the first step is to establish the correlation between the potential or actual vulnerability and the associated business process. Once this is established, it becomes easy for the business and information managers to articulate the magnitude of the risks and associated costs to it. And hence, the first and foremost step is to understand closely the environment in which the vulnerability is being found ;
  • Identify and establish the business objective of the software application
  • Identify the miniscule components and associated business functions performed by those components
  • Define business transactions in an end to end perspective and identify all the associated software systems involved to process those business transactions
  • the (sub) system
After identifying the causes of the vulnerabilities, the next task is to assign the business processes corresponding to those system vulnerabilities. Recommended classifications of business functions are:
  • Operational Risks related to internal business processes.
  • Regulatory risks of non-compliance with applicable laws and regulations
  • Reputational risk related to the brand of the organization
Once the vulnerabilities and the corresponding business processes are mapped, the quantitative business risk model to be established. The driving factors to build the model to address the below constraints:
  • Detailed analysis of the technical architecture and the functionality of the system in which the vulnerability is found
  • Identifying the scoring model based on the risk and assigning the threat score to determine the likelihood of a threat
  • Impact assessment with standard methodology and frameworks suck as ISF or COBIT5
  • Plotting the quantitative risk index post impact assessment
  • The most predominant vectors that ignite the threat are: Natural threat agent: Fire, flood, power failures and others.
  • Unintentional threat agents: Parties that cause damage or loss of service without direct intent.
  • Intentional threat agent: Those parties that would knowingly seek to make a threat manifest.
  • Capability: Capability to conduct and sustain an attack or totally destroy the system and any replacement.
  • Threat catalyst: Those factors are actions that cause an attack to be initiated at the time and on the target selected.
  • Threat agent motivators: Factors and influences that motivate a threat agent.
  • Threat inhibitors: Any factors that decreases the likelihood.
  • Threat amplifiers: Any factor that increases either the likelihood of an attack taking place or being successful.

Finally assess the vulnerabilities and map the relevant business risk. For example:

Vulnerability 1: Software flaw in externally hosted web site.

Externally hosted website includes a software flaw that makes it vulnerable for injection of images that compromise the integrity of the organization. The relevant risk that the organization face is the “reputation risk”. This type of risk does not have a direct link to the business processes and should be addressed at an organizational level.

Vulnerability 2: Software bug in SQL statement:

This vulnerability can be treated to the business process, but also can be viewed as a separate regulatory risk category. Besides it can qualify as reputational risk.

Vulnerability 3: Software flaw that affects the network exposure.

The impact of this kind of vulnerability should be addressed by technical team using techniques like “fault tree” analysis to deduce the impact

Conclusion:

The swiftly changing customer demands and extreme competition, technology is the only way-out in order to achieve cost effective business continuity. This gives rise to interface of many trusted and untrusted sites and gateways for the smooth functioning of the business transactions. This invariably exposes the software applications to major threats and knowing this, the need for some method to distinguish between software vulnerabilities based on the level of business risk becomes the prime focus. Software vulnerabilities must be presented in a language that clarifies which vulnerabilities can have the highest negative impact on business goals. This enables a business manager to make an informed decision about which vulnerabilities must be mitigated first.