Device Risk Assessment
The downtown hotel's IT manager, Grace Liang, has three findings from testing the new network, and money to fix one of them this month. The general manager would rather fix the televisions, the one problem guests have complained about. Before the managers decide, each finding gets a rating, high, moderate, or low, so they can see which one matters most.
| Finding | Device | What is wrong | What the device holds or controls |
|---|---|---|---|
| 1 | Reservations server | Each night the booking system saves the next day's arrivals list to a web address that needs no sign-in. Anyone who finds the address can download the list. | Arriving guests' names, home addresses, and scans of foreign guests' passports |
| 2 | Door-lock hub (the wireless hub the locks report through) | The page for encoding room key cards accepts any password of six characters or more and never locks out after wrong guesses. It can be reached only from the front-desk computers. | Which key cards open every guest room door |
| 3 | Room televisions | A flaw allows anyone on the guest Wi-Fi to make a room's television restart. | The movie a guest is watching; the screen also shows the guest's name and bill, which the flaw can't reach |
A rating weighs two things: how much harm the device could do in an adversary's hands, and how likely the weakness is to be used. Weigh both for each finding, then compare with the ratings that follow.
Three ratings
The arrivals list holds some of the most sensitive data the hotel has, and reading it takes no skill at all, only the address, so finding 1 is high. Finding 3 is low, whatever the complaints: the worst case is a guest's movie starting over. Finding 2 falls between them. The lock hub controls something critical, but the weakness is a weak sign-in, and only someone at a front-desk computer, or someone who had already taken one over, could try it. Both of those make it less likely to be used than finding 1, and the scale below counts weak authentication, and weaknesses less likely to be used, among the causes of moderate risk. The managers fund the fix for finding 1, and finding 2 goes on next month's list.
| Rating | What the scale says | At the hotel |
|---|---|---|
| High | High risks from device vulnerabilities can compromise sensitive data or critical operations. | Finding 1, the arrivals list |
| Moderate | Moderate risks can come from weak authentication requirements, or from vulnerabilities that are less likely to be exploited. | Finding 2, the lock hub's sign-in page |
| Low | Low risks typically come from vulnerabilities that would have little impact if exploited. | Finding 3, the room televisions |
Pacemakers with a radio
A pacemaker is an embedded computer sealed in a case about the size of a matchbox, placed under the skin of the chest. It watches the heartbeat through a thin wire, the lead, that runs through a vein into the heart, and sends a small electrical pulse down that wire when the heart is too slow. Many models talk by radio, so a doctor can check and adjust one without surgery.

The U.S. Food and Drug Administration confirmed in 2017 that several radio-equipped pacemakers made by St. Jude Medical, which Abbott had bought that January, had weaknesses in how they checked who was talking to them. Someone other than the patient's doctor, using equipment sold commercially, could send one commands that drained its battery quickly or made it pace the heart wrongly. About 465,000 of them were in patients in the United States. No patient was known to have been harmed. How would you rate that finding?
A pacemaker runs the most critical operation there is, and the flaw let an attacker get past the device's check altogether, with no password to beat at all, unlike finding 2's lock hub. Rated the way the hotel's findings were, it is high. Distance made an attack harder: the adversary had to be within radio range of the patient, with the right equipment and the skill to know what to send. On August 29, 2017, Abbott released new pacemaker firmware that closed the weaknesses, and the FDA called the update a recall. Removing and replacing the devices was not recommended.
A patient with a radio-equipped St. Jude pacemaker could keep a home monitor, the Merlin@home, beside the bed. Each night, usually while the patient slept, it checked the pacemaker by radio. It sent readings to the clinic on the doctor's schedule, or sooner if it found a problem, over the internet, a cell network, or a phone line. Older monitors needed the patient's help: a reader held over the chest, or a telephone handset set into a cradle. The Merlin@home was an embedded computer on a network, and in January 2017, months before the pacemaker update, the FDA had confirmed a weakness in the monitor itself: someone who altered one could use it to send the pacemaker those same harmful commands. St. Jude closed that weakness with an update the monitor downloaded on its own, as long as it stayed plugged in and connected.

The pacemaker's own update in August was different. It couldn't be sent remotely through the home monitor. Each patient had to visit a clinic, where it took about three minutes, and the update carried risks of its own. Based on Abbott's experience with earlier firmware updates, about 1 in 600 devices went back to the old firmware, and about 3 in 100,000 stopped working entirely. So the FDA didn't tell every patient to get it. It told patients and their doctors to talk over the risks of the weakness and of the update at the next regular visit and decide case by case, weighing how much the patient depends on the pacemaker, how old the device is, and what the patient prefers.
Sources: U.S. Food and Drug Administration, safety communication, "Firmware Update to Address Cybersecurity Vulnerabilities Identified in Abbott's (formerly St. Jude Medical's) Implantable Cardiac Pacemakers" (August 29, 2017); Abbott, letter to physicians on the pacemaker firmware update (August 28, 2017); ICS-CERT advisory ICSMA-17-241-01 (August 29, 2017); U.S. Food and Drug Administration, safety communication on the Merlin@home Transmitter (January 9, 2017); ICS-CERT advisory ICSMA-17-009-01A (January 2017).