How many ways can we assess risk? A lot, it turns out. In today’s world of recurring terrorist and hacker attacks, data breaches and identity thefts, and the other sources of threats that we all face every day, it should not be surprising that the art of risk assessment has become another multi-headed hydra for security professionals to wrestle with. I want to cover just a few high points with regards to risk assessment in this article. I know! I am leaving a lot out but I am addressing some key points for now (watch for future articles).
Risk assessment is typically defined as “a systematic process of evaluating the potential risks that may be involved in a projected activity or undertaking”. In Information Security terms, risk is the evaluation of potential threats, their associated likelihood and possible impact; calculated to reveal the inherent risk which is then measured against any implemented mitigation to produce the residual risk rating. It all sounds so simple, doesn’t it? Ok, maybe it doesn’t sound so simple but it gets even more complicated when you actually try to apply it!
Let’s start with the easy stuff: Business Continuity and Disaster Recovery Plans. Risk calculation as it is associated with this topic area is centered around what can go wrong in a disaster situation. So, threats for BR and DR would include things like hurricanes, earthquakes, fires, pandemics, chemical spills, etc. In addition, risk associated with the continued operation of the various business units of the organization in question, need to be assessed. A Business Impact Analysis (BIA) and a Hazard Vulnerability Assessment (HVA) are two pieces of the type of risk assessment that is associated with this topic. FEMA, Homeland Security, ISO22301 are some of the sources for these types of assessments.
Privacy is also of prime importance in security today; to assess risk related to the proper handling and management of personal or private information, a privacy impact assessment (PIA) is run against any new or modified process or project that might involve such information. National, regional or local privacy laws or regulations are required and experience in applying these laws and regulations is necessary to conduct the PIA.
When it comes to security when dealing with third parties, a Third Party Assessment or due diligence (what I abbreviate as TPA) should be conducted. SIG and SIG Lite are examples of structured methodologies for part of this process but, in addition to the SIG RA type of assessment, a complete assessment should include background and informational checks on the third party as well.
Finally, there is the standard Risk Assessment as defined by the ISO standards on security, PCI-DSS, SOX, ITIL, and many other standards and frameworks for security. An RA can be run on an organization or business process level, on IT functions, and on projects or deliverables. There are lots of frameworks for running these types of Risk Assessments depending on what you are assessing and at what point in time. Don’t worry, I have not forgotten TRA’s! Threat Risk Assessment is a relatively new term that I have seen bandied about of late. Given that every single type of risk assessment includes, of necessity and by definition, the threats that can be a source for exploiting vulnerabilities, the name “Threat Risk Assessment” seems redundant and, based on every version of TRA that I have seen to date, it appears to me that it might be redundant in more than just its name since any TRA that I have seen is basically a risk assessment with a new fancier sounding name.
Hope this has helped demystify some common risk assessment types!
Anthony English, with Mariner Innovations, is one of the top cybersecurity professionals in Atlantic Canada. Anthony has extensive Canadian and International experience in cybersecurity covering risk assessment/management/mitigation, security testing, business continuity, information security management systems, architecture security reviews, project security, security awareness/lecture/presentation and standards based compliance.
