The attack steps seem to be the same in most of the attacks that can be summarized to the below steps:

1. Reverse engineer the medical device and communication protocols.
2. Identify vulnerabilities that can be easily manipulated.
3. Utilize more powerful devices in terms of their communication range or manipulate the stipulated communication device's message packet. 
4. Medical device attacked!

Lets jump from Defibrillators to Insulin Pump which is another device that has been subject to attacks - Hijacking an insulin pump. To specifically notes most of the required hardware including the medical device was off the shelf. Summarizing:

• Experimental setup of attacks: USRP, glucose meter, insulin pump and remote control. Software: GNU radio for intercepting radio communication using USRP. Frequency of communication is public thus daughter boards and antenna are of that frequency. Modulation scheme is detected by down-converting it to near baseband. Packet format and ID is found by eavesdropping on the communication and intercepting the data packets. Generally data packets for an insulin pump are: Device type-Device PIN-payload information- CRC-end pattern.
• Attacks can be without the knowledge of PIN like DoS, privacy invasion etc. and with the PIN. USRP, setup can trigger active and passive attacks. Passive for signal knowledge and eavesdropping and active for control of pump.

Attacking commercially available devices! Not in the TV show Homeland, but in reality. Most of these attacks can be pointed to the manufacturers not paying too much attention to security. On the other side, security is still not a strictly enforced necessity so it is natural that manufacturers would go easy on means to provide the same. With such research publications, there is spread of the emphasis of security for the future of medical devices.
To start with a cool title to the paper - Take two software updates and see me in the morning. A summary of the paper:

• A commercial Automated external Defibrillator is taken and malicious updates are successfully launched.No, cryptographic controls were detected. Several software vulnerabilities are present including buffer overflow and cryptographic flaws.
•  IDA Pro5.6 is use for reverse engineering and off-the shelf hardware/software used. Vulnerabilities discussed: buffer overflow, weak password authentication, weak CRC as digital signatures and credentials stored in plaintext.
• Limited to one manufacturer but opens the door for the issue of medical device attacks.

  I finally end this blog with breaking medical devices. Though this might sound like a pessimistic topic it gives hopes for optimism of the need to incorporate safety measures in medical devices for the future where cyberattacks and security/safety issues will only rise. Many of the topics and reference provided will include the attack and also the countermeasure for the same.
  The classical incident of breaking medical devices is of Barnaby Jack who I spoke about in my first post of this blog. Have medical device manufactures reacted by providing countermeasures for the same? what is the situation from their side?..The answer is still uncertain, but as we have seen there is tremendous work from the research field and an active involvement from the FDA.

Software Security: Software security has been/is an active area of research for ages in computer systems. But, with medical devices becoming more complex with more software functionality the risk factor for software attacks has exponentially increased with medical devices in the loop and IoT in general. Software security is an expansive topic by itself and it is hard to cover. The following reference gives the high level requirement of assessing the integrity of medical device software. Though they introduce tools to check software, the bigger picture is that software in medical devices is something to worry about (it's written by people at the FDA!).
Link: Static Analysis of Medical Device Software using CodeSonar

Hardware Security: Hardware security as stated in the Malware section has been growing aggressively, mainly attributed to the face that computer systems nowadays have been manufactured by several companies and especially outsourced. With this into account it is not possible to detect hardware threats that may have been implanted into the computer system. The following links give a brief picture of hardware risks and hardware layers.
Links:

• Generic Infusion Pump Hazard Analysis and Safety Requirements Version 1.0
• SoK: Security and Privacy in Implantable Medical Devices and Body Area Networks

 Miscellaneous: This topic considers the aspects of the following:

1. Resources: This constraint has been discussed as a double edged sword as security algorithms are resource hungry and medical devices are severely short of that. This was the case in smartphone in the early 2000's but with the advent of technology it is no longer a problem, however that can be the testbench for the current IoT/medical devices.  
   Links:
• Low-Energy Encryption for Medical Devices: Security Adds an Extra Design Dimension
• Security in resource-constrained computer systems
2. Algorithms: Analysis of various algorithms for security which can be encryption or decyption or unique algorithms for security in such environments like medical devices or sensor nodes. Again, sensor nodes can be generalized to medical devices because they have roughly the same characteristics.
   Links:
• Analysis of Hardware Encryption Versus Software Encryption on Wireless Sensor Network Motes
• Absence Makes the Heart Grow Fonder: New Directions for Implantable Medical Device Security (You can see the pun :D, this article is worth a read!)

Malware: Malware is a common term heard in the software realm from a long time. However, it has successfully creeped into the hardware realm too and is commonly termed hardware trojans. With hardware malware comes the highest risk of security levels that will require robust hardware-software to counteract with. If such a malware is implanted in a medical device then the consequences are surely fatal. The following paper discusses in detail the malware's evolution in smart devices and possible detection schemes.
Link: Evolution, Detection and Analysis of Malware for Smart Devices

The next set of links and material would be on analysis of security in medical devices. There is a wide array of research that I have simplified under this topic. It incorporates how research has been working on in analyzing security, what aspects are considered?, how is it getting better?, what are the vulnerabilities? etc. Analysis of security also involves general aspects of software, hardware analysis of security, malware analysis, possible resource analysis for using security schemes in medical devices etc. The analysis of security is a vast topic and I would subdivide it as follows, giving a reference for each that would introduce the viewers to the topic and what I wanted to convey.

1. Malware
2. Software security
3. Hardware security
4. Miscellaneous 

More on the FDA: The FDA is an integral body that comprises of tonnes of data regarding medical devices their recalls, threats, security failures etc. It also provides checklists of organizations and manufactures for providing safety and security. The relevance of FDA has been immense in most of the works in medical device security. However, the FDA has no legal remit from Congress to directly regulate privacy!! The following readings provide analysis of the FDA databases along with the involvement of FDA in research.

• Security and Privacy Qualities of Medical Devices
• Inside Risks Reducing Risks of IMDs
• Safety Issues Involving Medical Devices