Vulnerability Assessment is more or less a standard activity across organization and across the globe for all large, small and medium enterprises. It is hygiene, compliance requirements or simple risk based approach to identify vulnerabilities both internet facing and internal systems and applications and patch them. The vulnerabilities generally arise out of inappropriate configurations, missing patches or inappropriate SDLC practices. The vulnerability management market has gone beyond simple tools to identify missing patches to complex Application Security Assessment including business logic review and software code review.

In this domain too, specific vendors like Qualys and Rapid 7 etc created an entire module to link assets within business groups, locations, distinguish them based on criticality and link vulnerabilities and security risks to them. This is followed by integration with Directory Services to track closures by users/ groups responsible/ owners of the systems; and hence aiding in not just identifying the vulnerability but also link it to assets and track closure and revalidate.

Taking a step back - if you see - vulnerabilities in systems are also a kind of risks but being assessed and treated in silos without any linkage with risks to business. Mostly, businesses do not understand the security terminology in its terms of risks. For example, what an SQL injection to an insurance application mean is difficult to make a business owner understand and therefore "input/ output" validation or parameterized query as a solution/treatment is unknown too. This creates lack of buy-in for security professionals to convince business to rework on their applications and reprogram it.

Hence, to club challenges of business linkage with vulnerability Management based on experience is as follows –

  1. No rollup view of vulnerabilities into business risk and no accountability
  2. Difficult to track the vulnerabilities and its closure
  3. Vulnerabilities identified against systems are in silos
  4. Linking change management with information security vulnerability management is missing

To counter this few firms like RSA Archer and Modulo allow importing of vulnerability information into GRC tools and link it with assets. But that too is just providing linkage to assets and tracking but no respite to the fact that how to make business understand the vulnerabilities as business risk and do prioritization and justify spending if required.

Secondly, linking change management, ticketing solution and patch management with security risk management is broken in its current form.

Hence, taking a view of GRC and linking some broken piece can solve this problem. The approach described is as follows –

  • Create a technology asset library, break it into OS, Application and Database as there are different custodians to treat risks to them and patch. Link the assets to business units and locations
  • Link assets with business processes, “classify” assets to identify its criticality, determine the function/ service provided by the system. The classification can provide us information for prioritization and its function and linkage to business process a detail understanding about business risks
  • Map vulnerability fields to GRC tool fields for mapping, for e.g. OS vulnerabilities shall be linked to OS custodian and goes to them.
  • Club vulnerabilities into risk categories, for example SQL injection and cross site scripting lead to “unauthorized access” risks
  • Based on criticality of the assets and risk associated from vulnerabilities, identify business risk. For example, the “SQL injection vulnerability” in an insurance application might lead to “change of insurance nominee” in an unauthorized fashion. Business understands business language. Secondly, the same unauthorized risk to an insurance application is not equally important if the vulnerability is in some internal knowledge portal application
  • Perform risk assessment of the identified “business risk” (unauthorized access due to SQL injection) due to vulnerabilities by defining probability and impact to compute risk score (ease of exploitation, remote execution, skill needed etc.). Herein too, the probability shall be based on existing controls, an application which require insurance beneficiary to be authenticated with 2 factor authentication with OTP shall be different then an application which allows self-service to do so
  • Prioritize risk treatment with appropriate treatment plans based on criticality of the asset and ease of risk materialization
  • Notify owners and custodians
  • Track the status of the vulnerability closure (risk remediation) using risk remediation workflow of GRC tool
  • Report based on business risk

The above steps shall link technical vulnerabilities to business risk, compute risk scores, prioritize vulnerability mitigation based on probability and impact and asset criticality and track the closure and provide dashboard.

Please drop your questions and feedback to me.

Author:

Chandra Prakash
Practice Head, Information Risk Advisory Services