1. Introduction
1.1. Aims and Terms of Reference
The Cyber Risk Investigation Working Party is a subgroup under the Institute’s ERM committee. The group was established as a forum for actuaries to share insight and research, and to respond to cyber risk developments within the industry.
The group aims to support actuaries working on realistic capital calculations and/or within enterprise risk management for life and general insurers. In particular, the purpose of the research is to provide insight into setting out potential impacts of cyber events and the measures available to mitigate such risks.
The initial research conducted by the group focussed around deriving specific cyber risk scenarios that can be referred to when determining operational risk capital requirements for insurance companies. This was deemed to be a significant emerging issue given the ever-increasing dependency on data and information technology to support the business operations of insurers. Given the multitude of possible permutations for insurer type versus scenario narrative, the group quickly began to focus more generally on developing a proposal for a framework within which to build appropriate scenarios.
This paper aims to drive greater awareness of cyber as an operational risk for insurers through a proposed framework for scenario development and three worked examples. The three worked scenarios modelled within this paper are as follows:
∙ employee leaks data at a general (non-life) insurer (set out in section 3.4);
∙ targeted ransomware attack on a life insurer (set out in section 3.5); and
∙ motor insurer telematics device hack (set out in section 3.6).
1.2. Definition of Cyber Risk
Cyber Risk is the risk of any financial loss, disruption or negative reputational impact because of a failure in information technology systems; whether through people, process or technology. According to the CRO Forum (2016), cyber risk covers:
∙ any risks emanating from the use of electronic data and its transmission, including technology tools such as the Internet and telecommunications networks;
∙ physical damage that can be caused by cyber-attacks;
∙ fraud committed by misuse of data;
∙ any liability arising from data use, storage and transfer; and
∙ availability, integrity, and confidentiality of electronic information – be it related to individuals, companies or governments.
The risk is dependent upon the malicious (or non-malicious) threats the organisation faces and how organisations mitigate the risks through business and strategic decisions.
This paper does not consider cyber underwriting risk but rather the cyber risks that an insurance organisation is exposed to (i.e. operational risk).
2. Methodology
To drive greater awareness of cyber as part of an operational risk for insurers it is important to define and introduce a framework of analysis within which scenarios can be developed in a consistent manner. This section of the report proposes such a framework.
Each scenario set out in section 3 has been designed and assessed in a consistent manner within this framework.
2.1. Defining a Common Taxonomy
A common taxonomy is of critical importance in ensuring consistency in the design and parameterisation of scenarios relating to cyber risk. There is a range of publicly available material aiming to bring consistency to this discussion. This paper highlights two specific sources of material:
• CRO Forum Concept Paper on a proposed categorisation methodology for cyber risk (CRO Forum 2016).
• NIST framework (National Institute of Standards and Technology 2018).
The taxonomy used within this framework has been created by leveraging information from these two sources.
2.1.1. Cybersecurity assessment taxonomy
The National Institute of Standards and Technology Cybersecurity Framework (“NIST framework”) has been developed to provide standards, guidelines and best practices to manage cybersecurity-related risk. It provides a guide for US private sector organisations to assess and improve their ability to identify, prevent, detect, respond, and recover from cyber-attacks. A Gartner report cited that 30% of US companies have adopted the NIST framework with 50% expected by 2020 (National Institute of Standards and Technology 2016).
Given the NIST framework is focussed on providing guidance for ensuring cybersecurity resilience this research group has leveraged this work to define the cyber security vulnerabilities taxonomy.
The Securities and Exchange Commission “SEC” has stated its preference that NIST should be used as the standard for Cyber Security assurance for organisations which contribute to critical national infrastructure (Clayton Reference Clayton2017). It has expectations that companies meet the basics of this framework for regulatory purposes.
Within this framework of analysis, we have relied upon v1.0 of the NIST framework released in February 2014. It is worth noting that v1.1 was released in April 2018. The working party has reviewed the ‘Notes to Readers on the Update’ section of the accompanying report and determined that the updates do not have a material impact on this paper.
2.1.2. Cyber incident taxonomy
The CRO Forum concept paper (Figure 1) proposes a methodology for a categorisation of cyber risk. The aim of the paper is to assist with data capture for cyber incidents. In particular, the concept paper proposes categorisations for:
∙ cyber incident;
∙ event type;
∙ root causes;
∙ threat actors; and
∙ impact type.
Figure 1 CRO Forum concept paper; a proposal for cyber categorisation
Although the original aim of the concept paper was to support claims data capture, the categorisations have been useful when considering the design and corresponding economic impact of the operational scenarios presented in this paper. The CRO Forum categorisations have therefore been leveraged as the basis for the cost/impact taxonomy used within this research group’s work.
2.2. Designing a Scenario
Given agreement of a common taxonomy (as set out in section 2.1), operational risk scenarios can be developed consistently within a simple framework. A proposal for such a framework is set out in the remainder of this section. It is worth noting that this framework is independent of any individual scenario; examples of how to implement this framework are detailed in section 3.
When defining a scenario, the organisation should first define their view of cyber risk (see section 1.2 for the working party definition) and consider how any tangible or intangible losses could arise from failures in their cyber-related processes. A key part of this assessment for an insurance organisation is to consider high-value assets and/or or key weakness/dependencies that could lead to a significant business impact if a cyber risk were to materialise. A precursor to defining a cyber-operational risk scenario is having an accurate understanding of organisational maturity across all the fields in the NIST framework. Once the key tangible and intangible assets of the organisation are defined, relevant scenarios can be developed to understand the impacts of the key threats to the company. Some of these key considerations are discussed in the following sub-section.
2.2.1. Scenario selection
When designing an operational risk scenario, it is important to think through a range of factors relevant to the scenario including, but not limited to:
• structure and size of the company e.g. national/global;
• types of insurance products written;
• IT systems used within the business including dependencies/contingencies in place and third-party dependencies;
• volume and use of data stored within the company including internal data warehousing process and maintenance (e.g. are old records deleted/duplication of records, etc);
• type of data records stored (e.g. Personally Identifiable Information or ‘PII’, Payment Card Information or ‘PCI’, Protected Health Information or ‘PHI’);
• assessment of the company’s current cyber resilience (useful to reference the NIST framework);
• current global cyber threat landscape, e.g. active threat actors and prevalent threat vectors if applicable. Consider who and why different threat actors may want to attack you directly or whether you may be indirectly exposed to collateral damage from attacks on others e.g. NotPetya;
• company specific cyber threat landscape, i.e. existence of factors which increase the motivation for a cyber-attack; and
• legal and regulatory framework the company is governed by.
Given the uncertainty, changing landscape and complexity of cyber risk it is recommended that key stakeholders from around the business should be consulted when considering the design and materiality of scenarios. This might take the form of workshops. The following is a non-exhaustive list of stakeholders who might be included:
• ERM;
• head of IT;
• CISO;
• procurement;
• cyber underwriter;
• legal;
• HR;
• board members;
• internal audit;
• supplier manager;
• COO; and
• business department heads.
The scenarios selected for quantification within this paper are detailed in section 3 of this report. A useful position to start is to consider near missed events such as NotPetya/insider data leaks and consider how these could have caused a significant impact on the organisation.
2.2.2. Assessment against the NIST framework
Each scenario is assessed against an aggregated NIST framework that includes a total of 22 control categories across the five core functions; Identify, Protect, Detect, Respond, and Recover (details of the control categories used are set out in Appendix 2). For a given scenario, the following steps are then taken for each control category:
1. Consideration is given to whether or not a control category is relevant to the scenario.
2. Assessment of cost types which could be impacted by failure of the given cost category.
3. Qualitative assessment of potential impact of the event of failure of a control; consideration is given to both frequency of event and severity of event.
This exercise is uncertain by nature given the subjectivity involved. The purpose of this assessment is to help focus the outcome of the scenario; in particular the potential for scalable costs and areas of mitigation.
2.2.3. Costs estimation approach
Once the cost types impacted by the scenario have been identified, the next step is to quantify an estimate of each loss amount. Estimation is completed through group discussion with reliance placed on members’ own experience and understanding of losses. For each identified cost type, the following sources of information have been used to inform the calculations:
• database of prior events (e.g. NetDiligence, Ponemon, Verizon);
• publicly available reports; and
• expert judgement.
2.2.4. Mitigation assessment approach
There is no quantitative assessment of the impact of potential risk mitigation mechanisms due to the uncertainty associated to the cost estimates and likelihood of breaches. However, a qualitative assessment is performed against the NIST framework to identify which areas and controls would be most relevant to focus mitigation efforts to ensure reduction of the potential risk of the event.
The approach taken within this exercise is to identify the high-risk control areas and summarise what reasonable mitigation attempts would look like. A more detailed assessment would include quantification of the impact each mitigation mechanism would have on each cost estimate. An assessment would also need to be completed to understand the cost-benefit analysis of these techniques against alternative risk transfer mechanisms such as insurance policies.
3. Scenario Analysis
Section 2 of this paper sets out the working party’s proposal for the framework within which cyber operational risk scenarios can be developed. Section 3 provides working examples of implementing this framework; detailing three scenarios including narrative of the event and estimated costs.
It is worth highlighting that there is a vast range of potential cyber operational incidents and some resulting costs are largely untested and therefore uncertain (e.g. GDPR fines). The example scenarios set out in sections 3.4–3.6 should be seen as illustrative examples rather than a robust model for readers to use blindly.
Each scenario team worked independently during the parameterisation process, which highlighted differences in views around impacted cost types and quantification. While an exercise has been conducted to ensure reasonable consistency between scenarios, any apparent differences represent the underlying uncertainty inherent in this risk and the fact there is currently no clear single industry-wide consensus on how the risk should be approached.
3.1. Scenarios Selected
The following scenarios were selected for the purpose of this paper:
∙ employee leaks data at a general (non-life) insurer (see section 3.4);
∙ targeted ransom attack on a life insurer (see section 3.5); and
∙ motor insurer telematics device hack (see section 3.6).
The three selected scenarios were selected from an original set of seven through group discussion. They were selected as being the most relevant scenarios to the insurance industry from an operational risk perspective given the current risk climate. All scenarios considered are detailed in Appendix 1.
3.2. Return Period
For the scenarios in this paper, we have chosen to target a 1 in 200 year event measure for each hypothetical company given that operational risk scenarios for capital purposes would generally aim for an event at this return period (in line with Solvency II). Given the significant uncertainty in estimation (lack of historical/public data), we consider the events discussed to be extreme but plausible and that the range around the estimate would be significant depending on the company, jurisdiction and market conditions.
The working party would encourage the reader not to place sole focus on the specific numbers reported in the following sections. The key takeaway is intended to be the framework and methodology for constructing such scenarios with the intent of equipping the reader to produce scenarios relevant to their own business.
The working party also recognises the difficulty in rationalising a 1 in 200 year scenario and thus readers should also consider creating and analysing scenarios at more frequent return periods, and then extrapolating.
3.3. Expected Cost Calculations
Estimated costs have been derived using a combination of research of current consultant rates, historical events, and expert judgement. References have been provided where appropriate and it can be assumed that expert judgement was applied where no reference is provided.
It is worth noting that some costs are likely to be variable by the size of the company (e.g. compensation depends on customers exposed) while some other costs may be considered more fixed (e.g. some regulatory fines or consultancy costs dealing with the incidence & response). Readers of this document should assess the appropriateness of each cost estimate given the characteristics unique to their business.
There is significant potential for economic impacts on insurers beyond those which would form part of the operational risk capital charge (e.g. loss of future sales). While this report focusses on those costs forming the capital charge, Scenario 3.5 looks in more detail at some of these other costs due to the potential materiality to the insurer in that given scenario.
3.4. Employee Leaks Data at a General (Non-life) Insurer
3.4.1. Scenario
A general (non-life) insurer writing a diverse business including a large motor portfolio is hacked by an internal staff member. Details of all motor insurance policyholders are leaked onto an Internet website and are widely available.
3.4.2. Description of the insurer
The insurer has a global presence, with over £10bn in revenue. The UK motor insurance book is a major unit of the insurer, with £1bn annual premium. The UK motor insurance portfolio contains 4m data records, with 3m policyholders on risk and 1m legacy records.
3.4.3. Event narrative
An employee had a poor working relationship with their manager (Figure 2). Low morale led to resentment and the employee decided to take harmful action. The employee published all motor insurance policyholder data online, both financial and non-financial. They accessed financial data including credit card information by persuading other employees to give access a few weeks’ earlier using social engineering techniques. The data leak was noticed by a policyholder who called the emergency claims team. This did not get escalated appropriately and it took another day before key staff members were aware of the data breach.
Figure 2 Incident summary for employee leak scenario
Slow response and poor communication with the public led to a backlash from policyholders who took to social media to vent their anger. Employees also shared their opinion on social media around poor working practices. Investors, concerned at the poor controls in place and potential reputational damage to the remainder of the business, sold shares resulting in a 5% drop in share price overnight.
3.4.4. Security assessment and mitigation
Figure 3 displays the assessment of this scenario’s vulnerability across the NIST framework for the impact on frequency and severity of the event and indicate that the following control areas are expected to be the key vulnerabilities for this scenario:
∙ protection e.g. access controls, data security and information protection processes; and
∙ respond e.g. response planning, communication and improvements.
Figure 3 NIST framework assessment for employee leak scenario
3.4.5. Expected costs
Table 1 summarises the expected costs considered relevant to this scenario. The costs presented are only estimations of the potential magnitude given the specified parameters of this scenario.
Table 1 Expected cost summary for employee leak scenario
This scenario represents a cost of approximately 2% of the company’s total revenue. Following an employee data leak we would expect there to be a reputational impact to the company that would impact future business and potentially the share capital. For motor insurance, we consider it unlikely that there would be significant lapses for in-force policies following the event, however there may lower renewal and new business rates at renewal period. Hence reputational damage may occur and will depend on the PR handling by the company and/or remediation efforts following the event but, for this scenario, we have not quantified any short-term reputational damage to premium volumes.
The key drivers of expected loss within this scenario are regulatory fines and compensation. It is worth highlighting the heightened uncertainty around the GDPR fines given that the legal and regulatory environment is currently untested. For the purposes of this scenario, a worst-case outcome was assumed and hence the mitigation actions proposed would help to manage the risk.
3.4.6. Mitigation
The impact and ability to mitigate the risk is dependent on the following key areas (as labelled in the NIST framework):
∙ protect and
∙ respond.
Table 2 summarises some of the possible mitigating actions that could be taken to limit the potential risk associated with this type of scenario. For this scenario, the protection controls are those likely to have the greatest mitigating impact (in terms of both the likelihood and the severity) on the potential losses facing the company.
Table 2 Proposed mitigation approach for employee leak scenario
It is worth commenting that data breaches could occur in several different ways, such as an external hack. It is likely that these scenarios would produce different loss estimates, and different recommendations on how to mitigate the risk (such as the need for penetration testing and security around third-party vendors). Although less likely, internal threats may have a greater financial and reputational impact to a company, as evidenced by the Morrison’s case (Paatz Reference Paatz2018). At a 1 in 200 return period, we would want to consider more extreme events and hence have focused on internal threats.
3.5. Cyber Extortion at a Life Insurer
3.5.1. Scenario
A life insurer is subject to a ransomware attack following a successful targeted spear-phishing campaign by hackers.
3.5.2. Description of the insurer
The insurer is a subsidiary of a FTSE100 listed financial services group. It has gross written premiums of £3bn, and an annual profit of £300m.
The company has historically relied on legacy IT systems to manage its customer portfolio data, but has recently begun an IT transformation programme to modernise its systems. It has agreed an outsourcing arrangement with a data services company to develop, test, maintain, and support new technology applications, both during and after the transformation phase. Back-up systems are linked to the core systems to allow for continuous back-ups.
3.5.3. Event narrative
A group of hackers carry out a co-ordinated series of attacks against the insurance companies via a sophisticated and tailored spear-phishing campaign (Figure 4). This allows them to obtain employee logins and passwords for corporate systems. The insurer in question is one of the targets. For this company, the hackers go undetected for several months, during which they use these credentials to move laterally throughout the corporate network and are able to identify the new back-up procedures and stored backup files.
Figure 4 Incident summary for cyber extortion scenario
The ransomware worm is then delivered covertly and infects almost all of the insurance company’s systems including both production and backup environments.
Upon launching the attack, operating systems become unavailable; critical systems and services are inaccessible and data is encrypted. In effect all operations grind to a halt. A request for a ransom payment of £15m is received to unlock all systems.
The firm calls an emergency management meeting and decides that given the dire situation of all systems and data including backups, being subject to the ransom the best course of action is to pay the ransom. Following investigations, the company identifies the critical systems held to ransom and a revised ransom figure of £7.5m is paid to the hackers. However, unexpectedly; the payment of the ransom does not result in the decryption of data. It is not known whether that was the intention of the hackers or not, but the resulting impact is that a huge data recreation, malware decontamination and IT systems restoration effort is needed. As the insurer is still in the middle of the IT transformation project, the restoration work is far more complex.
The incident has a huge impact on the firm’s business through interruption and increased cost of working as many employees cannot do their jobs and are sent home. The media focuses on the poor internal controls of the firm, in particular that the lack of network segregation led to the ransomware worm spreading quickly across the network. The reputational fallout is catastrophic as many customers are not able to check their balances, let alone conduct any transactions, and the firm suffers a significant drop in sales as well as regulator scrutiny.
3.5.4. Security assessment and mitigation
Figure 5 displays the assessment of this scenario’s vulnerability across the NIST framework for the impact on frequency and severity of the event and indicate that the following control areas are expected to be the key vulnerabilities for this scenario:
∙ detect, e.g. security continuous monitoring and detection processes;
∙ respond, e.g. analysis, mitigation and improvements; and
∙ recover, e.g. recoverability and communications strategy.
Figure 5 NIST framework assessment for cyber extortion scenario
3.5.5. Expected costs
Table 3 summarises some of the expected costs for this type of scenario. These costs are only indications of the potential magnitude of each cost area for the specified parameters of this scenario.
Table 3 Expected cost summary for cyber extortion scenario
This scenario represents a risk capital charge of approximately 6% of the company’s total revenue. However, it is important to note that this excludes any impact from a data breach scenario, which is dealt with in section 3.4, though hackers could steal as well as corrupt data.
The key driver of expected loss within this scenario is business interruption combined with regulatory fines and compensation costs, this scenario could give rise to severe losses. For this scenario, significant improvements in the ability to segment critical systems, improve defences and promptly detect unauthorised behaviour are critical to the outcome. The mitigation actions proposed would help to manage the risk.
As well as the losses above, the reputational damage resulting would give rise to loss of future sales in addition to those losses that typically make up the Solvency Capital Requirement. Nonetheless, these result in significant additional economic impacts on the insurer which have been explored in Table 4.
Table 4 Additional expected cost summary for cyber extortion scenario
3.5.6. Mitigation
The impact and ability to mitigate the risk is dependent on the following key areas (as labelled in the NIST framework):
∙ detect;
∙ respond; and
∙ recover.
Key mitigation actions include network segmentation, patch controls, vulnerability scans, i.e. having appropriate detection processes and testing in place to help to identify the leak early on, ensuring the situation can be tackled as it arises and therefore reducing the impact of any attack. In addition, it is important to have an incident response plan in place, covering areas such as a decision tree for payment of ransom, a communications strategy and consideration for any external support which could be required to assist with the resolution of any incident.
Circuit breaker back-ups could help to mitigate impacts. This works through one of a pair of back-up systems being connected to main systems, with the other not being connected at all; then switching over. This stops the back-up system becoming infected.
Staff should receive training to make them aware of phishing attacks and assist them in identifying and flagging potential attacks. I.T. systems should scan incoming communications to try to eliminate or quarantine potential attacks.
Table 5 summarises some of the possible mitigating actions that could be taken to limit the potential risk associated with this type of scenario.
Table 5 Proposed mitigation approach for cyber extortion scenario
3.6. Telematics device hack at a motor insurer
3.6.1. Scenario
A motor insurer deploys telemetry in customer vehicles for measuring driver patterns using a specific telemetry device. A security researcher publicises a hack on this device that allows anyone with Internet access to remotely access images from the camera of the telemetry device as well as the location and PII data on them. The insurer needs to recall/replace/replenish the device with each of its clients.
During the course of the recall, a number of hostile hackers break into the devices and publish data including locations, pictures, and journeys of high profile policyholders who have installed the devices in their vehicles.
3.6.2. Description of the insurer
For this scenario, we have assumed it will affect a medium sized UK only motor insurer with many motor insurance policies issued using telematics devices.
The insurer has premiums of £400 million p.a. with a fleet of 500,000 cars using its telematics device. There is an average premium of £500 per annum per client for the telematics product, resulting in c£250m premium p.a. for the telematics product.
3.6.3. Event narrative
All 500k telematics devices get hacked, rendering the devices (costing c£50 each) unusable or untrustworthy (Figure 6). Every device needs to be recalled and replaced.
Figure 6 Incident summary for telematics device hack scenario
Sensitive data from the devices are compromised and published online; including places visited, camera images and policyholder names. The data held by the devices is deleted or inaccessible and ongoing driver usage is not captured, resulting in 3–6 months’ driving data being unavailable. These data would normally be used by the insurer to determine the risk charges/premiums for the insurance product. (Note that an alternative adverse scenario could have involved the manipulation of data to make it unreliable on a policy by policy basis. This type of exercise could have continued for many months or years before detection.)
Compromised devices are used as part of a Botnet to launch a distributed denial of service attack. Such an attack would result in the attackers having control of the devices and being able to hire out the devices for others to perform attacks or doing them themselves. No costs are assumed, since at present litigation has not been directed towards those whose networks have been taken over by attackers. However, this is still mentioned as part of this in the scenario, as it is plausible that litigation to recover costs for the cybersecurity negligence of organisations whose networks are used for distributed denial of service (“DDoS”) attacks could result in additional costs in the future.
The attack published by the researcher highlights the fact that a web service is enabled by default on the telemetry device. The administrative interface to this web service is accessible using a default username and password combination (Admin/Admin). When logged into the web service with administrative credentials, the user can visit a page on the web site which provides the location of the device, a recent history of previous locations, the home address of the driver, driver’s license and a live feed of images coming from the camera. The web server also allows the administrative user to remotely wipe the device and upload new device management software on it for upgrade/support purposes. In addition, the device has an old version of Apache web server software which is susceptible to a buffer overflow attack leading to unauthorised remote access to the device.
A few weeks after the researcher’s results were published, a malicious botnet was created that automatically exploited the vulnerability and replaced the software on the devices with an image that ran DDoS attacks as part of a DDoS botnet.
Timelines
Week 0: Hack occurs
Week 3: A problem is detected in the devices. Investigation of the cause of the issue is identified; no information is coming out of the devices due to the hack. To rectify, the insurer needs to replace the product or fix it “over the air.”
Week 5: After investigation, the insurer finally realises that the problem is caused by a hack on the devices which need to be replaced. (Fixing over the air would typically reduce the costs of the scenario, and thus for the sake of a remote scenario this is not considered possible.) At the same time, data from the devices is being published online.
Weeks 10–20: To replace devices, the insurer needs to produce new devices and ship them to UK.
End of year 1: The Information Commissioner’s Office (“ICO”) applies a fine due to loss of customer data resulting from device security weaknesses.
Years 3–5: Damages incurred from complaints cases, reputational damage remains (uptake in new insurance products integrated with telemetry devices is slower compared with competition) and sales are reduced.
Year 5: Incident now in past and reputation restored
Examples of Internet of Things (“IoT”) devices used by insurers
IoT products measuring behaviours and driving down premiums are exposed to this type of hack. There are a growing number of IoT devices being used by insurers for the insurance products. Some examples are shown below for different insurer types.
Healthcare:
∙ fitness measurement devices; and
∙ monitoring devices such as heart monitors.
Home insurance:
∙ gas meters/electric meters to insurer to reduce premium;
∙ smart smoke/ heat alarm; and
∙ smart water detection.
Ship/cargo insurance:
∙ telemetrics/GPS keeping track of ships/cargo/shipments.
Car insurance:
∙ devices used in cars to measure driving habits/behaviours and encouraging good behaviour premium.
3.6.4. Security assessment and mitigation
Figure 7 displays the assessment of this scenario’s vulnerability across the NIST framework for the impact on frequency and severity of the event and indicate that the following control areas are expected to be the key vulnerabilities for this scenario:
∙ identify, e.g. asset management and inventory;
∙ protect, e.g. access controls, data security, remote management and information protection processes; and
∙ detect, e.g. anomalies and events.
Figure 7 NIST framework assessment for telematics device hack scenario
3.6.5. Expected costs
Table 6 summarises some of the expected costs for this type of scenario. These costs are only indications of the potential magnitude of each cost area for the specified parameters of this scenario.
Table 6 Expected cost summary for telematics device hack scenario
The majority of the costs estimated for this scenario are caused by the product replacement cost for all the cars. The scenario overall results in a cost of c18% of annual premium. It is possible that some portion of the scenario costs could be recovered, e.g. from the manufacturer of the devices or a separate insurance policy, however this has not been assumed for this scenario.
Business interruption costs and reputational damage have not been considered relevant for this scenario. There may need to be some system downtime for investigative work but it is not considered that it would be significant and thus normal operations would not be greatly impacted. Also, the type of consumer buying these policies is likely to be saving money by using such a device. This will require consumers to either switch away from such a device or switch provider; it is not clear whether consumers would believe that switching away would solve the issue.
3.6.6. Mitigation
The impact and ability to mitigate the risk is dependent on the following key areas (as labelled in the NIST framework, see also Table 7):
∙ identify;
∙ protect;
∙ detect; and
∙ respond.
Table 7 Proposed mitigation approach for telematics device hack scenario
The devices need to have better security and may require some security upgrades (software and hardware) to reduce their vulnerability to a hack. In addition, the devices should be monitored for unauthorised access, and regular security testing put in place to ensure they are safe.
Acknowledgements
The authors would like to thank Jonathan Evans, Patrick Kelliher, and Edward Pocock for their invaluable feedback as well as the IFoA staff for their continued support and assistance.
Disclaimer
The views expressed in this publication are those of invited contributors and not necessarily those of the Institute and Faculty of Actuaries. The Institute and Faculty of Actuaries do not endorse any of the views stated, nor any claims or representations made in this publication and accept no responsibility or liability to any person for loss or damage suffered as a consequence of their placing reliance upon any view, claim or representation made in this publication. The information and expressions of opinion contained in this publication are not intended to be a comprehensive study, nor to provide actuarial advice or advice of any nature and should not be treated as a substitute for specific advice concerning individual situations. On no account may any part of this publication be reproduced without the written permission of the Institute and Faculty of Actuaries.
Appendix 1: Scenario Selection
The following seven scenarios were discussed by the working party. These scenarios were originally conceived through brainstorming based on known events and events considered to be plausible given the knowledge of the cyber threat environment at the time. Care was taken to consider scenarios relevant to insurance organisations and across the whole industry regardless of area of business focus. The final selection of scenarios to focus on was based on a group vote to determine the scenarios which the group considered the most relevant and interesting to explore in greater detail.
Scenario 1: A general insurance business with a diverse business including a large motor portfolio is hacked by an internal staff member. Details of all motor insurance policyholders are leaked onto an Internet website and are widely available.
Scenario 2: A large life insurance business is targeted by a spear phishing e-mail to their CFO, apparently from their CEO. This results in a large transfer of funds intended for an investment portfolio, into a rogue bank account.
Scenario 3: A Lloyd’s syndicate has a large portfolio of risks in the USA. The Internet in the East Coast of the United States is attacked by cyber anarchists, resulting in no Internet connectivity for 2 weeks.
Scenario 4: A large insurer is in the process of migrating its data centre operations to the cloud. A member of their IT team extracts a large volume of data containing Personally Identifiable Information client data onto a high capacity disc to transfer to the new data centre. During the physical transfer of this disc, the disc gets stolen.
Scenario 5: A broker for a general insurer gets infected with ransomware on their computer. The ransomware spreads within the company and encrypts a major file share containing client records. The company is unable to access these records as they are encrypted by the malware. The online backup of the file share is also affected by the malware as it automatically backed up encrypted files. The insurer experiences an inability to process client requests due to lack of availability of important client information.
Scenario 6: An insurer employs a third party to print and send invoices and statements to all their customers. Large volumes of client data are shared monthly with the service provider to carry out necessary print and invoice operations. The insurer gets notified by the third party that they have experienced a data breach and customer records have been stolen.
Scenario 7: A motor insurer deploys telemetry in customer vehicles for measuring driver patterns using a specific telemetry device. A security researcher publicises a hack on this device that allows any Internet user to access the camera of the telemetry device as well as the location and PII data on it. The insurer needs to recall/replace/replenish the device with each of its clients.
Scenarios 1, 5 and 7 were selected as being the most relevant to the insurance industry from and operational risk perspective and the following amendments were suggested.
Scenario 1: Ensure that the data breach focus is retained but expand the narrative of the scenario to include both personal lines (volume focus) and commercial lines/London market (sensitivity focus e.g. high net worth, K&R, M&A).
Scenario 5: The focus of the scenario should be on business interruption e.g. ransomware/cloud downtime.
Scenario 7: In researching the scenario consider IoT and the potential impact of this area of technology more broadly.
Appendix 2: Detailed NIST Framework
The following table sets out the five core functions proposed within the NIST framework to ensure a company responds to cyber risk. We have assessed each scenario against the 22 control categories within each of these core functions as set out in v1.0 of the NIST framework paper (National Institute of Standards and Technology 2014).
It is worth noting that an additional control category was added to the ‘Identify’ function in v1.1 of the NIST framework (National Institute of Standards and Technology 2018). As mentioned in section 2.1 of this paper this is not deemed to have a material impact on the conclusions of the paper. For completeness, the additional control category has been included below:
Appendix 3: Glossary of Terms
Attacker: Malicious actor who seeks to exploit computer systems with the intent to change, destroy, steal or disable their information, and then exploit the outcome.
Botnet: A botnet is a collection of Internet-connected devices, which may include PCs, servers, mobile devices and Internet of things devices that are infected and controlled by a common type of malware. Users are often unaware of a botnet infecting their system.
Breach: An incident in which data, computer systems or networks are accessed or affected in a non-authorised way.
Brute force attack: Using computational power to automatically enter myriad value combinations, usually in order to discover passwords and gain access.
Bug bounty programmes: A bug bounty program is a deal offered by many websites and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to exploits and vulnerabilities.
CISO: A chief information security officer (CISO) is the senior-level executive within an organisation responsible for establishing and maintaining the enterprise vision, strategy, and program to ensure information assets and technologies are adequately protected.
CRO Forum: The CRO Forum is a group of professional risk managers from the insurance industry that focuses on developing and promoting industry best practices in risk management. The Forum consists of Chief Risk Officers from large multi-national insurance companies. It aims to represent the members’ views on key risk management topics, including emerging risks.
Cyber resilience: Cyber resilience refers to an entity’s ability to continuously deliver the intended outcome despite adverse cyber events.
Cyber underwriting risk: Cyber underwriting risk is defined as the set of risks emanating from underwriting insurance contracts that are exposed to losses resulting from a cyber-attack.
Data at rest: Describes data in persistent storage such as hard disks, removable media or backups.
Data warehousing: Data warehousing is a technology that aggregates structured data from one or more sources so that it can be compared and analysed for greater business intelligence.
DDoS: A distributed denial-of-service (DDoS) attack is an attack in which multiple compromised computer systems attack a target, such as a server, website or other network resource, and cause a denial of service for users of the targeted resource. The flood of incoming messages, connection requests, or malformed packets to the target system forces it to slow down or even crash and shut down, thereby denying service to legitimate users or systems.
Device hack: Embedded device hacking is the exploiting of vulnerabilities in embedded software to gain control of the device. Attackers have hacked embedded systems to spy on the devices, to take control of them or simply to disable them. Embedded systems exist in a wide variety of devices including Internet and wireless access points, IP cameras, security systems, pace makers, drones and industrial control systems.
ERM: Enterprise risk management (ERM) is the process of planning, organising, leading, and controlling the activities of an organisation in order to minimise the effects of risk on an organisation’s capital and earnings.
Firmware: In electronic systems and computing, firmware is a specific class of computer software that provides the low-level control for the device’s specific hardware. Firmware can either provide a standardised operating environment for the device’s more complex software(allowing more hardware-independence), or, for less complex devices, act as the device’s complete operating system, performing all control, monitoring and data manipulation functions.
GDPR: The General Data Protection Regulation (GDPR) is a legal framework that sets guidelines for the collection and processing of personal information of individuals within the European Union. The GDPR sets out the principles for data management and the rights of the individual, while also imposing fines that can be revenue-based. The General Data Protection Regulation covers all companies that deal with data of EU citizens, so it is a critical regulation for corporate compliance officers at banks, insurers, and other financial companies. GDPR came into effect across the EU on May 25, 2018.
IoT: Internet of Things (IoT) is the network of physical devices, vehicles, home appliances, and other items embedded with electronics, software, sensors, actuators, and connectivity, which enables these things to connect and exchange data, creating opportunities for more direct integration of the physical world into computer-based systems, resulting in efficiency improvements, economic benefits, and reduced human exertions.
Malware: Malware, is defined as the malicious software file or program harmful to a computer user which can execute different malicious functions like encrypting, stealing or deleting sensitive data, hijacking or altering core computing functions and monitoring computer activities of users without their permission.
Network segmentation: Network segmentation in computer networking is the act or practice of splitting a computer network into subnetworks, each being a network segment. Advantages of such splitting are primarily for boosting performance and improving security.
NIST Framework: The NIST Cybersecurity Framework provides a policy framework of computer security guidance for how private sector organisations in the United States can assess and improve their ability to prevent, detect, and respond to cyber-attacks.
Operational Risk: Operational Risk is the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. Operational Risk is the residual risk not covered by other categories of risk, including insurance, financial, credit and liquidity risk.
Patch controls: Patch management is an area of systems management that involves acquiring, testing, and installing multiple patches (code changes) to an administered computer system. Patch management tasks include: maintaining current knowledge of available patches, deciding what patches are appropriate for particular systems, ensuring that patches are installed properly, testing systems after installation, and documenting all associated procedures, such as specific configurations required.
Petya/Notpetya: Petya is a family of encrypting ransomware that was first discovered in 2016. The malware targets Microsoft Windows-based systems, infecting the master boot record to execute a payload that encrypts a hard drive’s file system table and prevents Windows from booting. It subsequently demands that the user make a payment in Bitcoin in order to regain access to the system. Variants of Petya were first seen in March 2016, which propagated via infected e-mail attachments. In June 2017, a new variant of Petya was used for a global cyberattack, primarily targeting Ukraine. The new variant propagates via the EternalBlue exploit, which is generally believed to have been developed by the U.S. National Security Agency (NSA), and was used earlier in the year by the WannaCry ransomware. Kaspersky Lab referred to this new version as NotPetya to distinguish it from the 2016 variants, due to these differences in operation. In addition, although it purports to be ransomware, this variant was modified so that it is unable to actually revert its own changes.
Penetration test/Pentest: An authorised test of a computer network or system designed to look for security weaknesses so that they can be fixed.
PFI: PCI Forensic Investigators (PFIs) help determine the occurrence of a cardholder data compromise and when and how it may have occurred. These PCI Forensic Investigators are qualified by the Council’s program and must work for a Qualified Security Assessor company that provides a dedicated forensic investigation practice. They perform investigations within the financial industry using proven investigative methodologies and tools. They also provide relationships with law enforcement to support stakeholders with any resulting criminal investigations.
PII: Personally identifiable information (PII) is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used for de-anonymising anonymous data can be considered PII.
QSA: Qualified Security Assessor is a designation conferred by the PCI Security Standards Council to those individuals that meet specific information security education requirements, have taken the appropriate training from the PCI Security Standards Council, are employees of a Qualified Security Assessor (QSA) company approved PCI security and auditing firm, and will be performing PCI compliance assessments as they relate to the protection of credit card data.
Ransomware attack: Ransomware is a type of malicious software from cryptovirology that threatens to publish the victim’s data or perpetually block access to it unless a ransom is paid. While some simple ransomware may lock the system in a way which is not difficult for a knowledgeable person to reverse, more advanced malware uses a technique called cryptoviral extortion, in which it encrypts the victim’s files, making them inaccessible, and demands a ransom payment to decrypt them.
S166: A s166 notice is a notice issued by the Financial Conduct Authority (FCA) under s166 of the Financial Services and Markets Act 2000 requiring a firm to carry out a “skilled person review.” The FCA serves around 50 a year.
SDLC: Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality softwares. It is also called a Software Development Process. SDLC is a framework defining tasks performed at each step in the software development process.
Social engineering: Social engineering, in the context of information security, refers to psychological manipulation of people into performing actions or divulging confidential information. A type of confidence trick for the purpose of information gathering, fraud, or system access, it differs from a traditional “con” in that it is often one of many steps in a more complex fraud scheme.
Software vulnerabilities: In computer security, a vulnerability is a weakness which can be exploited by a Threat Actor, such as an attacker, to perform unauthorised actions within a computer system. To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can connect to a system weakness. In this frame, vulnerability is also known as the attack surface.
Spear-phishing: Spear phishing is an e-mail-spoofing attack that targets a specific organisation or individual, seeking unauthorised access to sensitive information. Spear-phishing attempts are not typically initiated by random hackers, but are more likely to be conducted by perpetrators out for financial gain, trade secrets or military information.
Telemetry: Telemetry is an automated communications process by which measurements and other data are collected at remote or inaccessible points and transmitted to receiving equipment for monitoring.
Vulnerability scans: Vulnerability scanning is an inspection of the potential points of exploit on a computer or network to identify security holes. A vulnerability scan detects and classifies system weaknesses in computers, networks and communications equipment and predicts the effectiveness of countermeasures. A scan may be performed by an organisation’s IT department or a security service provide, possibly as a condition imposed by some authority.
Worm: A worm is a standalone malware computer program that replicates itself in order to spread to other computers. Often, it uses a computer network to spread itself, relying on security failures on the target computer to access it.
Open access
