‘Cyber’ is a word we use all the time. But what does it mean? What are the implications for us as directors and general managers? Or as IT security managers and auditors?
‘Cyber’ is thought to derive from the older term ‘cybernetics’ – based on electronic/mechanical control systems and the degree to which man-made and human worlds interact. Cybernetics is derived from the Greek word ‘kubernan’ – to steer or control. Kubernan is derived from the Greek word ‘kubernetetes’ – or steersman. So, we can think of cyber as the balance of control between humans and computers. It is now usually understood to cover most things computer/IT/Internet of Things (IoT) related.
This ‘control’ aspect is often overlooked. One of the reasons for this has been technical deafness on the part of business – they hear the words but zone out until the concepts of profit or loss/cost reduction are mentioned, and then tend to focus just on those. IT professionals have been more interested in bits and bytes and other exciting techie stuff. One of the exciting aspects of cyber is that these two worlds of business and technology management have started to merge. Partly because of a growing awareness of the threats facing cyber reliance, and partly as a response to increased pressure from regulators, the media and other agencies. What both tribes now need is a go-between.
It’s about balance: how do we continue to safely and confidently enjoy the benefits of our modern life – instant communication, and the ability to order goods and services whenever and wherever we want, having checked our bank balances and socially networked all of our friends to brag about our purchases.
The aim of governance, risk and compliance (GRC), according to SAP GRC for Dummies, is to:
Efficiently put policies and controls in place to address all its compliance obligations while at the same time gathering information that helps proactively run the business.
However, GRC is more than that. It is not just about ensuring compliance obligations are met, but also about providing assurance that significant risks that could impact the future viability and profitability of the organisation have been addressed. Increasingly this includes the reliance on information and cyber activity.
The preceding definition does partly explain why IT security professionals are sometimes opposed to GRC. It is seen as an overhead that does not provide business benefit and can get in the way of what they are trying to achieve. The irony is that this is exactly how project managers, IT service providers, and other information/IT managers see IT security/cyber management. They consider them as blockers rather than enablers. GRC should be seen as an opportunity to promote good cyber governance throughout an organisation in order to provide an effective foundation for cyber security.
The purpose of this book is therefore to provide an effective and efficient framework for cyber GRC. Like all frameworks, it will need to be adapted for each organisation to meet their own risk appetite and synchronise with their GRC policies, processes and tools. The book explains what is meant by GRC, how it applies to cyber and what is required to implement effective cyber GRC. Its aim is to guide managers and executives without resorting to ‘cyber-babble’; any feedback on whether it achieves this is welcome. The book will be of interest to non-cyber specialists, including non-executive directors, who may be required to review cyber arrangements. For cyber specialists, it provides an approach for explaining cyber issues in non-jargonistic, business-based language.
CHAPTER 3: CYBER SECURITY RISK MANAGEMENT
Introduction and overview
We all take risks every day. Life is a risky business. But without risk there is no progress. The same applies to organisations in the cyber world: there are risks of hacking, fraud, state interference and identity theft. But these have to be matched against risks of not doing business via cyber (e.g. failure to win new customers or reduce costs). The risks are great but so are the potential rewards: competitive advantage, reduction in costs, increased awareness of your products and services via social media, to name but a few. These risks can be managed in the same way you manage the daily risk of driving – by controls (ensuring your car is roadworthy and that you wear a seat belt, and having it serviced by a qualified technician), by following the rules (speed limits) and by insuring against the unknown risks that you cannot prevent. Every organisation needs to have a process for managing cyber risks.
The process and terminology will vary between organisations, but the basic steps are likely to be as shown in Figure 2. Wherever possible, they should also be followed for cyber. They will help ensure that risks are stated in a format and style that business managers and executives can relate to.
Figure 2: Risk management process
The objective, key activities and deliverables for each of these steps is described below. We will also consider how the risk management process can be made more agile.
Risk management scoping
When undertaking a risk management review, it is important to ensure that the scope is understood and agreed so that there are no gaps or duplication of effort.
For cyber, we need to ensure that all risk assessments are conducted to the same level of detail, based upon the risk appetite of the organisation, otherwise:
- Controls may be defined at too fine a level of detail, leading to extra effort with little or no reduction in the risk profile; or
- Risks identified as strategic for the organisation may not be covered adequately. For example, strategic risks relating to sensitive geographic operating locations or trading in restricted parts of the world could have cyber implications that need to be considered.
The main activities will be:
- Identifying relevant strategic risks, based on the enterprise risk strategy and level of risk appetite determined by the key stakeholders;
- Agreeing the processes, technology and locations in scope, and whether to include activities of third parties/the supply chain;
- Identifying any known incidents or risks specific to the review;
- Identifying all stakeholders, people, procedures and technology to be included in the review; and
- Determining the legal and other regulations that must be considered during the review.
The deliverable from the scoping exercise, which may be from a workshop or a series of meetings, will be an agreed scope, a high-level plan and background notes. To reduce the risk of scope creep or change during the exercise, this documentation should be reviewed and approved by all key stakeholders before the work starts.
1.1 Process and control mapping
Documenting the process and related controls helps confirm understanding and ensure that the controls are located at the point of risks so that any errors or attacks can be identified effectively and efficiently. If controls are located too far into the process, this can lead to additional, unnecessary corrective work. The documentation does not need to be too detailed – the aim is to consider the end-to-end process and identify key inputs, outputs and sub-processes. Often this documentation can be prepared following interviews, reviews of existing documentation, and workshops. The key step is to walk through the process and controls wherever possible to confirm understanding and identify any potential variations. For example, if we were looking at access controls for a new cyber application, we may consider whether they will work the same way for all devices/platforms. This step can also ensure that the documentation is accurate and easy to follow, and can highlight where additional documentation may be required to help users undertake key steps.
Output from this phase will be process maps and documentation. The format and tools used to generate these vary between organisations.
1.2 Risk assessment
A risk assessment can now be performed to identify key weak points in the process where error or attack could occur. This may also include considering known vulnerabilities for the technology. Key questions to ask for each process step are:
- What could possibly go wrong?
- How likely is it?
- Does it matter – what’s the impact?
- Are there any existing mitigations in place (consider TRAM (transfer/reduce/accept/mitigate)) and if so, are they adequate for the level of risk?
To provide clarity when describing risks, the following formula can be used:
X happens because of Y, leading to Z
For example:
The main way of classifying IT risks is using the initialism CIA (M):
- Confidentiality
- Integrity
- Availability
- Management
These will be explained further in the next chapter.
Where a control is in place, this should be reviewed against the identified risks to consider:
- Is it a detective control to identify an error or attack, where a preventive control would be better?
- If operated properly, would it fully mitigate the risk?
- Is it operated effectively?
- Is it redundant – where, for example, another control already fully mitigates the risk?
The output from this step may be in the form of a risk and controls matrix (RACM). The RACM is a spreadsheet-based document that contains details of the risk and control and can include details such as frequency, location, etc. It should also include details of observed control gaps and weaknesses.
This is an extract from How Cyber Security Can Protect Your Business – A guide for all stakeholders
©IT Governance Publishing Ltd
Understand how a strategic approach to cyber security can benefit your organisation
This book provides an effective framework for managing cyber governance, risk and compliance, which organisations can adapt to meet their own risk appetite and synchronise with their people, processes and technology. It explains what is meant by governance, risk and compliance, how it applies to cyber security and what is required to implement an effective cyber security strategy.
