To define risks, learn where they come from, and what their effect on information assets and the operation of your company is, you will need to carry out a risk assessment. In this article we will talk about IT assets and risks. I’m not going to outline the organizational or preparational side of things, such as appointing a risk manager or setting up the assessment process. If you need to learn about the different aspects of defining a process, take a look at ISO/IEC 27005:2018.
There are a few different approaches to defining risk, but let’s explore the basics. The first thing you will need to do is define the scope of your information assets. Information assets are all assets which could impact on the confidentiality, integrity, and accessibility of information within your company.
There aren’t any strict criteria on how to assess this scope. The result should be a list of systems, applications, code, etc. which you need to define risks for.
Assets can be singular or grouped together to unify identical risks for a set of assets.
The simplest way is to make a logical list of systems and applications, grouping them by type. For example:
It’s worth taking into account that IT is assets that aren’t just the standard systems and applications with recognizable names, but also:
When grouping assets, you need to take into account the critical nature of the assets. For example, a service for ordering coffee in the office isn’t as critical as a customer support system. Obviously, you set how critical the system is as you see fit, taking into account that each risk can have different effects on different assets.
This article is not supposed to go into detail about how to define zones of responsibility, but it’s worth mentioning in short.
You need to define who is responsible for what: which employees or departments are responsible for which systems from a business perspective (i.e. responsible for the data and system processes) and which are responsible for the technical aspects (i.e. asset support and management). You also need to define who your users are and who assesses the risks. You can express the result using the RACI matrix:
This is necessary in order to define who will
The next step is to work with people in your company to define the damage that could become of the different risks coming to fruition.
Take a look at the table below to see an example of how this is done.
You can identify risks by combining the threats and vulnerabilities associated with each asset. Risks can be categorized by the type of impact they could have on a system or dataset:
Threats and vulnerabilities can be split into two types and this will help you define the impact level the risk will have on the asset and the overall applicability of the risk to a particular asset:
The risk that sensitive data could be stolen when being transferred across your network due to incorrect system configuration. For data being transferred within the company (internal threat), the effects of this risk coming to fruition are much less than if you were to transfer the data externally (e.g. to a cloud provider).
The most difficult part of all is defining and forming the list of risks. You can use the risks that are listed in standards such as ISO, PCI DSS, NIST, COBIT, etc. and adapt them to your own processes.
The domains you consider should include but not be limited to:
The possibility and frequency that a risk might be realized also affects your assessment. Let’s take a look at an example.
Unsanctioned access to internal systems which leads to the system admin password being exposed. However, you can only access the system by being on the company’s local network (where connection is only possible with a user certificate and set device) or via VPN that requires two-factor authentication.
As we can see, the actual impact of this risk on an asset is practically zero and you can either not even consider it, or mark it as a risk that you are willing to accept.
Now, let’s take a look at this risk in different circumstances. If we say this risk is prevalent for an external system in a cloud and with local authorization via http, then:
As you can see, the circumstances are something you need to consider when defining and grouping risks for assets according to type and critical nature.
Let’s take a look at some more examples in the context of a marketplace and consider their impact.
Neither the company’s site nor mobile application have undergone a comprehensive security review during design and implementation. In addition, there is no process of continuous security assessment (vulnerabilities detection) of the site or mobile application.
This may result in prolonged existence of exploitable vulnerabilities which may lead to the systems being compromised by an outside intruder and a leak of confidential data.
This would impact on:
If we consider the risks and outcome using the damage table above, we several have types of harm:
You should define the value of the damage and the impact in a way appropriate for your business.
The company’s disaster recovery plan is outdated and has not been tested for years. Given the moderate potential of an intruder breaching the systems, a combination of events may result in the inability to restore operations at the recovery site within an acceptable time frame.
The data integrity or data accessibility and harm will be:
When you have completed the process of setting and assessing risks, you should have a document/matrix/table which shows for each asset or group of assets:
