CV/Work/Backup scenario

Scenario: ransomware-proof backups for a dental practice

A dental practice keeps its X-rays, CBCT images and scans on a network storage device that is also its only backup. This is how I would protect the data, so that after a ransomware attack the practice can treat patients again on the next working day.

Starting point

The practice has four treatment rooms, a CBCT unit and an intraoral scanner. The imaging data comes to about three terabytes and grows by a few hundred gigabytes a year. Everything sits on a NAS in the server cupboard. The same NAS backs up the practice software every night to a second share. Nobody has ever tried a restore, and three people and the device technician know the NAS password.

What is at stake

Ransomware encrypts everything it can reach over the network. If data and backup sit on the same device and can be reached with the same credentials, it encrypts both in one go. Then there is no clean copy left to restore the practice from.

For a dental practice this weighs twice as much. Under the German Radiation Protection Act, X-rays have to be kept for ten years, longer for children and adolescents. Without images and patient records there is little treatment possible, and every day of downtime costs appointments and trust.

Approach

1. Inventory and data classes

First I record which data exists, where it lives and how quickly it has to be back after an outage. The practice needs the practice software's database and the images from recent months on the same day. Older images may take longer, but they have to stay complete and readable. These classes decide how often backups run and how long copies are kept.

2. Three copies, one of them immutable

The backup follows the 3-2-1 rule, plus one copy that nobody can delete or change.

The off-site copy is encrypted before upload. The key stays in the practice and is also kept on paper in the safe. Whether cloud storage with a deletion lock or rotating drives fit better is decided by the practice together with me and its data protection officer.

3. Separate the backup from the practice network

The second backup device sits in its own network segment, and only the backup service may write to it. It has its own credentials, which are not stored on any practice computer. I separate the device networks for X-ray and scanner from the administration network, so an infected reception PC cannot reach the imaging.

4. Monitoring

Every backup reports whether it ran and how large it was. If a report is missing or the size changes unusually, a warning goes out. A sudden jump can be a sign that data is being encrypted right now.

5. Practise the restore

A backup is only worth something once the restore works. Once a quarter I restore a selection of data to a test machine, open images in the viewer and check that the practice software starts with the restored database. Each test is recorded, with duration and result.

6. Emergency plan

The emergency plan fits on a few pages and also exists on paper. It says who takes which devices off the network, whom the practice calls and in which order the systems come back. The practice software comes first, then the current week's images, and the archive last.

The result I would aim for

• After an attack, the practice is working again within one working day, with practice software and current images.
• At most the data since the last nightly backup is lost, usually only the last hour.
• Retention periods are met and documented across all copies.
• The practice can show with records that the restore works.

What it takes

The practice needs to set aside a few hours for the inventory and name one contact person who arranges appointments with the device vendors. Decisions are needed on where the off-site copy lives and who takes which role in an emergency. Costs come from a second backup device, off-site storage and the time for setup and tests. We work out the exact scope in the first call.

Related services