1.) Responsible disclosure to vendor. Allow reasonable amount of time for a fix to be created and deployed.
2.) (If fix is deployed, release details)
3.) If no fix is deployed in a reasonable amount of time and the vendor is unresponsive, release a PoC that demonstrates exploitability without giving away details. eg: "Here is a pacemaker. Look, I did magic and it stopped!" This is the same idea as releasing the actual vulnerability/exploit, but doesn't put lives at risk. People that could fuzz for any type of a vulnerability would be able to find it on their own anyway.
I agree that ICS and health-sensitive vulnerability disclosure is a trickier field than most. Medical devices, cars, and power plants are much more sensitive than a random kid's iPhone; that's why groups like I Am The Cavalry are trying to address the issue industry-wide.
However, to answer the original question: don't drop a pacemaker 0day at DEF CON. Find a way to fix the problem with the vendor instead. At the very "worst," demo without vulnerability or exploit details.
What does 'fix deployed' mean? How do you actually update pacemaker software? Are you going to wait for 100% of the deployed pacemakers are fixed? What is an acceptable fix rate before you release the exploit?
Pacemaker firmware can almost always be updated using inductive or rf telemetry. In most cases it still requires an appointment with a cardiologist or similar physician though.
And many can now be monitored by the cardiologist from their office as the device uploads data to a server, or can even be reached directly from the physician's console. And both cardiologists and pacemaker companies generally have a pretty good bead on who's walking around with which serial numbered device.
I think you should assume people will reverse engineer patches as soon as they are public. People should treat this like any urgent medical care and address it within hours or days of the patch being available. I don't know much about that area of the industry, but I don't envy it at all. Imagining being the person responsible for a) enabling remote communication, b) allowing updates via remote communication, and c) securing it. What a nightmare situation.
If a large enough majority of people get their pacemakers fixed, it greatly lowers the chances that you'll encounter someone with a defective pacemaker that you can exploit.
1.) Responsible disclosure to vendor. Allow reasonable amount of time for a fix to be created and deployed.
2.) (If fix is deployed, release details)
3.) If no fix is deployed in a reasonable amount of time and the vendor is unresponsive, release a PoC that demonstrates exploitability without giving away details. eg: "Here is a pacemaker. Look, I did magic and it stopped!" This is the same idea as releasing the actual vulnerability/exploit, but doesn't put lives at risk. People that could fuzz for any type of a vulnerability would be able to find it on their own anyway.
I agree that ICS and health-sensitive vulnerability disclosure is a trickier field than most. Medical devices, cars, and power plants are much more sensitive than a random kid's iPhone; that's why groups like I Am The Cavalry are trying to address the issue industry-wide.
However, to answer the original question: don't drop a pacemaker 0day at DEF CON. Find a way to fix the problem with the vendor instead. At the very "worst," demo without vulnerability or exploit details.