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.
Defining your assets
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:
- HR systems, like BambooHR, Zoho, Workable, etc.
- Security systems, like IPS, SIEM, Nexpose, etc.)
- Communication systems, like Slack, Facebook workspace, Google meet, etc.
- Access control systems, like PACS, CCTV, etc.
- Business support systems, like Google Workspace, MS AD, LDAP, etc.
It’s worth taking into account that IT is assets that aren’t just the standard systems and applications with recognizable names, but also:
- In-house systems
- Your code
- Employee workstations
- Your network and its components
- Software licenses
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.
Zone of responsibility
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:
- (R) Responsible
- (A) Accountable
- (C) Consulted
- (I) Informed
This is necessary in order to define who will
- Identify assets
- Support assets
- Assess critical nature of assets
- Assess damage (consequences)
- Process risks
- Administer processes for information risk management
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.
Identification of risks
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:
- Internal (within your security or network perimeter)
- External (outside of your company’s perimeter
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:
- Access and role management
- Change and development management
- System backup and recovery
- Password security
- Vulnerability management
- Privileged account management
- Third party management
- Physical security
What else affects risks?
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.
In this case:
- The chance that this risk will be realized is low
- The possible frequency of this risk being realized is low
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:
- The chance that this risk will be realized is high because the admin password is transmitted across an open channel and there is no additional security applied to the admin account
- The possible frequency of this risk being realized is high because the system is accessible from anywhere with an internet connection
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:
- Data confidentiality (misconfiguration in authentication form that grants access to client data)
- Data and application integrity (vulnerabilities like an SQL injection)
- Application accessibility (e.g. DDOS vulnerabilities)
If we consider the risks and outcome using the damage table above, we several have types of harm:
- Reputational damage — Moderate
- Idleness or inefficiency in service operation — Low
- Contravention of laws and regulations — Moderate
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:
- Financial loss – High because it’s very harmful for a marketplace to lose all of its customer data; the company will lose money if customers won’t be able to order goods.
What comes out the other end
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:
- Employee zone of responsibility for assets
- Critical nature of assets
- Definitions of damage types and a qualitative measure of the damage
- List of risks (based on internal and external threats), with each risk linked to specific assets or groups of assets
- Applicability and potential impact of each risk on different assets and the potential damage that could be incurred if the risk were to be realized, taking into account the possible frequency of such an event taking place