Anatomy of a Risk Assessment

  • February 06, 2019

In his second article for FourthLine, Andrew Denley considers what Information Security professionals must cover within a risk assessment.


For the Information Security professional and Project Manager, Risk is our friend. Calculated by multiplying the Likelihood of and event by the Impact of that event we will have a numerical value that we can use to drive the strategic direction of a Security framework or Project. But before we make the simple calculation we must evaluate the other factors that will ultimately affect our report to the Board or Project Team.

In the world of Information Security we must, (as a minimum), consider: Threat, Threat Actors, Vulnerability, Intent and Capability. In the world or Projects we must, (in addition), consider: Cost, Resource and Supply Chain.

  • Threat: What might attack our network or project?
  • Threat Actor: Where is the Threat coming from? An individual, a rival, a criminal?
  • Vulnerability: How vulnerable to attack is our network? How vulnerable is our project from other projects or uncontrolled circumstances?
  • Intent: What do I believe the Intent to attack my network to be? Is my network a target?
  • Capability: Is the threat actor capable of attacking my network?
  • Cost: Do I have sufficient budget to run the Project to full completion given these other factors?
  • Resource: Do I have sufficient resource to manage the Project?
  • Supply Chain: How reliable are my suppliers?

If we have an established IT Network then very often our biggest threat is likely to be Internal. It is rare indeed to assess an established network architecture where there are no Firewalls, Anti-Virus, IDS or IPS nor procedures or policies to guide employees in good security. Unless our business is in the financial sector, Public Services, Industrial, Research or Charitable, then statistics show that the threat of a targeted cyber-attack is slim. We are much more likely to fall victim to opportunistic attack along the lines of a Virus or Ransomware attack and these attacks are only successful because of the employees. Our employees are always the weakest link. They are not, (normally), malicious but they may be stressed and don’t think what they are doing. Employees who have been with a company for a long time are far more likely to facilitate an attack because they have become complacent – “We’ve always done it this way!” – and is also known as ‘Normalisation of Deviance’ whereby incorrect actions are taken over a long period but because nothing bad ever happens, those actions become the norm and which is why, very often, risk remediation is simply User Training.

So when we start our Risk Assessment we must take time to think about all these elements and evaluate each one separately to ensure that our assessment is both appropriate and accurate.

We start, therefore, with each identified asset. For example a new Website and we adopt a methodical approach. We ask questions along the lines of:

  • Is the Website vulnerable to external threat and/or internal threat?
  • If a cyber-attack is launched against the site, will it withstand the common attack vectors, e.g. cross-site scripting or SQL Injection?

Once we have, (hopefully), established the threat and vulnerability. Next we look at the Likelihood of attack.

  • Is the business a target?
  • Is the business susceptible to opportunistic attack?
  • Has the business been attacked before?
  • Will the Website be on the open web or the deep web (i.e. listed or not listed on search engines – don’t confuse this with the Dark Net)?

Next we look at the Impact of a successful compromise of our Website:

  • If the site were to be compromised, does it allow access to internal databases?
  • If data is stolen, what would be the impact on the business, (reputation, customers, financial penalty, compensation, legal challenge etc.)?
  • If the site were to become unusable (e.g. subjected to a DDOS attack will the business be adversely affected?

So now we have evaluated the Likelihood of attack taking into consideration the possible threats and the vulnerabilities to those threats and the impact should the attack and compromise be successful. Thus the calculated Risk Score will be accurate based on available knowledge. If the Risk Score falls within the business or project Risk Appetite, (that is the level of Risk that can be accepted without any further action), then we’re good to go. If, however, the Risk Score is higher than the Risk Appetite then we must mitigate the Identified Risk with remedial action.

The Information Security professional has four primary Mitigations at their disposal:

  • Reduce
  • Accept
  • Remove
  • Transfer

The simplest way to remove a risk is to stop the project. But this is rarely acceptable unless other actions are just financially unviable. We can accept the risk and often this is an agreed mitigation as the business benefit may still outweigh the risk. Transferring the risk may be expensive but for some areas of technology can be very beneficial as it effectively removes the risk from the parent company and becomes part of the Risk Management for a dedicated company. For example, off-site hosting and management, in the case of a website. This leaves us with the most common mitigation of reducing the risk. To achieve this we can try and make our website less vulnerable to attack thus reducing the likelihood of a successful compromise. Once we have decided on the appropriate mitigation then we then put in place the remedial controls to affect that mitigation, for example: If the Website leads to a database we could improve the security controls behind the site thus further reducing the likelihood of a compromise or even the Impact if for example, the attacker is unable to access any data.

When all our assets have been assessed and all remedial action, appropriate to the mitigation, has taken place then we recalculate our Risk score using the revised figures we have applied to the Likelihood and Impact. This final score is the Residual Risk and this is the value that is tracked as part of our overall Risk Management strategy.

Written by Andrew Denley

With more than thirty years’ experience in technology, Andrew has worked in a variety of industries including Maritime, Research & Development, Central Government, Business and Consultancy. Trained as a Maritime Electronics and Radio engineer he has diversified as Information Technology has advanced and has spent the last ten years specialising in Information Security and Data Protection. He is a qualified Risk Practitioner, GDPR Practitioner and ISO27001 Lead Auditor and has considerable experience in CLAS-related Security, Cyber-Essentials and NIST Information Security. He has co-written a technical guide to GDPR aimed at the non-European market which is due to be published in late 2018.

Find Andrew on LinkedIn.



£ k