Essentials of Cybersecurity for Healthcare Organisations (ECHO)

1.1 Staff members’ willingness to adopt cybersecurity elements

As health information systems and the use of ICT in healthcare settings become more advanced, it is important to ensure robust cybersecurity within healthcare organisations. The key challenge for an organisation that is constantly enhancing its cyber preparedness is the acceptance and adherence of staff members to the policies and tasks they are assigned. Healthcare staff are often tasked with a range of conflicting priorities and will be more accepting of cybersecurity policies and security actions that are straightforward to understand and not overly time-consuming.

The first step to encourage staff acceptance and adherence is strong two-way communication whereby leadership and ICT/cybersecurity personnel listen to the concerns of different staff members and try to directly address them. It is also important to provide adequate information to staff as policies and guidance are updated, and to simplify what staff are being asked to do, as much as is feasible (see Dimension 5: Awareness, Education and Training). It is important to highlight to staff members that cybersecurity is an essential element of patient safety and should be treated with the same attention as other activities to ensure the safety of patients. It can also be helpful to emphasise that adopting cybersecurity methods at work can be replicated at home to help keep personal and family devices and information safe as well.

Conversations and education sessions with staff on the topic of cyber preparedness should happen regularly within the organization.

1.3 Cultural factors and norms that undermine or promote security

Healthcare organisations operate within unique cultural factors and norms, as well as the wider society around the organisation, that can undermine or promote security and cyber planning and preparedness.

For example, a “blame culture” is a set of norms and attitudes within a healthcare organisation characterised by an unwillingness to take risks or raise concerns because of a fear of criticism or managerial reprimand.  A prevailing blame culture in healthcare may be a major factor for cyber risks or threats not being highlighted, as individuals fear they will be held responsible for error or lack of action. Conversely, an environment where staff are encouraged to raise concerns around cybersecurity or other ICT problems, both to immediate managers and organisational leadership, can promote more dynamic security and cyber planning. 

It is important for leadership and ICT/cybersecurity personnel to consider these cultural factors and norms to design policies and guidance that seek to minimise barriers to security and cyber planning.

1.2 ICT systems’ maturity level

A maturity assessment can be used to measure the current maturity level of a certain aspect of an organisation (e.g., ICT systems) in a meaningful way, enabling the healthcare organisation to identify strengths and areas for improvement towards prioritising efforts to increase maturity. Understanding the ICT maturity level of your organisation can help you plan where to target cybersecurity activities.

For example, a single healthcare provider partly using electronic health records internally, with little or few connected medical devices or technologies, will have different cybersecurity priorities as compared to a healthcare provider that is part of a network of providers, entirely dependent on electronic health records, sharing them across the care pathway and with external organisations, with many advanced and interconnected medical devices and technologies.

There are several assessment models available to facilitate this task, including the internationally validated Healthcare Information and Management Systems Society (HIMSS) maturity models where each of the multistage models (Stage 0-7) provide standards that assist healthcare providers in making improvements in efficiency, performance and care outcomes.¹ Assessing the maturity level of ICT systems within the healthcare organisation need not be a formal or complex task. Rather a responsible person/team can map the major ICT systems, as well as the medical devices and other technologies used within the organisation and by those working for the organisation.

Such mapping (see Dimension 4: Risk Management) should be undertaken regularly to ensure new ICT systems, devices and technologies used within the organisation are considered as part of ongoing cyber planning.

1.4 Implementation costs

There are a range of costs associated with developing cybersecurity within a healthcare organisation. These costs can directly relate to the financial resources associated with maintaining legacy infrastructure, purchasing ICT and cybersecurity technologies, or the costs of hiring staff or consultants to maintain cybersecurity within the organisation. Human resources in ICT departments are also required to develop and maintain cybersecurity preparedness. The pay gap between security specialists in the private sector/non-health critical sectors is one of the major challenges faced by public health systems globally. Without paying ICT and cybersecurity specialists an equivalent salary, healthcare organisations will face challenges in attracting and retaining security staff with implications for addressing cyber risks.  

It is also important to consider the time that needs to be invested by other, non-ICT staff in their everyday work (e.g., through time taken to update passwords/systems, incident reporting etc.) and the costs associated with training non-ICT staff. 

The costs of implementing cybersecurity will vary across contexts and will be based on a range of contextual factors, but also the technological needs of the organisation. Healthcare organizations should not be discouraged from scaling  up their cyber planning if there is limited financial or human resources available – there are a range of low-cost actions that can be undertaken by organisations to improve cybersecurity (see Dimension 4: Risk Management, and Dimension 6: Technical capabilities).

2.1 Incident communication plan

A cybersecurity incident in a healthcare environment may cause challenges for a range of staff members as they find themselves in an unfamiliar and high-pressure situation. An incident communication plan is an element of a healthcare organisation’s broader incident response plan (see Dimension 4: Risk management). The value of a specific incident communications plan is to ensure staff and stakeholders are informed about the incident in a clear and direct way, which allows them to understand the situation and respond appropriately.

Communication plans should aim to be easily understood and executable. While the specifics of an incident communication plan will be tailored to the needs of each healthcare organisation, there are several areas of consideration when developing the plan, including: 

• Ensure staff and stakeholders are briefed on the process from incident detection or recognition to reporting, as well as who will take the lead in putting the incident communication plan into action (e.g., following an initial assessment of the reported cyber incident, who is the individual or committee responsible for executing the plan?).
• Designate an individual responsible for external communication (e.g., to respond to patients, media, regulators and other stakeholders who will request information on the attack).
• Create criteria for whether to inform law enforcement or relevant cybersecurity organisations (e.g., under what circumstances should law enforcement be informed? Who from your organisation has the authority to make that decision? Which internal discussions should be undertaken prior to alerting law enforcement and national cybersecurity organisations?).
• Develop pre-approved templates to inform patients and stakeholders of the incident (e.g., under certain regional or national regulations patients must be informed if their personal identifiable information has been compromised, or following media attention, the healthcare organisation may want to share a statement with patients and stakeholders).
• Monitor social media (e.g., maintain up-to-date knowledge on information spreading about the incident to quickly respond should misinformation begin to circulate).
• Continuously analyse and update the incident communication plan (e.g., ensuring individuals listed as responsible for the different aspects of the plan are up to date, ensuring the pre-approved templates reflect the range of possible messages that may need to be sent out in the event of a cyber-attack).

2.3 National and local legislative requirements

Legislation and regulation provide the overall frameworks within which cybersecurity must operate. Failure to address cybersecurity gaps that then lead to breaches or incidents can be followed by severe legal consequences and fines. Furthermore, some regulations require that local safeguards must be met before international collaboration can occur. There are many international and national standards that can be implemented to achieve better security. The majority of these have similar foundations.

Legislation and regulation

It is important for leadership and ICT/cybersecurity personnel to consider these cultural factors and norms to design policies and guidance that seek to minimise barriers to security and cyber planning. ISO 9001 is an international standard for quality management that ensures that processes and systems are delivered with repeatable results. ISO 27001 supports a minimum set of controls that internal Information Security Management Systems (ISMS) should adhere to. This can be augmented with ISO 27017 and 27018 controls to cover strong ISMS in the cloud.

Organisations within certain geographic areas may be subject to further legislative requirements. On data protection, for example, General Data Protection Regulation (GDPR) is a European standard that regulates the use and sharing of personal data. National legislative requirements must also be followed in respect to data protection. For example, the Data Protection Act (the DPA) No. 24 (2019) regulates data protection in Kenya, the General Data Protection Law (“LGPD”) 13,709/2018 regulates in Brazil, and the Federal Law No. 152-FZ (2006) “On Personal Data” and the 2001 Labour Code of the Russian Federation (for personal data of employees) regulates in Russia.

Cybersecurity specific laws at the national level include, for example, the Federal Law of 26 July 2017 No. 187-FZ On Security of Critical Information Infrastructure of the Russian Federation sets out requirements to ensure security of critical informational infrastructure in sectors such as healthcare, transportation, financial services, energy, defense, etc. In contrast, in Brazil, there are no laws directly related to cybersecurity, however several laws could be applied. These include: The 2014 Internet Act, for certain principles and rules, and The Penal Code (Decree Law 2,848/1940) and subsequent Decree Law 12737/2012 on criminal classification of computer crimes, which establishes the crime of “invasion” of a computing device.

Legislation varies from country-to-country and is updated frequently so must be constantly reviewed by relevant personnel within the healthcare organisation. Even if all standards are not legally required to operate, it can be worth adding controls from other frameworks that will improve on existing implementations.

Frameworks

It is important to understand what different frameworks aim to accomplish to aid the adoption and alignment of these standards. Different standards will provide different benefits, therefore it is best to engage internal and external experts to ensure requirements are adopted and applied appropriately.

2.5 Clinical safety assessment process

A clinical safety assessment process is about making sure the technologies used clinically in health and care are safe. Assessment of these technologies needs to include both internet connected, and non-internet connected devices.

For example, digital clinical safety in the NHS is established in law under the Health and Social Care Act, 2012. The process for documenting safe development and deployment of health ICT systems is delineated in the Clinical Safety standards, with separate guidance for manufacturers of health technologies and for those deploying and using health technologies. Nationally, these two clinical safety standards outline the set of requirements to promote the effective application of clinical risk management by organisations responsible for the development, commissioning, deployment and use of health ICT systems.

Safety assessments need to include systems thinking, which takes into account the various aspects of the system that have or may lead to patient harm, such as provider(s), technology(ies), personnel, and organisational culture.

To support clinical safety, medical device regulation (see Section 2.5) Conformitè Europëenne (CE) marking in the European Union, and US Food and Drug Administation (FDA) regulation can help ensure safety for both individual devices and system-based devices such as artificial intelligence and machine learning. To ensure transparency in assessment, black box  technology* should be avoided in favor of open standards and code. Clinical trials should support efficacy and safety for all medical technology, from pharmacy to diagnostic decision support.

* A system or device whose internal workings are hidden or not readily understood.

Figure 1

2.7 Best practice guides

Organisational memory is the accumulation of past experiences and knowledge that become ingrained into an organisation’s current and future decision-making.¹⁰ Organisational memory can contain both good and bad practices that influence behaviour. It is therefore critical to capture and spread best practice that can help deliver repeatable positive outcomes.

Best practice guides will contribute to positive organisational memory. Best practice guides for cybersecurity should cover safe internet and equipment usage, security by design in systems and application architecture, credential and password management, minimal privilege principles, engagement with third parties, and risk appetite matrices (see Dimension 4: Risk management and Dimension 6: Technical capabilities). Hosting internal challenges to capture or improve existing best practice can help engage the healthcare organisation in the process of creating best practice guides, increasing the likelihood of adoption. Best practice guides can also be adopted from external sources.

2.9 System and Organization Controls (SOC) 2/Pen test criteria

As described in Section 2.5, many cybersecurity frameworks go beyond just documenting how things are done to include evidence proving controls are implemented and secure. Going a step beyond to showcase resilience against
cyber-attack provides compelling evidence to support certifications and regulation. Regular internal and external audits (see Dimension 4: Risk management) can help provide evidence of implementation and expose gaps that need to be addressed.

Penetration (pen) testing as part of audits, where applicable and allowable, will also test systems against many known vulnerabilities and weaknesses. The network scanning tool Nmap (Network Mapper, see Dimension 4: Risk management) can help map open risks that may exist as part of default software, including operating systems. Security testing should also be built into software development processes, referred to as unit testing, to expose any possible bugs prior to software release. Open-source components and libraries should be vetted prior to use to ensure that combinations will not create inadvertent risks. Agile delivery – delivery in smaller, more iterative parts – helps support better cybersecurity by making unit tests smaller and more direct.¹⁵ However, the release-often mentality can create its own risks, so policies should cover acceptable release criteria and integrated change management should address any potential security risks.

2.2 Communication of threats to stakeholders

Like the importance of a clear incident communication plan following a cyber incident, it is important to actively communicate threats to stakeholders and the steps being taken to mitigate risk which overlaps with the awareness considerations outlined in Dimension 5: Awareness, Education and Training. Communication of threats to stakeholders must happen on several levels. For example, the team/individual responsible for cybersecurity should report to senior management/organisational board-level. Reporting may cover briefings on attempted attacks, novel vulnerabilities, cyber-attacks reported by similar organisations in the area, etc.  

The communication of threats to stakeholders can be planned through formal policies and planning documents such as the incident communication plan (see Dimension 4: Risk Management). However, healthcare organisations should consider any other channels where their stakeholders would value updates on cyber threats, and how often this would be required (e.g., Would senior management/board members benefit from quarterly briefings on cyber threats? Would front-line staff benefit from a monthly summary of recent attack attempts and reminder on good practice when using ICT systems? Is there a requirement to share communications with national cybersecurity centers or other cybersecurity/ICT emergency response teams?).

Table 1: Overview of various common cybersecurity frameworks²

2.4 Health/clinical information standards

Health and clinical information standards are used by healthcare organisations to ensure information about the health and care of individuals can be shared and compared across the organisation, or the health sector more widely, using data that are defined consistently. Each healthcare organisation will be expected to conform to the relevant national, regional, and international health and clinical information standards.

Governance of healthcare data through appropriate standards is critical as healthcare data, including genomic data, constitutes a special category of data in many data protection regulations.³ ⁴ ⁵ Part of using healthcare data is providing appropriate access and exchanging data between organisations to deliver care. If data are poorly structured, it will be more difficult to exchange these data safely and reliably. Information standards and ontologies help to code data in a format that allows exchange of a minimal amount of data to achieve clinical and non-clinical requirements. Coding of data reduces the release of “free text” data – data in raw form.

Standards such as Fast Healthcare Interoperability Resources (FHIR), a standard for clinical messages between systems, and Systematized Nomenclature of Medicine – Clinical Terms (SNOMED CT), a standard for describing clinical events, are commonly used to support healthcare delivery, operations, and research.⁶ ⁷ These systems increasingly rely on coding services, such as ontology servers, to function as part of routine healthcare. These services must be protected to the same degree as the sensitive data as an attack on these services could disrupt healthcare delivery. These services are not secure by default and must be paired with appropriate security measures to operate safely.⁸

The same logic applies to clinical devices that should operate with common standards. This reduces the need for custom-developed software to sit in the middle, which can then become a source of vulnerabilities. Creating seamless connections between systems by implementing secure standards for application programming interfaces (API) ensures that patient data can be exchanged safely.

Healthcare organisations must catalogue and assess cybersecurity risks (see Dimension 4: Risk management) for various types of connections, person to system, system to system, and device to system. OAuth 2.0 is a well-adopted standard for authorisation that can be used alongside encryption to secure communication between these types of connections.⁹

2.6 Appropriate 'work from home' policy, as well as 'bring your own device' (BYOD) policy

Given the increasing use of personal electronic devices globally, healthcare organisations are required to consider the security of such devices when used by staff to access work information. Similarly, following the onset of the COVID-19 pandemic, many healthcare organisations across the world are embracing ‘work from home’ policies where staff may take their work electronic equipment out of the organisational environment. In both cases, policies must ensure cybersecurity is thought about and maintained in the following scenarios:

Working from home (WFH): As staff connect to their home network, often without the security protections of organisational networks, such as firewalls, the risk of security breaches increases. The risk of certain cybersecurity threats also increases, for example, “phishing”*. Mitigation requires cyber-safety training and technical controls for file transfers and network access.

‘Bring Your Own Device’ (BYOD): As staff bring their own, potentially insecure electronic devices into the healthcare organisation’s premises (or use them to work from home), hacking, malware, and data leakage are the biggest BYOD security risks. In these cases, cyber-attackers may take advantage of unsecured devices, networks, and malicious apps to mine personal devices for organisational information or patient data. Applying control policies to personal devices helps minimise the risk of exposure.

When getting ready to deploy a work from home or BYOD solution, organisations should first understand the additional risks involved, and then develop a policy that will balance security while minimising disruption to staff. Risks to consider may include but are not limited to:

• The higher potential for accidental data loss (e.g., device backups containing work data, staff sharing their device with family).
• A malicious unauthorised data transfer (e.g., malicious application leaking data that staff have accidently consented it to access).
• A higher likelihood of unsupported or out-of-date devices, leading to exploitation of known security vulnerabilities.

Once your organisation has considered the risks of BYOD, a BYOD policy can help mitigate them. The BYOD policy should clarify both organisational and employee responsibilities (see Figure 1). The policy should also consider how to encourage compliance, what happens if staff do not follow procedures, and how the organisation might respond in such circumstances.

*Phishing describes a particular type of email scam, whereby victims are targeted from seemingly genuine persons or services, with the aim of tricking the recipient into either providing personal details or clicking on something that will allow the attacker to do something the user may not be aware of.

2.8 Medical device standards

Many common cyber-security frameworks (see Section 2.5) focus on controlling human and system behaviour and access. However, in the age of the Internet of Things (IoT), where internet-enabled smart devices are increasingly used in the workplace, building policies and procedures to protect these devices are critical. For example, ICT-enabled blood pressure devices or oximeters are medical devices but can also encompass whole systems. As an example, the NHS England (NHSE) Genomic Medicine Service (GMS), through which clinicians can order genomic sequencing and testing for eligible patients, is both ISO 13485 certified, and European Conformity (CE) marked as a medical device.¹¹ This is important to ensure that the service meets the same strict criteria as traditional medical devices do. The US FDA has proposed similar regulation for artificial intelligence and machine learning when used as a medical device.¹²

Increasingly, medical device standards are being developed at the regional level, as well as nationally. For example, in Southeast Asia the Association of Southeast Asian Nations (ASEAN) Medical Device Directive (AMDD) seeks to develop a harmonised regulatory structure for medical devices across ten countries.¹³

Within a healthcare organisation, governance of medical devices should include assurances that systems and devices are resilient, secure, and can be updated as required to meet new threats (see Dimension 6: Technical capabilities). This includes the ability to automatically deploy updated software and firmware, and to register these devices with asset numbers so they can be cataloged and tracked. Hackers can easily exploit insecure devices, a fact that should not be underestimated. Even devices that are not connected to networks, such as pacemakers and insulin pumps, can be exploited through Bluetooth or radio frequency (RF) connectivity with potential dire consequences.¹⁴ As more and more medical activity moves to personal wearables, embedded sensors, and mobile device therapies, this problem will only amplify. It is therefore critical that a healthcare organisational cybersecurity framework encompasses medical devices.

2.10 Firewall protocols

Firewalls, including internet and software proxies, are a great defense against cyber-attacks. These firewalls can range in sophistication from simple port and network address blocking to file and email scanning (see Dimension 6: Technical capabilities). Addressing spam or phishing attempts through email proxies or scanning files for embedded malware can help prevent such risks from even reaching your network. Some firewall services, notably cloud-based provider components, can even help improve resilience through load balancers, and detect and defend against distributed denial-of-service (DDoS) attacks. At a minimum, healthcare organisations should map the sensitivity of key networks, such as those hosting electronic health records (EHR) or patient administration systems (PAS) and ensure that these are protected from inappropriate external and even internal access. A policy that defaults to no access, referred to as the “default drop” policy, and explicitly allowing only service protocols to cross networks and machines where required, will significantly strengthen protection against attack.¹⁶

3.1 Business continuity plan

Continuous operations are a matter of life and death in many healthcare organisations. Cyberattacks have the potential to disrupt both business and clinical delivery with devastating impact. Part of ensuring resilience is implementing a comprehensive and tested business continuity plan (BCP). The BCP will include ensuring redundancy in critical systems such as ICT systems, power, and heating, ventilation, and air conditioning (HVAC). Redundancy and failover capability are important as some cyber-attacks are merely about denying access to systems rather than actual intrusion. Over 5.4 million distributed denial-of-service (DDoS) attacks were detected in the first half of 2021 alone.¹⁷

The BCP should outline criticality of organisation systems and applications, the primary contacts for them, and failover procedures if a system or application should fail. Supporting these plans should be technology architecture that reduces single points of failure (SPoF). Understanding and mitigating SPoF is critical for stable delivery, remembering that SPoF can encompass people as well as systems.¹⁸ Network devices such as routers and switches should be redundant so that network outages can be minimised. Expected timelines for recovery should be documented and tested with those who would be involved, including security and non-security staff. As healthcare organisations are heavily reliant on digital technologies for the running of essential services, these actions must all be underpinned by automated backups of assets which should be available for recovery, including data.

It is not always possible to have fully redundant systems, but critical infrastructure should be prioritized to enable seamless failover and any gaps should be documented along with acceptable thresholds for outages. Using machine images that can be rapidly restored as virtual machines will help reduce the risk of prolonged outages. Cloud services such as Amazon Web Service (AWS) can help prevent outages through server-less architecture and automate failover using not just machine images, but entire infrastructure templates.¹⁹ ²⁰

3.3 Appropriate budgets for cybersecurity improvement

While the costs of cybersecurity incidents, specifically a ransomware breach, have been estimated at $4.62 million²¹, the percentage of ICT budgets used for security in healthcare organisations is still relatively low, though increasing year on year in most healthcare organisations. For example, in research published in 2021, security executives estimated 15% of IT budget was spent on security in their organisations.²²

There is no magical formula for deciding on cybersecurity budgets, and the financial feasibility of scaling up cybersecurity will vary between different healthcare organisations and their wider context (see Dimension 1). A good budget needs to consider software, professional security staff and services, risk management, documentation, training, and external and internal threats. It should also include requirements for global events and a changing landscape in work locations.²³

As part of developing appropriate budgets, organisations must reflect proper lifecycle management. For example, without planning upgrade requirements in an initial budget, an organisation may find itself needing short-term high cost ‘fixes’ (such as virtual patching) to cover the vulnerabilities after systems go out of support which becomes a ‘cyber’ problem (See Dimension 6: Technical capabilities). This can be avoided by proper understanding of lifecycle costs of systems/services and ensuring that is factored in. Cybersecurity costs can therefore be reduced and focus on features such as vulnerability scanning/SIEMs etc.

3.5 Cybersecurity as a regular item discussed at board level

To ensure cybersecurity is (and continues to be) an organisational patient safety priority, understanding and support (“buy-in”) from the highest levels of the organisation’s leadership is essential. There are several ways to engage with the board on cybersecurity, and in some organisations board members will already have knowledge on the importance of cyber preparedness. Should your organisation be starting at the very beginning of this process, it can be helpful to arrange an introductory session at a board meeting where representatives from the ICT/cybersecurity team present an overview of cyber threats and the importance of cybersecurity to the organisation.

To maintain awareness and support at the board level, cybersecurity should be a regular item discussed at board meetings, for example cybersecurity could be discussed quarterly or annually. Providing high-level information on the cyber threat landscape, attempted or actual cyber-attacks, and actions undertaken to build cyber preparedness across the organisation, is an opportunity to showcase the work of the ICT/cyber team. It is also a means of receiving board feedback towards integrating and improving cybersecurity within the organisation. Engaged board members can also act as advocates for cybersecurity planning at budget meetings and with other senior leadership and staff.

3.7 Procurement strategy to support cybersecurity

Secure by design thinking should be an integral part of a healthcare organisation’s procurement and development guidelines. When buying commercial off-the-shelf (COTS) products, an organisation should consider features that support cybersecurity. Products should have strong encryption capabilities for data being stored (at rest) and data transfers (in-transit) (see Dimension 6: Technical capabilities). Software should allow both user and system account authentication preferably supported by additional short-lived temporary tokens (multi-factor authentication). Interoperable standards should be used to avoid the need to develop “glue” middleware that can be at risk from a security and maintenance perspective. Device security needs to be assessed. For example, does the device support easy to apply firmware and patch updates?

Secure procurement also applies to services and suppliers. Requirements for third-party suppliers should be documented and followed. Questions should be asked such as:

• What vetting processes does the vendor use?
• What security certifications does the vendor have?
• Has the vendor had any breaches or incidents reported to a local authority?
• Does the vendor meet local regulatory requirements?
• How does the vendor secure its own third-party suppliers?

It should also be considered whether the vendor should use only company equipment if providing services or if they should use their own. This will depend on the type of information being handled and whether assurances can be met sufficiently. Many governments provide procurement frameworks, but these may only cover security requirements as part of security software and services. It is important to consider security for all people, devices, software, and services and as such, cyber-security should be a critical part of any tendering/procurement.

3.2 Organizational cybersecurity strategy

Developing a cybersecurity strategy allows the healthcare organisation to work towards goals instead of addressing gaps as they appear. A cybersecurity strategy goes beyond outlining which attacks an organisation may be at risk for by covering all the aspects of both external and internal threats (see Dimension 4: Risk management). Understanding the staff in your organization who may have inappropriate levels of access, even if required, will help support a plan for mitigating the risks surrounding that access. An organisation would not allow employees to authorize their own expenses, so employees should not be authorising their own systems and data access either. Appropriate controls need to be provided. A list of different elements requiring cybersecurity, even if just the basic technology and people to start with, should be created and assigned ownership. Employing a Responsible, Accountable, Consulted, and Informed (RACI) matrix can be very useful for ensuring controls have ownership. Consulting an Information Security Management System (ISMS) framework, such as the international ISO 27001 will be beneficial in ensuring that all the basic controls are covered.² Additional national cybersecurity frameworks, such as the UK National Cyber Security Centre (NCSC) Cyber Assessment Framework (CAF), Singapore Operational Technology Cybersecurity Competency Framework (OTCCF), or Australian Information Security Manual, may also be available in your country settings.

3.4 Communications strategy related to cybersecurity

It is very important to consider how cybersecurity will be discussed both internally and externally within your healthcare organisation. Internally, cybersecurity should be a well-known topic to ensure that it remains on staff minds. Externally, communicating about cybersecurity should build confidence and show improvement over time. Communication policies and procedures for suspected incidents need to be drafted and followed and a cybersecurity incident response plan (IRP) (see Dimension 4: Risk management) should be created and tested at a minimum. It is important to keep in mind that communication works both ways, and as such, communication policies and procedures should provide guidance on how staff can report incidents internally.

There will be specific regulatory requirements for reporting suspected incidents to an appropriate authority (see Dimension 2: Governance) within a documented time frame. Failure to do so can result in significantly higher fines.

3.6 Multidisciplinary Security Steering Group within the organisation

A multidisciplinary Security Steering Group provides an open discussion forum where individuals or departments can raise concerns and/or ideas around existing security policies to influence the creation of new policies. It also offers ICT/cybersecurity teams the opportunity to engage with a wider range of expertise from across and outside the healthcare organisation. As well as representation from the ICT/cybersecurity team, Steering Group expertise could include but does not need to be limited to:

• Legal expertise to provide regulatory and legal compliance insight.
• Human resources expertise to facilitate communication with staff and manage training.
• Clinical expertise to help determine the feasibility of policy roll-out across clinical staff roles and departments.
• Internal audit expertise to help determine security metrics and measure compliance.
• Project management/administrative expertise to ensure the meeting runs smoothly and track action item statuses between meetings.
• Other stakeholder expertise could include technical expertise offered by third-party vendors, patient and public engagement insights from patient groups, etc.

Inviting a member of the board (for example the Senior Information Risk Owner (SIRO)) to attend, or chair, Steering Group meetings can also be an effective strategy to increase board level buy-in and facilitate the sharing of ideas across both stakeholder groups.

Identifying risk

4.1 Monitor evolving risk landscape (threat detection)

It is critical that organisations are prepared for a variety of evolving threats as cyber-attacks on healthcare organisations are on the rise and growing in sophistication. National healthcare organisations and central health agencies are increasingly the targets of cyber-attacks. For example, in May 2021 the Irish Health Service Executive (HSE) was attacked and subsequent systems’ shutdown led to the cancellation of appointments and COVID-19 testing.²⁴

Cyber criminals take advantage of geopolitical and other global challenges to carry out cyber- attacks. The COVID-19 pandemic period has seen an increase in cyber-attacks on healthcare organisations since 2020, prompting the World Health Organization (WHO) to highlight this issue to member states.²⁵ INTERPOL similarly issued a Purple Notice to 194 member countries warning of the growing risk of attacks.²⁶ The opportunity of the COVID-19 pandemic has led to at least 16 different nation-state hacking groups using COVID-themed attacks to target organisations, including governmental healthcare agencies.²⁷ The war in Ukraine has highlighted that any state related conflict is likely to use cyber as a strategy for disruption. This will inevitably mean that there will be ‘collateral damage’ in terms of an increased risk of either new vulnerabilities, or existing vulnerabilities being exploited.

Analysis by Deloitte has shown that cyber-attacks are weaving into the very fabric of how organisations operate. Their research has shown that even medical devices can be vulnerable, allowing malicious users to change vital signs for patients with potential impact on clinical decision-making.²⁸ Risk also goes beyond just trust of human beings; machine-to-machine communication is due to make up half of all connections, leaving systems open to abuse through stolen machine identities.²⁹

An annual cyber risk assessment with a review of potential exposure is a must for every healthcare organisation.³⁰

4.3 Asset identification and management

An asset is any data, device, or other component that supports information transfer. Each of these assets must be identified and managed to reduce cyber risks associated with the assets.

An information asset register (IAR), a catalog that holds details for every information and technology asset owned by an organisation, is the foundation that helps ensure you can both manage and measure risk. Along with a configuration management database (CMDB) that holds the current configuration of assets, an asset register helps ensure that the current state of cyber risk is auditable.³⁴ Scanning of an organization’s network for unregistered devices, referred to as “asset discovery”, can help ensure this list is reconciled as a single source of truth.

Many healthcare organisations do not currently have a robust register of assets, and in such cases, it is important to build up a system of where assets can be recorded and updated as a start. Given the potential for healthcare organisations to have substantial numbers of assets, asset identification and management may be a long term process requiring substantial planning.

All assets, including information assets, should be assigned an asset identifier in the IAR. This can be as simple as a unique number or as complex as code identifying location and type. All assets should be cataloged as soon as they are procured or created. Furthermore, assets should be periodically audited to ensure they still exist. This helps ensure that assets are not missing, potentially indicating a data loss, and ensures that you are not wasting valuable resources trying to update unavailable assets. An IAR can also be used to connect system users with assets, which can help improve audit capability and mitigate risks of unauthorised access. Asset management provides the foundation for many key information management frameworks including ISO 27001 and Information Technology Infrastructure Library (ITIL).

A good IAR will also contain information on asset ownership, ensuring that every asset has an owner who is responsible for the current state of the asset. More recommendations on building cyber resilience through strong asset management can be found on the UK National Cyber Security Centre (NCSC) website.³⁵

4.5 Identification of dependencies on entire supply chain and other partners

International frameworks for best practice Information Security Management Systems (ISMS) such as ISO 27001 allow for security controls to be outsourced to third-party suppliers. Annex 15 of ISO 27001 covers how organizations should approach information security when dealing with suppliers.⁴¹ This guidance indicates supplier agreements should be very clear about roles and responsibilities when it comes to cybersecurity and recommends that organisations should work on a collaborative basis with suppliers to ensure better results. In this case an organisation is responsible for understanding and managing risks with suppliers and ensuring that attacks on third parties do not disrupt supply. See 4.14 for further information on third-party audit of controls (assessment of suppliers and partners).

The danger of not de-risking your supply chain is exemplified by the June 2021 outage in Fastly that provided a content delivery network (CDN) for 10% of global internet traffic, including service providers like Reddit, Amazon, Twitch, Spotify, and Hulu.⁴² This outage also caused the UK Government website, gov.uk, to become unavailable.

Figure 4: Example of a Common Risk Matrix Approach⁴³

4.7 Lessons learned/root cause analysis appraisals of cyber incidents

An integral part of risk management is learning from failure. Standard approaches to appraising risks should incorporate templates for nonconformances, e.g., issues where your security systems did not conform to intended safeguards, and root cause analysis which considers the details of what led to a failure.

Nonconformities, which are addressed under clause 10.1 of the ISO 27001 standard, provide a way to document when a nonconformity occurs, which can then be used for corrective action.⁴⁵ Creating this form can be up to the healthcare organisation, but it should meet some minimum criteria. It should include a description of the nonconformance itself, the requirement against your standard that was not met, and a corrective action plan that helps prevent any future occurrence of the nonconformance.⁴⁶ Corrective action is key to ensuring that the organisational risk matrix (see 4.6) is up to date in terms of probability and severity.

Root cause analysis is similar to a nonconformance report but is more detailed and not necessarily tied just to a security policy. There are many types of root-cause analysis, but one very common approach is called “the 5 whys”. The 5 whys approach postulates that you can reach the root cause of an incident by asking why 5 times. It may however take more than 5 to reach the true root cause and you should not stop investigating until you are satisfied that the real reason is clear.⁴⁷ Again, the value in root cause analysis, given that it happens after an event, is not in solving the issue but in preventing its reoccurrence. It is also important when performing root cause analysis to consider how failures can be the result of several issues and not just one; this is known as the swiss cheese model of failure.⁴⁸

Mitigating risk

4.9 Systems network monitoring, logging, and alerting

Continuous monitoring and logging are critical to cybersecurity. Using logs to detect and create automatic alerts ensures that systems are always under surveillance. Most logging is so broad and expansive though that it cannot possibly be processed by a human being, making it important to investigate software that can help process these logs in a more intuitive way. Log data processing platforms can provide common security processing patterns that can help implement detection according to popular cybersecurity frameworks.⁵² It is important to not reduce the noise in logging simply by turning logging off. Instead, healthcare organisations can identify their critical systems, and ensure they are capturing their logs for at least 180 days.

Security Operations (SecOps) is the practice of having a dedicated combined security and IT operations team. SecOps provides several benefits including continuous intervention capability, and security expertise.⁵³ Although not strictly restricted to cloud providers, cloud as-a-Platform (aaP) and as-a-Service (aaS) automation has taken SecOps to a new level. Major providers like Amazon Web Services (AWS) and Azure enable comprehensive logging and alerting capability to support SecOps. AWS even has a blog dedicated to SecOps security.⁵⁴ Healthcare organisations that do not feel comfortable running their own SecOps team can choose to outsource this function to a supplier.

Figure 5: Example of a RACI Chart for Incident Management

4.11 Internal risk management (including interoperability)

Internal risk management deals with the enemy within. Malicious actors or dissatisfied employees can cause destruction if a healthcare organisation is not prepared. Risks can also be non-malicious such as insecure machine-to-machine communications (see Dimension 6: Technical capabilities) or even user error, but these risks still present a grave threat to the security of the organisation. Security teams have a responsibility to ensure that internal risks are mitigated in addition to external risks.

Addressing inadequate access controls (see Dimension 6: Technical capabilities), untrained staff (see Dimension 5: Awareness, education, and training), and poor culture (see Dimension 1: Context) are key in ensuring that internal threats do not put an organisation at risk. Knowing where the gaps are by drawing up a list of internal risks and assigning them a score according to the organisational risk matrix (see 4.6) is a good place to start. Addressing these can take time and effort, as people will often prioritise productivity over security even unconsciously.⁶¹

Improving internal security requires the healthcare organisation to build a strong cybersecurity culture and wide awareness of common risks, framed in organisational terms such as less time with the patient or missing clinical information.⁶² In addition to addressing the human element, remember that the risk of insecure communications and trust between technology components also needs to be addressed.

4.13 Scenario planning/simulation

Business continuity planning and disaster recovery are important in risk management. Both terms address plans for what to do in case of an unforeseen emergency that may impact organizational delivery. Similarly, and just as important, an incident response plan and known risks must be tested or simulated regularly. For example, simulating phishing attacks to test employee knowledge or carrying out penetration testing as part of audits is important to mitigate risks and impact. PricewaterhouseCoopers’ (PwC) Cyber Readiness Health Check can help healthcare organisations assess their readiness in case of an attack.⁶⁴

There is sequence to incident response testing: Starting with checklists, table-top exercises, simulation to full stress testing (i.e. actually running on back-up data). Organisations need to build up their response plan to cover all aspects of this sequence.

Table-top exercises can be conducted several times a year, simulation annually, then a full stress-test every 2 to 3 years. Going straight to simulation without doing the former (check-lists and table-top) is likely to be counter productive as parts of the process may fail early on preventing the full benefit of simulation/stress testing.

Incident response testing of different cyber threats to elicit a response can facilitate improvements to existing incident response plans and capability by testing staff, processes, and the technology itself. Many areas of improvement identified by simulation or a full stress-test may not usually be detected through a desk-based manual review of incident response. An additional benefit of incident response testing is the ability to engage response teams, including executive leadership, and provide individuals and teams the opportunity to engage with wider cybersecurity planning and with each other.

4.2 Phishing detection and prevention

Phishing is a growing threat to healthcare organisations and the easiest way for attackers to target staff in healthcare organisations. Phishing is the process of using seemingly real content to trick individuals into “taking the bait” and doing something (e.g., clicking a link) that they would not do if they knew the content was false. There are many types of phishing using various mediums and broad or specific targets.³¹ There are also technological solutions to help block phishing attacks, including email detection software, advertisement blockers, and signature validation software. The UK National Cyber Security Centre (NCSC) recommends a multi-level approach to preventing phishing attacks.³² This includes user training (see Dimension 5: Awareness, Education and Training), which is an important defense to mitigate the risk of phishing. By recognising the warning signs of phishing, for example an unexpected email, or an email from a private domain rather than an organisational one, can help ensure that staff question the validity of communications. Once trained, staff should be checked to validate their understanding on a regular basis, which will then inform ongoing education requirements.

4.4 Data and network mapping

Hackers use port and network scanners to determine which attack points might be available to exploit. If you are not using these tools as well*, it is likely that you might know less than the potential hackers on your network.³⁶ Network mapping is part of any good penetration testing, which is the process of automatically testing potential vulnerabilities in your systems. Data mapping can also improve your ability to determine potential breach points by understanding how data flows between systems. Such potential breaches can also include unauthorized access to data by potentially authorised individuals such as system administrators, something an organisation might not be looking for initially.

Network mapping is the process of mapping your assets on networks and determining where risks may exist. The Network Mapper (Nmap) tool is an open-source scanner that can use common network protocols and response types, required for networks to function, to map the topology of an organisation’s network, the machines in the network, and ports that might be open on that network. Using a tool that can scan your network and look for open weaknesses ensures your risks are managed by reconciling the current state of your network with your expectations.

Many organisations that provide sensitive data for analysis require data flows to be provided when requesting data.³⁸ These data flows ensure that potential risks are assessed before releasing data to recipients. It also outlines who may have access to information as part of a release of data, and who may or may not be accounted for as part of the data application.

Data flows even improve internal risk management by clearly defining roles and responsibilities for data as they move between systems. Encryption requirements (see Dimension 6: Technical Capabilities) and threat models can also be mapped using data flow diagrams. Data flow diagrams can represent a single data asset as it flows through systems or can represent all data within the organisation. At a minimum, a healthcare organisation should hold a current context diagram of all the data assets within their organisation, their connections to systems, and their generation or modification by business processes.³⁹

*Note that some service and cloud providers limit penetration testing, providing alternative services instead. For example, Amazon Web Services (AWS) has specific policies on penetration testing and your services can be stopped if you do not comply with their requirements.⁴⁰

4.6 Risk assessment/vulnerability identification

A risk assessment matrix is a common way to understand the potential impact of risk against the probability that it will occur, creating a combined score that helps prioritise which risks need to be addressed first, as shown in Figure 4 below.

Probability, also referred to as likelihood, dictates how likely an event is to occur. For example, how likely is it that ransomware could be installed on an organisation’s machine? Severity is the rating assigned to the impact of the event. If we take the ransomware example, the impact could be quite severe. In this case, even if the likelihood is low, the severity is high and therefore the matrix score is high with a score of 10. A company policy will dictate the score that demands mitigation, but it is common for organisations to address anything high as a matter of priority.

It is also important to remember that the process of updates can be complicated, ranging from a simple patch (see Dimension 6: Technical Capabilities) without removing active access, to potential long outages for migrating services. Appropriate change management processes are key to ensuring that impact is understood and planned for. Using the risk matrix can help clarify to those impacted why services might need to be interrupted and help support the agenda for cybersecurity.   The impact of updates (e.g., interruptions) can add risks, and these should be assessed. These impacts are often explained to organisation management in terms of easily understood impacts, e.g., loss of productivity, reputational risk, or financial risk. These categories need to be mapped from your risk assessment to your change management system.⁴⁴

4.8 System audits

Adding to lessons learned and root cause analysis, system audits strengthen the security and resilience of healthcare organisational systems and culture. System audits have the added benefit of being preventative rather than reactive. Audits differ from (but might include) penetration testing. The point of an audit is to ensure that processes and security controls are sound, and that capability for capturing risk is robust. Two types of audits should occur at a minimum, internal and external.

Internal audits should be performed regularly by internal security teams. This gives an organisation the chance to self-criticise potential weaknesses given that no one knows systems better than the organisation itself. Internal audits should be honest and not ignore critical issues just to appease management or save effort. A risk matrix (see 4.6) is critical to help ensure that issues are accurately assessed and flagged for action accordingly. The North American Institute of Internal Auditors (IIA) has developed an internal audit competency framework that can help develop internal audit standards.⁴⁹ ⁵⁰

External audits should be performed on a scheduled basis, usually quarterly or annually depending on need. External auditors should be certified bodies with appropriate domain knowledge to assess potential risks in your security procedures. Although generic auditors can be appropriate, the domain knowledge will help bring in knowledge from other audits to improve findings. External auditors will provide findings in the form of nonconformances, either major or minor, which will then be used to improve the security processes. These nonconformances should be assigned scores aligned with the organisational risk matrix (see 4.6) and added to an organisational risk register accordingly. External auditors will expect to see the results of internal audits and steps taken to address nonconformances where applicable.⁵¹

4.10 Development of emergency processes

Clear escalation protocols in the event of a cybersecurity incident are critical to mitigating the impact of attacks. An incident response plan can include Responsible, Accountable, Consulted, and Informed (RACI) charts to clearly outline how to respond to incidents (see Figure 5).⁵⁵ ⁵⁶

The focus on incident response should be identify/analyse, contain, remediate, recover. Following this, authorities will need to be informed. In this regard, it is important to also note what is required by regulation (see Dimension 2: Governance). For example, many bodies responsible for investigations and fines in the event of a data breach have strict notification requirements. For example, the New Zealand Privacy Act 2020 requires notification for incidents “as soon as you are practically able”.⁵⁷ Alternatively, in Nigeria there is no mandatory requirement to report data security breaches or losses to the authorities or to data subjects under the Nigeria Data Protection Regulation. However, the Framework mandates Data Controllers to notify the  National Information Technology Development Agency (NITDA) of Personal Data breaches within 72 hours of becoming aware of the breach.⁵⁸

At a minimum, first and second level support contacts for applications and assets should be defined and recorded in an information asset register (see 4.3). Contact information should be up to date. Such support should also have clear agreements in place for expected response time.

Development and annual testing of an incident response plan (see Dimension 3: Organisational strategy) will help ensure an organisation is ready when, and it is likely when not if, an incident occurs.⁵⁹ ⁶⁰

4.12 External risk management (including interoperability)

External risk deals with the enemy outside. Building strong gates is helpful, but it is also helpful to know as much about your enemy as possible. What are their strengths and how can they be used against your organisation, what are their weaknesses and how can they be exposed to avoid confrontation?

Much like internal risks, external risk management begins with an assessment and corrective plan for your own weaknesses. Employing techniques previously outlined such as network scanning and vulnerability tracking (see Dimension 6: Technical capabilities), and a robust information asset and risk register (see 4.3) will help reduce your exposure to external risks. Regular internal and external audits will surface potential gaps and ensure these are accounted for and addressed. Patching machines and devices regularly will help prevent exploitation of known bugs (see Dimension 6: Technical capabilities). Finally, general user awareness (see Dimension 5: Awareness, Education, and Training) of different types of external attacks will help ensure that malicious actors cannot trick their way into attacking the organisation.⁶³

4.14 Third-party audit of controls

Supplier chain risk is one of the highest risks posed to organisations. The only way for organisations to be fully aware of the risk of their supply chain is to gain a clearer understanding of the security measures that their third-party suppliers have put in place. 

As the dependency on outsourcing in healthcare organisations is often increasing, it is important that suppliers and partners are held to the same high security standards as your organisation. It is essential to have appropriate security certifications, contracts that clearly outline roles, responsibilities, accountabilities, and liabilities, and be clear on what access and controls they have within your healthcare organisation’s systems.

To reinforce validation of security readiness, having third parties regularly audited is also useful. This should be proportionate to the requirements placed on the suppliers and not an audit that reflects only internal organisational standards. Requiring these audits as part of a procurement contract is not unreasonable.

5.1 Employee engagement and cyber awareness raising

The importance of employee engagement with cybersecurity planning cannot be underestimated. As gatekeepers of sensitive data and information in an organisation, all employees should be aware of the importance of cybersecurity and should be supportive of efforts to protect data and systems. Ensuring that staff realise the importance of cybersecurity is one of the most critical ways to help an organisation build resilience and ensure patient safety. There are a range of engagement strategies to raise awareness and educate staff on cybersecurity measures. These include but are not limited to:

• Regular short online or in-person information sessions on cyber threats and the basics of cybersecurity, actions they can take to protect patients, relevant internal policies and guidelines staff should follow, overviews of basic preventative actions staff should incorporate into their day-to-day working, question and answer sessions between staff and ICT/cybersecurity teams.
• A cybersecurity resources hub where staff can go to learn more about the relevant polices and guidelines they should follow and where they can seek help and more information.
• Cybersecurity awareness reminders in the staff newsletter, regular emails, and/or notice boards positioned throughout the organisation.

Those responsible for employee engagement and awareness raising should be mindful that employees will often be overburdened with other tasks and so activities and resources should be targeted and concise to ensure maximum participation. It is important for leadership and ICT/cybersecurity personnel to take part in engagement and awareness raising activities to highlight that everyone in the organisation must be active in addressing cyber threats.

Employee engagement and awareness raising planning and resources should be regularly updated to reflect the most up-to-date cyber threat landscape.

5.3 Technical staff training, with minimum cyber literacy requirements for staff

Many cybersecurity frameworks require that staff, including those with specialist roles, are trained appropriately for their responsibilities.⁶⁵ ⁶⁶ In addition to vetting, staff should be regularly trained and tested for comprehension. All organisations should have a minimum training and test programme for cybersecurity and data protection that includes safe communication practice, adequate protection of user credentials, information classification levels, how to safely transfer sensitive data, and relevant government regulatory requirements.

Training and testing should be provided to all staff with access to systems, as well as those without, as part of developing a wider security culture. This includes contract staff and third parties such as data processors. Training all staff, not just those with access to systems, can foster a culture of safety where all staff are aware of social engineering, people acting suspiciously, or accessing systems that they should not have access to.

Research has shown that cybersecurity risks are reduced by 70% when businesses invest in training and awareness.⁶⁷ If the organisation cannot provide this training, it can be adopted or outsourced. There are many good and free examples of training available on the Internet, for instance the US National Institute of Standards and Technology (NIST) website lists free and low cost online cyber learning content for ICT career and professional development, and employee awareness training.⁶⁸

5.2 Measures to ensure that only appropriately trained and qualified individuals are given cyber responsibilities

Human beings are a critical part of an organisation’s defense system. Vetting should be performed to ensure that those with access to sensitive/privileged data and systems are trained to have such access. An organisation should regularly review roles and responsibilities and match these to required vetting requirements to ensure that appropriate individuals are hired. Building a matrix of these requirements will help maintain appropriate hiring practices.

Criminal background checks are a minimum requirement for most roles, but further vetting could include basic cybersecurity awareness tests or role-specific technical testing. Developers for software should understand principles for secure by design approaches, which ensure that applications are built and released safely. Microsoft offers a suite of resources on secure development lifecycles. Procurement staff should have an understanding of cybersecurity so that any contracts with third parties have cybersecurity requirements embedded.

Vetting should be managed as part of an employment lifecycle to ensure that staff are reviewed periodically for ongoing access and compliance. The Organization for Economic Co-operation and Development (OECD) offers detailed contextual guidance on managing the employee lifecycle within an information security framework.

5.4 Provision of materials/resources outlining regulations, best practices, and reporting systems in place

A useful means of encouraging staff to engage with cybersecurity policies and planning is to ensure easy access to materials and responses outlining relevant regulations, best practices, and the reporting system(s) set up within your organisation (see Section 5.1). As staff will be managing a range of priorities, it is important to ensure the process of seeking and utilising materials and resources should not be difficult or time-consuming. These documents should be as short and clear as possible, available in one place, and available for everyone to access, at any time.

Depending on the resources available to staff within your organisation, materials and resources could take the form of one/several of the following:

• Electronic information available to all staff on the organisational Intranet or other official online platform used by staff.
• Paper copies of materials and resources available for staff to read in-house or collect and take home.
• The appointment of a designated cybersecurity liaison person responsible for discussing any questions or concerns with staff members across the healthcare organisation.

Regardless of how the provision of materials and resources will be offered within your organisation, it is essential that staff are made aware of where they can go to access them. See Section 5.1 for examples of how to share this information with staff.

6.1 Access control

In healthcare it is critical that staff have access to information and systems required to perform their duties. However, there are three principles that underpin building and implementing access requirements. Note that these principles apply equally to human and system accounts, as there should also be controlled trust between systems.

The first principle is that staff should only have access to the information they require when they require it. Granting free-standing access to everything might* make it very easy for staff to perform their job, but it also creates an environment where there is very little control over sensitive information and systems. On the other hand, making an individual justify every request for access might be safer, but will severely limit the speed of care delivery. The best approach is that systems and information structures support on-demand access with little to no human interaction. This can be achieved by using intuitive classification systems and by monitoring access across systems.

This leads to the second principle: access should be implemented in an intuitive way to minimise the risk of credential sharing or workarounds. By using intelligent classification labels applied to your systems and data, you can ensure that these labels correspond to access roles which minimise unauthorised access. For example, you can label a dataset such as medications with a label like AE for accident and emergencies, then assign ambulance staff the role of AE so that they will have access to medications for any patient. This approach is referred to as role-based access control (RBAC). To keep in line with the first principle, you could minimise this access to only current or recent medications, as historic medications will be of less relevance in an emergency context. This turns the RBAC approach into attribute-based access control (ABAC), which is a much higher grade of security.⁶⁹

Supporting the other two principles is the third principle: all access should be recorded for monitoring and audit purposes. A common mistake is assuming that access approval is sufficient and that monitoring access is not required. Continuous recording of access can provide two important benefits. First, you can correlate between systems to ensure that staff only access the information they should. For example, a patient in the staff member’s care and not another patient they might have an interest in. Second, you can build or integrate intelligent systems that can monitor access and look for irregular patterns, e.g., out of normal hours access or access from devices a person would not normally use. Although it is difficult, if not impossible, to monitor modern access logs, robust log management is essential for automation in security.⁷⁰

*In reality, free-standing access is often counterproductive as it creates conflicts on system and information updates resulting in inconsistent records and driving overhead in manual resolution efforts.

6.3 Secure mobile devices and medical devices

The Internet of Things (IoT) has made it easier to connect interoperable smart devices across a range of settings, enabling better care for patients. However, any device connected to a network is susceptible to attack. Recently an attack of cameras led to over 150,000 live feeds being exposed to unauthorised viewers, including cameras in hospitals.⁷³ Widespread use of messaging platforms like WhatsApp on personal devices among clinicians also presents security challenges, including international transfer of data and local device storage of images.⁷⁴ It is therefore imperative that all connected devices are secured, and that staff are educated on the risks of common tools.

To ensure that clinicians are appropriately using technology, it is critical that a mobile device strategy, including “bring your own device” (BYOD), is created and that an acceptable use policy for these devices is understood and agreed to (see Dimension 2: Governance). Allowing BYOD access to key communications for email and messaging can help prevent the use of personal emails for clinician-patient interaction, but this access needs to be supported by device and communication protections including antivirus software, encrypted transfer, and administrative controls on data retention. Research has shown that technical approaches must also be backed by cultural change, with all three security dimensions (people, policy, and technology) having equal attention.⁷⁵

All devices, connected or otherwise, must also be regularly updated to ensure they are not only secure, but also continue to be safe to use clinically. This means that there must be a regular schedule of updates for “firmware”, the software that controls the basic functions of a device. As previously mentioned, there should also be controls on trust between devices on the system. Even devices as simple as printers are at risk of attack, as shown by the successful hijack of over 28,000 printers.⁷⁶ Unsecured devices should not be able to be plugged into the network using open Wi-Fi or network ports. All devices should be registered and tracked in an asset register and should be monitored for updates and usage.

Figure 7: Areas where intrusion detection needs to be considered⁸¹

6.5 Regular patching and software updates

The use of supported operating systems and adopting an “evergreen IT” strategy”, an approach which emphasises making small, iterative updates to an organisation’s IT systems on an ongoing basis, is the optimal approach to securing systems. However, whether the healthcare organisation has an evergreen strategy or not, the importance of regular patching for cybersecurity cannot be underestimated. No one would think that a gate with a hole in it was secure just because it’s on their land, but quite often this same logic is applied to systems on a local network. A 2020 report by security firm Bitdefender showed that a staggering 60% of breach victims in 2019 cited unpatched vulnerabilities as a main reason for breach.⁸² It’s vital that projects to update critical software versions, such as upgrades to Windows 10, are not just a post-attack reaction.⁸³

To enable regular patching and software updates, all devices must first be cataloged in a central location. This “asset register” is the key to being able to monitor the overall status of vulnerabilities due to outdated software. There are many tools available to also scan your network to monitor for unregistered devices, to ensure that the register stays up to date. Many settings in healthcare require continuous service, so any interruptions due to patching or updates can have an impact. Testing and business continuity planning should be used to mitigate the risks of outages. Informing staff of the importance of patching will help gain buy-in for any potential disruption requirements.

Once preparations are made for patching and software updates, the process should be as automated as possible. Leveraging off-the-shelf or vendor patch management systems can help ensure that patches are installed as seamlessly and quickly as possible. These software systems can be tuned to install vulnerabilities according to criticality, meaning that bugs that are most severe are addressed first, while vulnerabilities that are not as risky can be deprioritised in favor of minimising disruption to services. Personal and connected medical devices must also be up to date, not just workstations or servers. Your BYOD policy (see Dimension 2: Governance) should also prohibit unprotected or unpatched personal devices from accessing your network.

6.7 Network segmentation

Healthcare will inevitably involve both patient-facing and internal systems. These two types of services are a simple example of where a healthcare organisation can benefit from considering network segmentation, the division of a computer network into smaller parts to better control how traffic flows through the network. One of the key benefits of network segregation is to prevent lateral movement, which limits the impact of a compromised system and can help secure on-premise infrastructure if organisations have not made the conversion to cloud.

The need for segmentation will be much more complex than simply segmenting patient-facing and internal systems. For example, you can further segment your patient-facing systems in terms of web servers and data servers, as your web servers will need to access your data servers and your patients will access their data through the web servers. Therefore, the data servers do not need to be publicly accessible like the web servers. Such public service zones are often referred to as demilitarized zones (DMZ).⁸⁸

In a good security configuration, you will have any number of zones that host different types of services and data, considering the needs of the application. Increasingly, cloud services are offering such configuration capability with added protections by default. For example, Amazon Web Services (AWS) uses virtual private clouds (VPC) supported by private and public subnets to create a dedicated area for services.⁸⁹ These VPCs also benefit from being in different availability zones, adding resilience to your services in case of an outage. Other cloud providers also provide similar services. Leveraging cloud for these types of configurations abstracts a lot of responsibility for security from internal resources. For example, access to physical hardware and data centres is handled by AWS instead of your healthcare organisation. This is called a shared responsibility model.⁹⁰

Closely aligned with network segmentation is service segmentation. Micro-services are a way of taking discrete components of services, for example your patient administration system (PAS) and your electronic health record (EHR) service and connecting them through communication channels but without each system having to access the other system’s data directly.⁹¹ This is usually done using application programming interfaces (API) that enable a limited set of access routines to make pre-defined updates and requests for data. This greatly improves security, stability, and even application performance, as you don’t have to be concerned with synchronising changes between applications, so long as the API is still able to handle the right request after changes. This, coupled with network segmentation, means that the window of opportunity for malicious activity is greatly reduced, akin to opening and locking a window just enough to let in a breeze but not a person.

6.9 Data anonymisation and minimisation (e.g., for data extracts)

Alongside access control and encrypting data is the need to consider what data are required to perform data analysis in the first place. Although healthcare professionals will need access to sensitive data for patients in their care, for example name and age, many data users will not need such detailed access. Those using data for planning, commissioning, and research purposes can most likely perform their job function on a much less granular level of detail. De-identifying or anonymising data can help ensure that data that are released outside of your control, e.g., into other technology environments, remain protected.

What exactly constitutes de-identification of data is very much dependent on the dataset and the purposes the data are required for. Data protection regulation across countries (see Dimension 2: Governance) dictates that shared data should be appropriate to the purpose for which they are shared, especially when it comes to special types of data such as healthcare data.⁹⁷ Will data analysts require access to full date of birth for example, or will they require exact admission date? The answer is most likely no; therefore, these fields can be minimised to month and year to help protect the identity of the individual they refer to. Does the analyst require all users for all years, or can they use a subset of diagnoses and a limited range of years instead? Minimisation and other similar safeguards such as independent data access review, legally binding contracts, and minimum data security standards help ensure that data are used safely and with respect for patient privacy.⁹⁸

In addition to de-identification of data, there is an increasing trend towards “synthetic data”. Synthetic data are data that act like the real data but are not identifiable. There are many types of synthetic data, but the two most common versions are synthetic data generated from real data, by means of modifying original data, and data generated from scratch to meet the needs of the analysis, usually based on some requirements such as rates of disease and socio-demographic percentages.⁹⁹ ¹⁰⁰ The first method of transforming real data into synthetic data is very similar to de-identification but uses quite sophisticated algorithms to maintain information of interest while still making the data unidentifiable.

This works quite well for building sophisticated models that require data that closely resemble real world data. On the other hand, for simple testing of application interfaces and user experience, there are many programming language modules that support ground-up synthetic data generation.

6.11 Gateway security

In addition to requiring appropriate protective software on corporate and personal devices, protection can be provided centrally by funnelling all traffic through a central gateway that provides security services. This is usually referred to as proxy, secure web gateway, or internet gateway security as public bound traffic is intercepted and cleaned in transit.¹⁰³ Such software can provide capabilities for automatically blocking known harmful URLs, scanning downloads for viruses and malware, and even scanning emails for phishing attacks. However, it is important to note that such tools are usually* useful in the same way as virus and malware protection in that they rely on intelligence as it becomes available.

An organisation can block all internet traffic by default and then only enable trusted websites, a process known as default blacklisting. This makes sense in some cases where staff do not require default internet access, but this can seriously impact the productivity of your healthcare organisation and lead staff to rely more on personal devices. It is beneficial to build a policy that considers the full spectrum of user requirements and the consequences of overly tight controls.¹⁰⁴

*Artificial intelligence and machine learning are increasingly being built into such software, but this has the potential to cause problems as well as solve them.

Figure 6: User access principles to help guide access implementation

6.2 Passwords/authentication – Domain-based Message Authentication, Reporting and Conformance (DMARC)/identity management/multi-factor authentication

Passwords and authentication are at the heart of ensuring a person is who they say they are and that they therefore have the right to access what they need to access. It is important to also consider that authentication does not just apply to people, but to systems as well. One system must know that another system is what it says it is and that it has a right to access the information requested. Attacks like spoofs, e.g., pretending to be someone else, or man-in-the-middle attacks, where systems intercept data and then transmit it on pretending that they are a relay, are very common.⁷¹

Much like access control, good authentication is a case of ensuring the right access to the right thing. To support this, identity management and identity verification go hand in hand. Identity management is the process of creating a role associated with a particular person, which can be a simple username associated with specific permissions or a more complex set of permissions belonging to a particular group of people, for example “nurses” or more specifically “intensive care nurses”. Identity verification is the process of ensuring that a person is who they say they are, which can be password-based authentication or in a more secure environment, using multi-factor authentication. Multi-factor authentication enables a person to use a temporary token or code to validate themselves. Commonly this is done via a combination of single sign-on applications such as Google or Microsoft combined with a token generating app or via tokens sent over short messaging service (SMS) to a person’s mobile phone. Applications can also use temporary tokens for authentication to services, and many cloud vendors now enforce short-lived tokens for system-to-system communication, often referred to as app tokens.⁷²

6.4 Technologies for threat detection and processes that send alerts

Cybercrime is continuously evolving, and cybercriminals are often at the forefront of advanced technology. The best defense is surveillance and quick response mechanisms. Backing awareness and training with intrusion detection and response software can help ensure that early intervention can be swift and effective.

Although advanced techniques like deep learning can be integrated into intrusion detection, basic anomaly detection software can also be a starting point to help address potential breaches.⁷⁷ Anomaly based intrusion detection, or the process of looking for unusual patterns of access, is one type of intrusion detection among many as shown in Figure 7. This technique can be quite effective in automatically notifying of potential threats, which is why the market for anomaly detection software and services is due to hit $8.8 billion by 2027.⁷⁸

However, a good intrusion detection policy should consider multiple approaches even in anomaly detection.⁷⁹ It is also important when implementing anomaly detection software to consider the overhead of false positives and other types of noise, as this can take resources away from other important work.⁸⁰

6.6 Data encryption

Healthcare data are among the most sensitive data an organisation can hold. However, unlike most other industries, the impact of not treating healthcare data with the respect it deserves can pose a risk to patient safety and reduce the ability to use wider data to improve general population health and care. One of the best protections you can have on data is to encrypt it so if it is obtained or intercepted, it still cannot be used for the wrong purposes. This requires that data are encrypted both while stored, also known as “at rest”, and while the data are being transferred, referred to as “in transit”.

Encrypting data at rest with strong encryption is getting much easier given that many vendors offer it within their platforms at a storage level. Currently strong encryption is defined as 256-bit Advanced Encryption Standard (AES) encryption, which with the fastest super-computer, would still take millions of years to crack.⁸⁴ With quantum computing this will need to be revisited as cracking encryption of this level could become as computationally intensive as it was to create the encryption.⁸⁵ Encrypting data is not enough however, as additional steps are required to ensure that data cannot be easily decrypted. For example, the keys used to encrypt data should not be stored in the same systems as the data. Leveraging hardware security modules (HSM), which are dedicated hardware devices for encryption, or key vaults on separate networks can help ensure that if data storage is breached, it doesn’t mean the data are at risk automatically.

In the same way, data encryption in transit has become much easier due to common vendor support. Transport Layer Security (TLS), which encrypts data se to ensure that hackers are unable to see what is transmitted, should be used where possible for data encryption. Where this is not possible⁸⁶, Secure Sockets Layer (SSL), an encryption standard for protection on websites that access sensitive information has also become widespread.⁸⁷ Insecure mechanisms for copying files between areas, such as the “remote copy program” rcp command, have been replaced by secure tools such as “secure copy” scp, which is encrypted through libraries like OpenSSL, an open-source standard for SSL communication.

When implementing technology, the policy of a healthcare organisation should always be to ensure encryption for sensitive data. Encryption takes up a computational overhead and therefore requires more resources. In cases where you transfer a lot of information, it may make sense to segment your data into sensitive and non-sensitive to allow non-sensitive information to be transferred without encryption.

Figure 8: The AWS Shared Responsibility Model

6.8 Appropriate anti-malware/anti-virus and firewalls

Every healthcare organisation should, at a minimum, have a policy for malware and virus protection software and ensure that these are installed both on organisational assets and personal devices where necessary. Firewalls help ensure the legitimacy of traffic across the network and help stop any unwanted traffic from rogue devices that may contain malware.

Malware on mobile devices is a growing threat, even if it is still not as common as on desktop devices. A recent investigation found that nearly 16% of all mobile devices were infected with malware, and that this disproportionally impacted emerging markets.⁹² Protection software should be set to automatically update to ensure that the latest threats are always being accounted for. Although common mobile software platforms such as Google Play and Apple Store are monitored and vetted, this does not stop all malicious software from slipping through the net. For added protection  a healthcare organization should enable services that scan applications before  they are downloaded and installed, not just when the application is added to the software portal.⁹³

A secure practice is to control the software that can be installed, either through use of custom software mirror portals or through software whitelisting. Mirror portals include hosting an organisation-specific instance of the Comprehensive R Archive Network (CRAN) to control which R language modules are installable.⁹⁴ Such basic libraries might seem innocuous at first but there are methods for circumventing default security to distribute malicious code through these repositories.⁹⁵ ⁹⁶ Software whitelisting limits the software names and versions that can be installed to a local machine and often also controls the installation so an individual does not need greater access to install software.

6.10 Checklist with minimum hardware, software, and standards requirements for technology to manage patient information

Organisations need to understand the full life-cycle management of any system procurement, particularly if that system is likely to be in service for several years. Often clinical systems will rely on the operating systems of the time (e.g. Microsoft’s operating platforms), but these will have an end-of-life far quicker than the clinical system they support. Organisations therefore need to understand how the operating system can be updated to remain current, and who is responsible for doing this.

Managing patches and updates is very important, especially for healthcare organizations, but some of the issues caused by EOL software can be avoided in the first place by ensuring that systems are using up to date hardware, software, and standards. Adopting open standards and software can also improve the ability to avoid vendor lock-in and ensure long-term support from community developers. This approach can be coupled with microservice architecture to make your estate easier to update, improving the overall flexibility and security resilience of your healthcare organisation.

When purchasing healthcare ICT systems, it is tempting to buy an all-in-one solution, also referred to as a “megasuite”. On paper, it seems that such solutions are cheaper, easier to implement, more robust, and safer. However, Gartner research has shown that the megasuite can result in increased cost of total ownership and less innovation.¹⁰¹ It may also be less secure as there is a larger reliance on one monolithic data store that requires constant configuration to ensure appropriate access for both staff and interconnected systems. When designing your architecture, you should look for interoperability as a standard. It should be easy to integrate your system with other systems. The data should also be easily abstracted from the application, meaning that appropriate storage solutions can be chosen without being tied directly to the application you implement, referred to recently as separating the data layer.¹⁰² This then makes it easier to implement appropriate segmentation as mentioned previously.

6.12 Cloud capability (and standards) to ensure better security

Many healthcare organisations have moved, or are in the process of moving, to cloud-based infrastructure. This is because cloud platforms provide a myriad of benefits that reduce burden on local ICT teams. For example, in most cloud provider configurations, physical and device-level security is handled by the provider. Cloud providers also offer as-a-Service (aaS) solutions that can enable a “serverless” estate, meaning that even operating system-level security is handled by the cloud provider. Many cloud-based managed services are also defaulted as little to no trust, meaning that access must be explicitly enabled. This, along with easy to implement segmentation and built-in microsevice architecture makes for a very powerful security infrastructure capability out of the box.

Cloud is not without its limits though. It is important to consider these limits when adopting the cloud. For example, cost management in cloud services needs careful attention, and it is possible without the right protections to become the victim of so-called Denial of Wallet (DoW) attacks.¹⁰⁵ However, cloud providers often provide many services to help address cost management including billing alerts and thresholds. Cloud services also provide other robust security services including virtual networks, distributed denial-of-service (DDoS) protection, load balancers, and firewall capabilities. These are often set up across different regions to prevent loss of business continuity in the case of a disaster or regional outage. Cloud professional services also provide consultancy on security configurations, and AWS even provides a free security scanning capability and enterprise customers with architecture reviews.¹⁰⁶ ¹⁰⁷ Cloud configurations can also be hybrid, connecting with local infrastructure where required through virtual private networks (VPN), internally hosted cloud hardware, or even direct connect services.¹⁰⁸