Original supplied source slides 50–63. The source retains historical examples and wording. Use the classroom explanation for contextual qualifications. Source review is part of the chapter.

Download the original source pack for full slide layout and vector diagrams.

Slide 50 · Maintaining critical service availability

Maintaining critical service availability To maintain availability, you need to know: the system services that are the most critical for a business, the minimal quality of service that must be maintained, how these services might be compromised, how these services can be protected, how you can recover quickly if the services become unavailable. Critical assets are identified during service analysis. Assets may be hardware, software, data or people.

Slide 51 · Mentcare system resilience

Mentcare system resilience The Mentcare system is a system used to support clinicians treating patients that suffer from mental health problems. It provides patient information and records of consultations with doctors and nurses. It includes checks that can flag patients who may be dangerous or suicidal. Based on a client-server architecture.

Slide 52 · Client-server architecture (Mentcare)

Client-server architecture (Mentcare)

Slide 53 · Critical Mentcare services

Critical Mentcare services An information service that provides information about a patient’s current diagnosis and treatment plan. A warning service that highlights patients that could pose a danger to others or to themselves. Availability of the complete patient record is NOT a critical service as routine patient information is not normally required during consultations.

Slide 54 · Assets required for normal service operation

Assets required for normal service operation The patient record database that maintains all patient information. A database server that provides access to the database for local client computers. A network for client/server communication. Local laptop or desktop computers used by clinicians to access patient information. A set of rules to identify patients who are potentially dangerous and which can flag patient records. Client software that highlights dangerous patients to system users.

Slide 55 · Adverse events

Adverse events Unavailability of the database server either through a system failure, a network failure or a denial of service cyberattack Deliberate or accidental corruption of the patient record database or the rules that define what is meant by a ‘dangerous patient’ Infection of client computers with malware Access to client computers by unauthorized people who gain access to patient records

Slide 56 · Recognition and resistance strategies

Recognition and resistance strategies

Event	Recognition	Resistance
Server unavailability	1. Watchdog timer on client that times out if no response to client access 2. Text messages from system managers to clinical users	1. Design system architecture to maintain local copies of critical information 2. Provide peer-to-peer search across clients for patient data 3. Provide staff with smart phones that can be used to access the network in the event of server failure 4. Provide backup server
Patient database corruption	1. Record level cryptographic checksums 2. Regular auto-checking of database integrity 3. Reporting system for incorrect information	1. Replayable transaction log to update database backup with recent transactions 2. Maintenance of local copies of patient information and software to restore database from local copies and backups
Malware infection of client computers	1. Reporting system so that computer users can report unusual behaviour. 2. Automated malware checks on startup.	1. Security awareness workshops for all system users 2. Disabling of USB ports on client computers 3. Automated system setup for new clients 4. Support access to system from mobile devices 5. Installation of security software
Unauthorized access to patient information	1. Warning text messages from users about possible intruders 2. Log analysis for unusual activity	1. Multi-level system authentication process 2. Disabling of USB ports on client computers 3. Access logging and real-time log analysis 4. Security awareness workshops for all system users

Slide 57 · Mentcare system resilience

Mentcare system resilience

Slide 58 · Architecture for resilience

Architecture for resilience Summary patient records that are maintained on local client computers. The local computers can communicate directly with each other and exchange information using either the system network or using an ad hoc network created using mobile phones. If the database is unavailable, doctors and nurses can still access essential patient information. A backup server to allow for main server failure. This server is responsible for taking regular snapshots of the database as backups. In the event of the failure of the main server, it can also act as the main server for the whole system.

Slide 59 · Architecture for resilience

Architecture for resilience Database integrity checking and recovery software. Integrity checking runs as a background task checking for signs of database corruption. If corruption is discovered, it can automatically initiate the recovery of some or all of the data from backups. The transaction log allows these backups to be updated with details of recent changes

Slide 60 · Critical service maintenance

Critical service maintenance By downloading information to the client at the start of a clinic session, the consultation can continue without server access. Only the information about the patients who are scheduled to attend consultations that day needs to be downloaded. The service that provides a warning to staff of patients that may be dangerous can be implemented using this approach. The records of possibly patients who may harm themselves or others are identified before the download process. When clinical staff access these records, the software can highlight them to indicate that this is a patient that requires special care.

Slide 61 · Risks to confidentiality

Risks to confidentiality To minimize risks to confidentiality that arise from multiple copies of information on laptops: Only download the summary records of patients who are scheduled to attend a clinic. This limits the numbers of records that could be compromised. Encrypt the disk on local client computers. An attacker who does not have the encryption key cannot read the disk if they gain access to the computer. Securely delete the downloaded information at the end of a clinic session. This further reduces the chances of an attacker gaining access to confidential information. Ensure that all network transactions are encrypted. If an attacker intercepts these transactions, they cannot get access to the information.

Slide 62 · Key points

Key points Resilience is a judgment of how well a system can maintain the continuity of its critical services in the presence of disruptive events. Resilience should be based on the 4 R’s model – recognition, resistance, recovery and reinstatement. Resilience planning should be based on the assumption of cyberattacks by malicious insiders and outsiders and that some of these attacks will be successful. Systems should be designed with defensive layers of different types. These layers trap human and technical failures and help resist cyberattacks.

Slide 63 · Key points

Key points To allow system operators and managers to cope with problems, processes should be flexible and adaptable. Process automation can make it more difficult for people to cope with problems. Business resilience requirements should be the starting point for designing systems for resilience. To achieve system resilience, you have to focus on recognition and recovery from problems, recovery of critical services and assets and reinstatement of the system. An important part of design for resilience is identifying critical services. Systems should be designed so that these services are protected and, in the event of failure, recovered as quickly as possible.