tag:blogger.com,1999:blog-51122909953418601702024-03-14T03:47:32.474-07:00Archimedes Center for Medical Device SecurityWhen experts claim the sky is falling, we point out that you're just looking at the ground.Ben Ransfordhttp://www.blogger.com/profile/00120982349595965249noreply@blogger.comBlogger93125tag:blogger.com,1999:blog-5112290995341860170.post-48556108311207822342017-01-10T08:10:00.004-08:002018-10-01T11:01:28.304-07:00FDA’s Role in Ensuring Medical Device Security Under Review<span id="docs-internal-guid-88ce84a8-8920-ca75-b5dd-12f4be347670"></span><br />
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "times new roman"; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Q&A with OIG’s IT Audit Director Jarvis Rodgers Reveals What They’re Looking for and Why</span></div>
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "times new roman"; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjf8XS7wbFR626jBzdKUSsCe8VWHRnhPo-87BttJWyAwJjYTxkKopab-y7qOVMNGaMp3TIu8jPoFttAiKJNrsHEQ3wxnQQN1bKM0ZgifJ4Fv0zfIY89iylo-jFLJGSWWiZtL1D6wRrJwMKy/s1600/iStock-579766232.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjf8XS7wbFR626jBzdKUSsCe8VWHRnhPo-87BttJWyAwJjYTxkKopab-y7qOVMNGaMp3TIu8jPoFttAiKJNrsHEQ3wxnQQN1bKM0ZgifJ4Fv0zfIY89iylo-jFLJGSWWiZtL1D6wRrJwMKy/s400/iStock-579766232.jpg" width="400" /></a></div>
<br /></div>
By Nikki McDonald<br />
<br />
Nobody likes to hear they’re about to be audited. Not even when the subject of the government audit is the government itself. But auditors provide necessary independent and objective oversight that helps keep both individuals and federal agencies honest—and safe.<br />
<br />
As IT Audit Director for the <a href="https://oig.hhs.gov/">Office of Inspector General</a> (OIG)’s Office of Audit Services within the <a href="https://www.hhs.gov/">Department of Health and Human Services (HHS)</a>, Jarvis Rodgers is charged with ensuring agencies are good stewards of tax payer dollars, a big job when you look at the HHS’s vast mission and budget, which totals more than $1 trillion.<br />
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "times new roman"; font-size: 16px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><b style="font-weight: normal;"><br /></b></span></div>
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
The HHS leads a number of important IT initiatives—such as electronic health records, medical device security, and genomic data storage—that impact all Americans. These projects and issues cut across over 100 programs operated by the different agencies within HHS, including <a href="https://www.ihs.gov/">Indian Health Service</a>, which is responsible for providing health services to the 567 federally recognized tribes of American Indians and Alaska Natives and directly operates 28 acute-care hospitals; the <a href="https://www.cms.gov/">Centers for Medicaid and Medicare Services</a>, which funds healthcare for tens of millions; and the <a href="http://www.fda.gov/">Food and Drug Administration</a>, which is responsible for ensuring the safety, efficacy, and security of, among other things, medical devices.<br />
<br />
The OIG announced that in 2017 it will be reviewing FDA’s role in ensuring the safety and effectiveness of networked medical devices. In this interview with Jarvis Rodgers, we asked him why the FDA review is a priority this year, what he looks for when conducting an audit, and what he thinks are the key security issues facing medical device manufacturers right now.<br />
<br />
<b>When your group performs an IT audit, who are you auditing and what are you trying to discover?</b><br />
<br />
We conduct independent IT audits of HHS programs, grantees, and/or contractors. Our audit objectives typically vary, hence what we’re trying to “discover” will also vary. With that said, there are internal and general controls that transcend audit objectives. When auditing (IT, accounting, or performance) we are consistently assessing the stability and strength of the “control environment.” The control environment is the foundation for an internal control system and provides the discipline and structure to help an entity achieve its objectives.<br />
<br />
When performing an after-action report of any process anomaly, the first areas an auditor or examiner will attempt to discover are the risk assessment(s) and internal controls: policies, processes, standard operating procedures, defined roles and responsibilities, etc. These controls help inform an auditor and provide a roadmap to discover where the internal control failure occurred. Whether the issue is national security or medical device security, the roadmap to discover the root cause typically remains the same. Auditors frequently find when there are lapses in response times and process failures that the culprit is ineffective internal controls and inadequate risk assessments.<br />
<br />
The importance of internal controls should not be misconstrued, auditors are not seeking documentation for the sake of documentation. There is consensus: in a mature and highly effective environment, internal controls are indistinguishable from day-to-day activities personnel perform. For those who are unfamiliar with internal controls and the importance of a strong control environment, I highly encourage reading the <a href="http://www.gao.gov/">Government Accountability Office</a> <a href="http://www.gao.gov/assets/670/665712.pdf">Greenbook</a>.<br />
<br />
<b>What is a penetration test and why do you do them? </b><br />
<br />
Penetration tests are a valuable tool in OIG’s IT Audit portfolio. They’re intended to identify vulnerabilities and security flaws in systems, devices, and controls that are in place to protect data and critical resources. This type of information security testing attempts to simulate attacks that are either internal (typically from employees) to an organization’s computer network or outside (e.g., state sponsors).<br />
<br />
<b>Do people tend to panic when they find out you’re going to audit them? Like when the IRS decides to pay a visit?</b><br />
<br />
Reactions of auditees do tend to vary. My advice is: although we are independent, it’s important to remember that we’re all on the same team! We’re ultimately trying to achieve the same goal; in many cases, those aims are an effective and efficient system/business process. Audits tend to go south when the auditee is adversarial, dismissive, and lacks transparency. Remember—auditors are people too! When auditees work with the audit team the final audit report can benefit all parties, and it’s more effective, relevant, and timely.<br />
<br />
In the <a href="https://oig.hhs.gov/reports-and-publications/archives/workplan/2017/HHS%20OIG%20Work%20Plan%202017.pdf">HHS Office of Inspector General’s fiscal 2017 work plan</a>, your agency announced that it plans to review FDA’s role in “ensuring and monitoring the safety and effectiveness of networked medical devices.” Why is this a priority for 2017?<br />
<br />
Security of the Internet of Things (IoT), and specifically medical devices, is an emerging issue and a growing concern for our stakeholders. Full disclosure, I do not watch <a href="http://www.sho.com/homeland">Homeland</a>; however, I am aware that in Season 2 Vice President Walden’s pacemaker was hacked and, although fictitious, this was a game changer for medical device security. People all over the world now wondered—can my device be hacked? In everyday conversations, I’ve met people who believe this actually happened—they believe the Vice President’s pacemaker was hacked—and no, they don’t wear strainer helmets with aluminum foil antennas.<br />
<br />
The public concern over the security of medical devices is very real. OIG must have a role, and we can add value. We recognize that patching or enhancing the security of a medical device presents unique challenges. Changing a device could present unforeseen, and even catastrophic, consequences. Should a medical device be impenetrable? How much security is enough? Answering these questions is where risk assessments become important. We encourage manufacturers to consider the risk of each device and make informed decisions using a risk-based approach.<br />
<br />
For fiscal year 2017, OIG has decided to focus on preparation (pre-market) and response planning (post-market). We believe our evaluation (pre-market) and audit (post-market) work will assist in answering two fundamental questions: 1. How is FDA ensuring that manufacturers are building in security and assessing the device’s cybersecurity risks prior to FDA-approval or clearance? and 2. Once a cybersecurity vulnerability has been identified, what plans and processes does FDA have in place to respond efficiently and timely?<br />
<br />
<b>What are the key security issues manufacturers face both pre-market and post-market? </b><br />
<br />
Pre-market and post-market present unique challenges for FDA and manufacturers. In our pre-market work, we will examine how FDA reviews the cybersecurity of networked devices before the devices are cleared or approved. FDA has finalized the pre-market guidance; our work will focus on how FDA assesses the cybersecurity information that manufacturers include when seeking device clearance/approval.<br />
<br />
Our post-market work will focus on FDA’s internal processes (internal controls) to timely and effectively respond to a medical device compromise, specifically a cybersecurity vulnerability. Our work will not focus on the “nuts and bolts” of specific medical devices, but rather the processes and procedures FDA has in place to respond to a medical device compromise.<br />
<br />
<b>What would you say are the biggest security issues facing medical device manufacturers today? Why?</b><br />
<br />
I believe one of the largest hurdles facing any emerging issue is first recognizing that a new risk has presented itself and change is on the horizon. Those in the medical device community must begin to ensure that water-cooler talk about the risk within medical devices makes its way into the boardroom and ultimately the culture of the organization. Device manufacturers have to examine: How can we design our devices so that they’re secure, and still user-friendly, while also delivering care safely and in a timely manner?<br />
<br />
Manufacturers should first conduct a risk assessment and ask: Do we have a documented and repeatable process in place to timely and effectively respond to a medical device compromise? Specifically, a cybersecurity compromise? How would our cybersecurity response differ from our response to a more traditional event, such as a faulty battery? Importantly, are we adequately prepared to deal with a reported cybersecurity vulnerability in our medical devices?<br />
<br />
You’re participating on a panel at the<a href="https://www.medicalsecurity101.org/"> Medical Device Security 101 Conference</a> where you’ll be talking about federal policies for medical device cybersecurity with Chantal Worzala, director of policy of the <a href="http://www.aha.org/">American Hospital Association</a>, and Iliana Peters, senior advisor, <a href="https://www.hhs.gov/ocr/">HIPAA Compliance and Enforcement, HHS Office for Civil Rights</a>. What specific issues do you think you’ll be discussing or debating?<br />
<br />
I hope to discuss how our roles and responsibilities complement one another in ensuring a timely and effective response to a medical device cybersecurity compromise.<br />
<br />
<b>Are there any other sessions at the conference you’re interested in attending yourself?</b><br />
<br />
There are a number of great topics and experts. The two sessions I am most interested in are <a href="https://www.medicalsecurity101.org/schedule/">Principles for Medical Device Security-Risk Management</a>; and <a href="https://www.medicalsecurity101.org/schedule/">How to Set up a Medical Device Security Program for Manufacturers</a>. As I have mentioned in a number of responses, the first step to an effective program is appropriately assessing risk and the next step is standing up a program with strong controls, based on a solid risk assessment. I’m excited to hear what Geoffrey Pascoe and <a href="https://secure-medicine.blogspot.com/2016/11/how-to-make-medical-devices-more-secure.html">Bill Aerts</a> have to say. </div>
<div dir="ltr" style="line-height: 1.2; margin-bottom: 0pt; margin-top: 0pt;">
_________________________________<br />
<br />
Stay informed on medical device security news and events by signing up for the Archimedes monthly <a href="https://www.medicalsecurity101.org/newsletter/">newsletter</a> or by <a href="https://twitter.com/ARC_MedSec">following us on Twitter</a>.<br />
<br />
<i>Email archimedes@umich.edu to learn how to become a supporting member of the Archimedes Center for Medical Device Security.</i></div>
Sarah.penahttp://www.blogger.com/profile/03475889181807340528noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-49333028727091740492016-11-22T09:56:00.001-08:002016-11-22T09:59:00.780-08:00How to Make Medical Devices More Secure<h3>
Q&A with Medtronic’s Retired Director of Product Security Bill Aerts</h3>
By <a href="mailto:scribwell@gmail.com">Nikki McDonald</a><br />
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhb3RXebB7z56scWld8jTX-9JMxxeIEUSBzfpU0n07Wd5INIAjvOfsP0pFgtvVhHLb8zyy48srG41-rqcrtkufM7mIW94NZD97Efi7XAZNhTPFtIrkoqyW0q9EM3IWaM3WvmU2aAmTLyFB-/s1600/Bill_Medtronic_Outside.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhb3RXebB7z56scWld8jTX-9JMxxeIEUSBzfpU0n07Wd5INIAjvOfsP0pFgtvVhHLb8zyy48srG41-rqcrtkufM7mIW94NZD97Efi7XAZNhTPFtIrkoqyW0q9EM3IWaM3WvmU2aAmTLyFB-/s400/Bill_Medtronic_Outside.jpg" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
Former Medtronic Director of Product Security Bill Aerts took some time recently to discuss the new security challenges arising from the IoT of medical devices, how to put together a strong security program, and the current state of medical device security (and how we can fix it). </div>
<div>
<br />
Aerts will be hosting a training session on How to Set up a Medical Device Security Program for Manufacturers at the Archimedes <a href="https://www.medicalsecurity101.org/">Medical Device Security 101 Conference</a> this January. </div>
<div>
<br />
<b>Describe your experience in the medical device security field and how it’s led to the work you’re doing now.</b><br />
<br />
I’ve had the opportunity to start and develop IT security programs at a number of large companies over my career, including the program at Medtronic. As time moved on, it was clear that the products and services that Medtronic sells had some of the same IT security challenges, as well as many unique challenges and situations.<br />
<br />
As my wife has benefitted from many heart devices, I’ve always been very interested in making sure that products are secure, so I jumped at the opportunity to build a medical device security program at Medtronic. It has been a great experience and the program is really having an impact.<br />
<br />
More recently, I realized that 30+ years working in large corporations was enough, and that I wanted to try something new, so I retired from Medtronic. Now, I’m excited about any kind of work I can do in this field to help all of the players in the medical device security industry create better and more secure products. There is so much opportunity and challenge ahead.<br />
<br />
<b>As more medical devices have become wirelessly connected, what new security challenges have arisen?</b><br />
<br />
The list is long: asset management is difficult because of the wide variety of vendors and unique devices connected to a hospital network...protecting the storage and use of personal information as it is sent anywhere in the world...lack of physical control over the device.<br />
<br />
Secure communications, including authentication and encryption, is also a real challenge. Being connected to the Internet is an even higher risk for medical devices than for a typical laptop or mobile device. It will be difficult to secure IOT devices as they multiply.<br />
<b><br />How serious is the risk to patients?</b><br />
Real security risk does exist in connected medical devices, especially in older ones. Any security risk needs to be taken very seriously to protect patient safety, but the key question to me is always, “Does the therapy that the device provides outweigh the risk of a security problem?”<br />
<br />
In the majority of current cases, the risk is relatively low, and the benefit is very high. That said, there are too many devices out there that have poor security and they need to be addressed as quickly as possible. The risk to patients is growing quickly as more connected devices are used, and the IOT becomes full of medical related “things.”<br />
<br />
<b>What can medical device manufacturers do to create more secure products?</b><br />
<br />
They need to build a program around device security and have strong commitment from the top, as well as assignment of accountability. This may require that they find or buy more expertise on security, specifically in medical devices.<br />
<br />
Manufacturers need to leverage new security technologies and build security into the development of new products from the beginning. As part of this process, they must engage heavily with their healthcare customers to really understand what needs to be improved with their products, and then support the security functions in their products when they’re in the field.<br />
<br />
<b>What are the key components of a strong security program for device manufacturers?</b><br />
<br />
A successful security program should have strong leadership and governance, security built into the entire product lifecycle, training and education on security for those people developing products, independent assessment and security testing in products, a repeatable coordinated response capability, and heavy engagement with the communities outside of the company, including patients, providers, researchers, regulatory agencies, industry groups, and the press.<br />
<b><br />What are some of the common struggles manufacturers have in implementing a security program?</b><br />
<br />
One of the biggest issues many face is simply getting the support and funding they need from leaders to build a new capability and hiring the right people to do it. Manufacturers have to educate engineers about the real threats that exist for these products and secure their understanding and support as well. To get a security program in place, it’s essential to bring together IT people with R&D engineering people and help them understand that they need each other to take on this challenge.<br />
<br />
It can also be difficult to find the right expertise from inside or outside the company and to get Legal and Regulatory onboard without being too cautious and slowing things down.<br />
<br />
<b>What can manufacturers do to overcome these issues?</b><br />
<br />
Gaining support from executive leadership, including the BOD, is essential. Sell it to them based on patient safety, regulatory requirements, and requirements coming from the healthcare customers that are buying the products. Provide training/education on the risks and remedies done by outside expert groups. Invite Legal and Regulatory into the discussion early, and expose them to what the industry and other competitors are doing. Put deliberate effort into bringing the IT experts together with the engineering experts in order for them to learn each other’s language and build productive relationships. If needed, have security assessments done on core legacy products to be sure there is good understanding of the risks.<br />
<br />
<b>St. Jude Medical was in the news recently when a report indicated that their pacemakers could be hacked and Johnson & Johnson recently released a warning that their insulin pumps could be vulnerable to hackers. How widespread is this problem? What is the state of medical device security today?</b><br />
<br />
We know there are large numbers of devices out there right now that are not secure. There will be more events like these recent examples in the future, and they could involve any manufacturer or connected device. Many of the devices in use today were designed years ago when the only requirement was patient safety.<br />
<br />
A lot has been accomplished in the last three to four years by manufacturers, healthcare providers, and regulators, as well as security researchers working with the community to help improve security. I hope we’ll see the benefit of that collaboration in the next few years as newer, more secure devices are rolled out. In the meantime, we need to put mitigations in place, and continue to measure security risk against therapy benefit.<br />
<br />
<b>You’re teaching at the Medical Device Security 101 Conference this January. Who do you think should attend and what are the most important things they’ll learn?</b><br />
<br />
My session will be on building a strong medical device security program. I believe that anyone who has or desires responsibility to ensure their medical devices are safe and secure would have great interest in this, regardless of how big or small their company is, or how new or mature their program is.<br />
<br />
They will learn about the importance of taking a programmatic approach, getting executive support and creating governance, integrating security into the product development process, engaging the right people, coordinated response, and the importance of being connected within the industry, among other topics.<br />
<br />
__________________________________________________________________________<br />
<br />
<i>The <a href="https://www.medicalsecurity101.org/">Medical Device Security 101 Conference</a> takes place January 15-17, 2017 at Disney’s Yacht & Beach Club Resorts in Lake Buena Vista, Florida. <a href="https://www.eventbrite.com/e/medical-device-security-101-conference-tickets-27465381696">Register today</a> to get access to over 20 expert speakers at this highly selective event attended by medical device manufacturers and healthcare delivery organizations.</i><br />
<div>
<i><br /></i></div>
<div>
<i><b>Email <a href="mailto:archimedes@umich.edu">archimedes@umich.edu</a> to learn about individual discounts or group rates. </b></i></div>
</div>
</div>
Sarah.penahttp://www.blogger.com/profile/03475889181807340528noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-455822705332844602016-11-22T09:06:00.000-08:002016-11-22T09:06:04.064-08:00 Professor to Congress: 'Internet of Things security is woefully inadequate'<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhx3YMGLh6L9lKYc_NlXdC8wWsw58AtY3ZexXGuPv60pxOgzhPXNq21fG8aGrDes0iXHyL4S2R2PcheiAwuFK7Ec2sSStSJI5i8-_t8XBmPv609ORRitI9YlD8RH5iZp0OVTIR70VgNQW9G/s1600/fu.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhx3YMGLh6L9lKYc_NlXdC8wWsw58AtY3ZexXGuPv60pxOgzhPXNq21fG8aGrDes0iXHyL4S2R2PcheiAwuFK7Ec2sSStSJI5i8-_t8XBmPv609ORRitI9YlD8RH5iZp0OVTIR70VgNQW9G/s200/fu.jpg" width="200" /></a><br />
From: <a href="mailto:ncmoore@umich.edu">Nicole Casal Moore</a><br /><a href="http://www.engin.umich.edu/">Michigan Engineering</a><br /><br />As the Internet of Things grows around us, so do the threat of cybersecurity breaches severe enough to shut down hospitals and other vital infrastructure, a Michigan Engineering professor <a href="https://energycommerce.house.gov/news-center/press-releases/subcommtech-and-subcmt-examine-recent-cyber-attacks">told federal lawmakers this week</a>.<br /><br />Kevin Fu, associate professor of computer science and engineering, and director of the Archimedes Center for Medical Device Security, was one of several experts who called for federal security regulation of the Internet of Things (IoT). He spoke to the House Energy and Commerce Committee at the Nov. 16 hearing, “Understanding the Role of Connected Devices in Recent Cyber Attacks.”<br /><br />On Oct. 21, many high-traffic sites including Paypal, Twitter, Amazon and Netflix went down for several hours due to an IoT-powered attack on web service provider Dyn. Hackers carried out the attack by taking advantage of vulnerabilities in connected consumer devices like webcams and digital video recorders—perhaps millions of them.<br /><br />While the consequences of the Dyn breach were not major, Fu warned that it demonstrates a gaping security hole as more and more consumer technologies—appliances, thermostats, cars, airplanes, and medical devices—become connected.<br /><br />"I fear for the day every hospital system is down," <a href="http://money.cnn.com/2016/11/16/technology/cybersecurity-regulation-congress/index.html?iid=hp-toplead-dom">CNN quoted him as saying</a>. “This will require some kind of governmental mandate."<br /><br />Companies don’t have enough incentive to do it on their own, he argued.<br /><br />"We are in this sorry and deteriorating state because there's almost no cost for a manufacturer to deploy products with poor cybersecurity,” <a href="http://www.cio.com/article/3142351/security/us-lawmakers-balk-at-call-for-iot-security-regulations.html">CIO quotes him as saying</a>.<br /><br />He called on a variety of sectors to help put safeguards in place.<br /><br />“Universities, industry and government must find the strength and resolve to invest in embedded cybersecurity with interdisciplinary science and engineering, industrial partnerships for research and education, and service to the nation," he said.<br /><br />Read Fu’s full testimony or watch a video of the hearing at the E&C committee websites of the <a href="https://energycommerce.house.gov/hearings-and-votes/hearings/understanding-role-connected-devices-recent-cyber-attacks">Republican majority</a> or the <a href="https://democrats-energycommerce.house.gov/committee-activity/hearings/hearing-on-understanding-the-role-of-connected-devices-in-recent-cyber">Democrat minority</a>.<br /><br /><i>U-M’s Archimedes Center for Medical Device Security offers a <a href="https://www.medicalsecurity101.org/">Medical Security 101 training</a> for healthcare organizations, device manufacturers, and regulators in Orlando Jan. 15-17, 2017. The center is a multidisciplinary team of medical and computer science experts who focus on research, education and on advising industry leaders on methods for improving medical device security.<br />__________________________________________________________________________<br /><br />Ensuring the security of our society is a top priority for the U-M College of Engineering's transformational campaign currently underway. <a href="http://www.engin.umich.edu/college/giving/victors">Find out more about supporting the security of our future in the Victors for Michigan campaign.</a></i>Sarah.penahttp://www.blogger.com/profile/03475889181807340528noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-82827390913081670972016-09-15T09:48:00.001-07:002016-09-15T09:48:04.370-07:00Commentary: Hospitals need better cybersecurity, not more fearBy Kevin Fu, Dr. John Halamka, Jack Kufahl and Mary Logan | September 14, 2016<div>
<br />We've seen unprecedented attention to medical-device security after an <a href="http://www.nytimes.com/2016/09/09/business/dealbook/hedge-fund-and-cybersecurity-firm-team-up-to-short-sell-device-maker.html" target="_blank">unorthodox report</a> was recently released by short-selling investment research firm Muddy Waters Capital and MedSec, which alleged security vulnerabilities in <a href="http://www.modernhealthcare.com/section/articles?tagID=4996" target="_blank">St. Jude Medical's</a> pacemakers. An <a href="https://secure-medicine.blogspot.com/2016/08/correlation-is-not-causation-electrical.html" target="_blank">independent research team</a> subsequently raised doubts about some of the clinical claims made by the report. St. Jude Medical, meanwhile, has filed a lawsuit disputing the allegations in the same report. <br /><br />Cybersecurity risks associated with medical devices must be weighed against the often life-saving benefits of these devices. Hospitals struggle in assessing those risks: They may not know which medical-device assets are exposed to cybersecurity threats or get meaningful responses from vendors, and there is no national testing facility for medical-device security. There are different schools of thought on how to safely and effectively share information regarding medical-device security vulnerabilities. However, we should agree that vulnerability reporting should not be done in a manner that causes people to make decisions based on fear, rather than on clinically relevant data. <br /><br /><br />Read the <a href="http://www.modernhealthcare.com/article/20160914/NEWS/160919950/commentary-hospitals-need-better-cybersecurity-not-more-fear"><b>complete article</b></a>, which originally posted on <a href="http://www.modernhealthcare.com/" target="_blank"><b>Modern Healthcare</b></a>.</div>
Pena Familyhttp://www.blogger.com/profile/15029890814268092559noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-21232271739166477762016-08-30T14:39:00.003-07:002016-08-31T18:03:22.225-07:00Correlation is Not Causation: Electrical Analysis of St. Jude Implant Shows Normal Pacing<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span></div>
<h3 style="clear: both; text-align: center;">
St. Jude Merlin Error Indicators Are Not Evidence of Malfunction</h3>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjY_CJ6efeQJbchJkPVMubReHXWSPO0jXrOJ6aKN6NDFyNszhmIUGql1DqGACM5B8t_1DBs0bRUyXahwcaaN7sfc5k2gvfbTzSVsqP03sOSin-vS5Onlq5bobcHL1viwp2oax9m3XrNpRCL/s1600/muddy-jude.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="162" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjY_CJ6efeQJbchJkPVMubReHXWSPO0jXrOJ6aKN6NDFyNszhmIUGql1DqGACM5B8t_1DBs0bRUyXahwcaaN7sfc5k2gvfbTzSVsqP03sOSin-vS5Onlq5bobcHL1viwp2oax9m3XrNpRCL/s320/muddy-jude.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Battle of the bands: Here's what we <a href="https://www.youtube.com/watch?v=A_MjCqQoLLA" target="_blank">listened</a> to while <br />
writing this summary.</td></tr>
</tbody></table>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Here's an abbreviated technical analysis of some claims by Muddy Waters and St. Jude regarding pacemaker/defibrillator security. We will show you why correlation is not causation in the sense that a scary-looking screen is not a reliable indicator of a clinically relevant security problem. We did this analysis based on our experience over the last ten years <a href="http://www.secure-medicine.org/public/publications/icd-study.pdf" target="_blank">analyzing pacemaker and defibrillator security</a> and our experience building cardiac arrhythmia simulators for humanitarian <a href="http://www.med.umich.edu/myheartyourheart/" target="_blank">pacemaker reuse</a>. Read more at our <a href="https://spqr.eecs.umich.edu/publications.php?q=health" target="_blank">ancient research website</a>. </span><span style="font-family: "arial"; font-size: 14.6667px; line-height: 20.24px; white-space: pre-wrap;">Or see our </span><a href="http://blog.secure-medicine.org/p/index.html" style="font-family: Arial; font-size: 14.6667px; line-height: 20.24px; white-space: pre-wrap;" target="_blank">index of previous blog posts on medical device security</a><span style="font-family: "arial"; font-size: 14.6667px; line-height: 20.24px; white-space: pre-wrap;">. </span><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;">This is a fun extracurricular activity for our team at the </span><a href="http://ns.umich.edu/new/releases/24153-holes-found-in-report-on-st-jude-medical-device-security" style="font-family: Arial; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;" target="_blank">University of Michigan</a><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;"> and </span><a href="https://virtalabs.com/" style="font-family: Arial; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;" target="_blank">Virta Labs</a><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;">, and we may post more thoughts before we return to our regular lives baking hearth breads and helping hospitals with cybersecurity risks. </span><br />
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;"><br /></span>
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 20.24px; white-space: pre-wrap;">The Muddy Waters report of August 25 showed a screenshot which they say shows an “apparent malfunction.” They also say that red error marks “are also indicators that the device is malfunctioning.” We were curious about these claims and decided to see if we could produce the same onscreen displays without causing any malfunction. This summary shows the screenshot is correlated with normal pacing and sensing, suggesting that the Muddy Waters report misinterprets clinical relevance of the screenshot.</span><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;">
</span><br />
<div>
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;"><br /></span></div>
</div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGZ8FYKfZd_7TcN5T7fRSd0BfUUsDcJs25yYnXlAJZldut-RVFGx1qDm-W-4WHYxJJ1zSAHDZjuXsOLSg_eP3bQ4WBezdjJyXPhxjtoY1cj3b6-vc4KgFwScsKmIMSKP9n3OxWmSBOSUH/s1600/IMG_20160829_081303.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGZ8FYKfZd_7TcN5T7fRSd0BfUUsDcJs25yYnXlAJZldut-RVFGx1qDm-W-4WHYxJJ1zSAHDZjuXsOLSg_eP3bQ4WBezdjJyXPhxjtoY1cj3b6-vc4KgFwScsKmIMSKP9n3OxWmSBOSUH/s320/IMG_20160829_081303.jpg" width="320" /></a></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-pqWZfvK5K-pU1-ybuzUHnRX0srKk3dX7PxdgNB2-9cArGLGZ0Fqv37LCoP6ROkUQFybSn53PdTKLSoSkq7FwxVeot4XT9MWP1aiVUDJ2V7CxFA1_eM80Yya4vNmoUjPqgzY3xTiiyYww/s1600/IMG_20160830_105318.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-pqWZfvK5K-pU1-ybuzUHnRX0srKk3dX7PxdgNB2-9cArGLGZ0Fqv37LCoP6ROkUQFybSn53PdTKLSoSkq7FwxVeot4XT9MWP1aiVUDJ2V7CxFA1_eM80Yya4vNmoUjPqgzY3xTiiyYww/s320/IMG_20160830_105318.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption"><span style="font-size: 12.8px;">Figure 1: Our experiment shows that a Merlin programmer screenshot from p. 17 of the Muddy Waters report is not supportive evidence of a successful attack. The top photo shows our reproduction of the Merlin programmer screen photo, but without causing changes to the pacing pulses. Our end-to-end oscilloscope measurements (bottom photo) show that pacing pulses continue normally despite the three benign alerts that are expected when not connected to cardiac tissue. </span></td></tr>
</tbody></table>
<div dir="ltr" style="font-weight: 700; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span></div>
<span style="font-weight: 700;">Hypothesis:</span><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 400; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span>The Merlin programmer screen photo on page 17 of the Muddy Waters report is not supportive evidence of appearing “to have caused the device to pace at a rapid rate.”<br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.666666666666666px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Approach:</span><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 400; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span>Produce the same on-screen screen output, and externally measure electrical signals to test safety and effectiveness of pacing and sensing.</div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.666666666666666px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Result:</span><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 400; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span>We reliably produced the same screen output while the implant continued to pace normally.</div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.666666666666666px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Material: </span>St. Jude Medical Fortify Assura ICD, Merlin programmer (software version 22.0.1 rev1)<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 400; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br class="kix-line-break" /></span><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 700; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Clinical validation:</span><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.6667px; font-style: normal; font-weight: 400; line-height: 1.38; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"> </span>Verified by Dr. Thomas Crawford, a cardiologist and a clinical electrophysiologist at the University of Michigan Health System's Frankel Cardiovascular Center.</div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.666666666666666px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: transparent; color: black; font-family: "arial"; font-size: 14.666666666666666px; font-style: normal; font-variant: normal; font-weight: 700; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;">Commentary:</span></div>
To verify pacing, we configured the device to emit 40 bpm pacing pulses at 2.5 V, then connected a clipped lead (~20 cm) to the V (IS-1 Bi) sense/pace port, connected an oscilloscope to the clipped lead with 50 Ω probes, and visually confirmed that the device was emitting 40 pulses per minute (Figure 1 bottom). To verify sensing, we used a signal generator to produce a 0.5 Hz square wave (consisting of 2 events, a rising then a falling edge, for a total of 1 event per second or 60 pbm) at 2 mV which we fed into the sense/pace port via the same lead; the programmer recognized a 60 bpm beat as expected. We tested other square-wave frequencies between 0.5 Hz and 2 Hz to verify that the sensing worked as expected.<br />
<br />
To reproduce the markers that the Muddy Waters report highlights as indicators of a successful attack, we introduced benign electrical noise on the sense/pace port via the clipped lead by connecting the lead to a separately grounded oscilloscope (i.e., not grounded to the “can” of the device, which typically acts as ground). This noise was sufficient to trigger the “VS2” markers on the programmer screen, indicating that the device sensed a “ventricular beat.” While sampling the 40 bpm pacing output as described above, we reproduced the count of three alerts visible in the Muddy Waters report’s screen photo: two alerts from high impedance on two leads (since those were not connected to cardiac tissue), and one indicating “ventricular noise reversion.” The pacing and sensing continued to function normally. ■<br />
<br />
<div>
The team from the University of Michigan and Virta Labs is continuing to investigate the contrasting claims by Muddy Waters and St. Jude Medical. To receive notifications of updates, follow the Archimedes Center for Medical Device security <a href="https://twitter.com/ARC_MedSec" target="_blank">@ARC_MedSec</a> and <a href="https://twitter.com/DrKevinFu" target="_blank">@DrKevinFu</a> on Twitter. Virta Labs also plans to issue a separate white paper.</div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-15101355989844324532016-08-30T12:46:00.001-07:002016-08-30T13:22:46.980-07:00Study on St. Jude medical device security deemed “inconclusive” by University of Michigan researchersA recent report that alleged security flaws in St. Jude Medical’s pacemakers and other life-saving medical devices has major flaws of its own. That’s according to a team of University of Michigan researchers who say they’ve reproduced the experiments that led to the allegations, and come to strikingly different conclusions.<br />
<br />
The U-M team is composed of several leading medical device security researchers and a cardiologist from the U-M Health System's Frankel Cardiovascular Center. “Hyperbolic” and “sloppy” are words they use to describe the unorthodox report, which was released last week by short-selling investment research firm Muddy Waters Capital and medical device security firm MedSec, Ltd. <br />
<br />
The U-M team reproduced the error messages the report cites as evidence of a successful “crash attack” into a home-monitored implantable cardiac defibrillator. But they showed that the messages are actually the same set of errors you’d get if you didn’t have the device properly plugged in. <b style="font-weight: normal;"><br /></b>
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/ljDjyzh2C70/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/ljDjyzh2C70?feature=player_embedded" width="320"></iframe></div>
<div dir="ltr" style="line-height: 1.44; margin-bottom: 0pt; margin-top: 0pt;">
<br /></div>
When it’s implanted, a defibrillator’s electrodes are connected to heart tissue via wires that are woven through blood vessels, explains Kevin Fu, associate professor of computer science and engineering at U-M and director of the Archimedes Center for Medical Device Security. Fu is also co-founder of medical device security startup Virta Labs.<br />
<br />
Through these wires, implantable defibrillators can perform sensing operations and also send shocks if necessary.<br />
<br />
“When these wires are disconnected, the device generates a series of error messages: two indicate high impedance, and a third indicates that the pacemaker is interfering with itself,” said Denis Foo Kune, former U-M postdoctoral researcher and co-founder of Virta Labs. <br />
<br />
On page 17 of the Muddy Waters report, a screenshot cites these very error messages as proof of a security breach.<br />
<br />
“But really the pacemaker is acting correctly,” Fu said. “To the armchair engineer it may look startling, but to a clinician it just means you didn’t plug it in. In layman’s terms, it’s like claiming that hackers took over your computer, but then later discovering that you simply forgot to plug in your keyboard.”<br />
<br />
Added Foo Kune, “While there still could be security problems, the screenshot is anything but supportive of the claim. When researchers with limited medical training go public with unvetted claims, it’s easy to jump to conclusions.”<br />
<br />
Ethicists and other researchers have criticized MedSec’s technique of teaming with a short-seller to publicize its preliminary findings—and benefit financially, no less. <br />
<br />
Short-selling is an investment practice that essentially involves betting that a particular stock will decline in value. If it does, then the investment firm profits. In this case, MedSec made a deal with Muddy Waters to receive a share of those profits. St. Jude’s stock fell sharply over the weekend.<br />
<br />
<div>
“It was the irresponsible thing to do. Think about whether you believe everything a used car dealer claims when deciding whether to buy,” said Wenyuan Xu, a visiting professor of electrical engineering and computer science at U-M and an expert in automotive and medical device security. She recently hacked into Tesla’s autopilot system to demonstrate its vulnerabilities. <br />
<br /></div>
<div>
To conduct the experiments, the U-M team used a new and properly functioning model of the same defibrillator that the Muddy Waters study used—the Fortify Assura VR. In several additional instances, they found that the device operated properly.<br />
<br /></div>
<div>
Even while the U-M research team finds fault with the Muddy Waters report, they don’t mean to suggest that these medical devices—or any medical devices for that matter—are necessarily secure. They stress the importance of establishing security workflows early on in the design process of medical devices.<br />
<br /></div>
<div>
“While medical device manufacturers must improve the security of their products, claiming the sky is falling is counterproductive,” Fu said. “Healthcare cybersecurity is about safety and risk management and patients who are prescribed a medical device are far safer with the device than without it.”<br />
<br />
Thomas Crawford, an assistant professor of medicine and a clinical electrophysiologist at U-M, agrees. Crawford implants and follows patients with pacemakers and implantable defibrillators.<br />
<br /></div>
<div>
“Given the significant benefits from home monitoring, patients should continue to engage in it via St. Jude Medical Merlin, and other companies’ respective proprietary home monitoring systems, before independent research can substantiate the claims made by MedSec and their financial partner Muddy Waters Capital, LLC,” Crawford said.<br />
<br />
Crawford adds that home monitoring has been shown to reduce a variety of adverse events, with some studies even showing reduction in overall mortality over periodic checks of devices in the doctor’s office. The devices can send actionable alerts to a central monitoring service, which then is forwarded to the physician, so that it can be dealt with immediately if necessary. Alerts include low battery status, potential malfunction of the device, or changes in heart rhythm, which may require treatment.<br />
<br />
The Archimedes Center for Medical Device Security offers a Medical Security 101 training in Orlando Jan. 15-17, 2017. Details will be forthcoming online. In the meantime, for more information, email archimedes@umich.edu. </div>
Pena Familyhttp://www.blogger.com/profile/15029890814268092559noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-38693669711689467832016-05-02T18:31:00.001-07:002016-07-15T14:34:27.870-07:00Archimedes Circular Podcast 0x01: Co-Chairs of the AAMI Medical Device Security Working Group<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFyUSZlylj__pGORCJ3bP4kgBzM185ymhpGHjIj3I7G6wY1wGM-v94-IvLBQoLkl9JGkOU3JsBQ4M0lZBl3G08sp5zRhXqXB_S7jGoHQYeCFMjLocq_dnZNAzVjCVGgz4jOkZTWXFxea84/s1600/Screen+Shot+2015-10-08+at+12.04.35+AM.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFyUSZlylj__pGORCJ3bP4kgBzM185ymhpGHjIj3I7G6wY1wGM-v94-IvLBQoLkl9JGkOU3JsBQ4M0lZBl3G08sp5zRhXqXB_S7jGoHQYeCFMjLocq_dnZNAzVjCVGgz4jOkZTWXFxea84/s320/Screen+Shot+2015-10-08+at+12.04.35+AM.png" width="316" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Not an official logo of the AAMI Medical Device Security Working<br />
Group, but it may become a T-shirt after members catch up.</td></tr>
</tbody></table>
Welcome to the inaugural Archimedes Circular Podcast. Today, Dr. Kevin Fu interviews the co-chairs of the <a href="http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2014-06/ispab_jun2014_medical-devices_hoyme.pdf" target="_blank">AAMI Working Group on Medical Device Security</a> ahead of the release of its Technical Information Report 57 to medical device manufacturers on specific security engineering methods designed to help satisfy regulatory expectations of cybersecurity in the 510(k) and PMA processes.<br />
<br />
Ken Hoyme and Geoffrey Pascoe are co-chairs of the AAMI Medical Device Security Working group. <a href="http://www.aami.org/" target="_blank">AAMI is the Association for the Advancement of Medical Instrumentation</a>. Founded in 1967, AAMI is a non-profit organization of 7,000 professionals for the development, management, and use of safe and effective healthcare technology. AAMI consists of over 100 technical committees and working groups that produce Standards, Recommended Practices, and Technical Information Reports for medical devices. The medical device security co-chairs are interviewed by Kevin Fu, a professor at the University of Michigan and the Archimedes Center for Medical Device Security.<br />
<br />
For several years, the AAMI Medical Device Security Working group has been toiling away tirelessly on the Technical Information Report #57 (<a href="https://standards.aami.org/kws/public/projects/project/details?project_id=876">Principles for medical device information security risk management</a>). Its members fondly call it TIR 57. The document provides advice to front-line medical device engineers on how to begin integrating security engineering into the design and implementation of medical devices. The TIR 57 is based on the input and consensus vote of medical device manufacturers, health delivery organizations, security engineering experts, and faculty.<br />
<br />
<iframe frameborder="no" height="166" scrolling="no" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/260592389%3Fsecret_token%3Ds-rWPpA&color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false" width="100%"></iframe>
<br />
<br />
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><br /></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Welcome to the Inaugural Archimedes Broadcast. My name is Kevin Fu. I direct the Archimedes Center for Medical Device Security. Today, we’re going to talk about consensus standards and guidance documents for manufacturers to meet FDA expectations on medical device security. Today, I am interviewing Ken Hoyme and Geoff Pascoe, the co-chairs of the Medical Device Security Working Group of AAMI, which is considered the most respected standards body in the medical devices arena. I am also joined by Wil Vargas who is the director of standards at AAMI, so welcome, Ken, Geoff and Wil.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Wil:<span style="mso-tab-count: 1;"> </span>Thank you.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Thank you. Thank you for having us.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Thanks.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"></span><br />
<a name='more'></a><span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Let me begin with just a little background here because not everybody is familiar with AAMI. AAMI is the Association for the Advancement of Medical Instrumentation. When talking with my information security colleagues I often liken AAMI to the IETF of the medical device manufacturing world. AAMI is this nonprofit organization that supports the healthcare community, has over 7000 professional members represented and they’re really the primary source of consensus standards for the medical device industry.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>Before we get into what AAMI is doing in the medical device space, I was hoping Wil, maybe you could just tell us a little bit about AAMI and in a jargon-free world to introduce some of our technical folks who may not be familiar with medical devices what exactly AAMI does.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Wil:<span style="mso-tab-count: 1;"> </span>Sure. AAMI stands for the Association for the Advancement of Medical Instrumentation. They have been around for almost I think 50 years now. Its focus has been on issues relating to patient safety with medical devices. The efforts really started around creating voluntary standards and guidance documents to help address and facilitate those issues to improve patient safety for medical devices across a wide spectrum of device safety issues from sterilization all the way through elements of software and security.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>AAMI’s products and services have developed and grown over time really with that core focus in mind. We have conferences and courses and events, all related to communicating the issues related to patient safety. The standards program is really where the rubber hits the road bringing the experts together, from industry manufacturers and even the end users which are the doctors as well as the biomeds, the biotech, and getting them around the table to address and create those voluntary standards. That’s part of the core of what AAMI does even 50 years later.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>My understanding is that AAMI is this independent body that is not an advocacy group but is more a builder of consensus. Maybe you could help us understand how that affects or what makes AAMI special.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Wil:<span style="mso-tab-count: 1;"> </span>You’re right. AAMI doesn’t really get involved and doesn’t really play a role in advocacy or lobbying. It’s a nonprofit organization that relies on the consensus process which is basically where you get folks to agree enough on a topic that we can move on, not that everyone completely 100% solidly is behind or believes 100% that they would do it that way if it were up to them. Consensus is one of those weird squishy things but it works and it works really well in order to create these voluntary standards, but it also takes on or takes in a lot of feedback within the consensus building process.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>It’s not a one and done type of operation when you’re developing a standard. It’s a very iterative sequential process where the issues and elements are discussed at great length over a very long period of time, at least a minimum of a year, it can be as long as five years in order to achieve that level of consensus required to achieve and get the document approved.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>This is Geoff, I think one of the really useful things about this consensus process is that especially in the medical device industry where we’re heavily regulated it really provides a mechanism for the FDA to collaborate with industry in an open structure that doesn’t favor any particular manufacturer. They have to be very careful about how they communicate their intent to manufacturers. The AAMI rules at being a standards organization really creates a forum where it’s not just the product but the product actually creates these mechanisms for communication in such a way that it actually meets both the needs of the regulators as well as also the needs of the manufactures, and also, in some case the providers.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>This is a good segue to Geoff and Ken on your specific duties on the AMMI Working Group on medical device security. Everybody who is listening to this is aware that medical device security is a problem and one of the problems is where do you point a manufacturer to improve the medical device security posture? Ken or Geoff, I am hoping you can give me just a brief introduction to what is the AAMI working group on medical device security. What is it doing?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Sure. This is Ken. We were formed about three years ago I think really in response to when the general accounting office (GAO) issued their report encouraging the FDA to improve their pre-market expectations of cyber security and medical devices and their post market surveillance. Again, as Geoff mentioned there is this collaboration between AAMI and the FDA. I think AAMI saw the opportunity there to help drive some consensus standards and discussions between industry and regulator to help evolve the thinking on that and provide some clear guidance on industry to meet the expectations of the FDA.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>The committee was formed in the typical AAMI process where all the various member organizations are informed of new committees that are emerging and other kinds of communication vehicles. I think our first meeting was in May of 2013. I think we had about 40 people at that first meeting and have cut across FDA participated medical device manufacturers, security researchers, hospitals, the veteran’s administration had cyber security involved in it. There is clearly a lot of interest and energy working on improving cyber security in these devices.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Right, so you have a pretty broad group contributing then. These guidance documents take quite a while to produce because the thing about democracy and consensus building is it takes time. I understand that AAMI is still in the middle of this, but what should we be expecting down the road? To a medical device manufacturer who is looking at the FDA pre-market guidance and the draft post market guidance on cyber security, what elements of this guidance document is going to be most valued or what do you think they are going to be looking for?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Kevin, when you say ‘guidance document’ you’re referring to AAMI in this particular case, because we refer to these things that are nonstandard as technical reports.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>My apologies. I am not speaking the lingo. Yes, the TIR. Tell us a little bit about the TIR 57 and how it relates to manufacturer needs to meet FDA expectations with both the pre-market and the post market guidance. Basically, what can they expect?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>The first technical report that the committee decided to tackle we evaluated probably a dozen different directions that we could go, looked at what that other organizations were already producing out there. Our initial choice was to try to address. What ended up shortly after we focused on this, directly tied to the original guidance for pre-market notification, pre-market analysis. What we decided as a committee is since medical device manufacturers are very familiar with safety risk management as part of their quality systems and there is an international standards, standard 14971 that address the risk management process associated with patient harm and patient hazards. Most of our organizations understand the need to do this and have systems in place to assist in that.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>What we decided to do was to essentially frame security risk management in the context of the procedures that are defined in that 14971 document and essentially teach device manufacturers that might not have a security background how to reason about security risk management during the development of their process. That ended being up very closely aligned to how the original guidance for the pre-market information addresses manufactures to basically look at acceptability of risk and mitigate those risks that are unacceptable.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Right. I was going to say I think one of the things about this familiarity with the medical device manufacturer familiarity with safety risk management, it’s a double edged sword. They understand the concept of risk management but I think they don’t really fully appreciate the significant differences between security risk management, safety risk management. The fact that there are similarities, there are linkages that need to occur but as a result there are significant differences.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>We wouldn’t want to see manufacturers saying well we do safety risk management according to 14971 and we put some security stuff in there and we’re set. I think one of the things about this that is a strength of this technical report is that it makes clear what those similarities are, what those differences are and how the two interact.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>For the folks who are less familiar with AAMI and even FDA guidance documents, could you try to tease out for me what is the difference between an AAMI Technical Information report (TIR) and an FDA guidance document or even a company whitepaper? How is this going to be different?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>I think a guidance document by the FDA is recommended approaches that manufacturers should consider. They aren’t bound to it as opposed to a standard or something that’s recognized as a shell document. The FDA has flexibility in how they understand and interpret it, but it is reasonably understood by device manufacturers that when the FDA produces a guidance document that that creates an expectation for what they should do and if they ask for device approval without following the information or anything with respect to those documents, that they would expect to have a slow process with lots of questions back from the FDA during the approval.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Yeah. I think that’s the key, is that technically guidance from the FDA is not enforceable. On the other hand, if you don’t follow the guidance, you create additional barriers either during approval process for regulatory submissions or even in the case of an FDA inspection. Now FDA inspectors are familiar with the guides, so if you show documentation that supports an approach that is commensurate with the guidance, they know how to follow that. If you do it in a completely different way, then it leads to additional questions and makes inspections and regulatory submissions a lot more complicated. I think as a practical matter, most manufactures try to follow the guidance whenever they can.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Right, and to the effect that I am beginning to see whitepapers being circulated about recommended ways to improve medical device security, where do you think AAMI is going to distinguish itself with its TIR compared to what we’re seeing coming out of individual companies and other sources of information for general advice?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>I think one of the strengths of AAMI is number one their intimate familiarity with medical device fields and particularly an emphasis on safety. I think that that is one of the things that distinguishes medical device security and some other types of security, some that are similar to this, perhaps in the transportation field would be one example or even ITS systems. It’s really safety and it’s the linkages between safety and security that I think really is a place where AAMI can make significant contributions as opposed to the traditional protection of confidentiality of information.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>I agree with Geoff. That’s a key distinction. Nature abhors a vacuum. As soon as a lot of press was hit with regard to medical device security, there are a lot of organization that wanted to pile in and help. I think many of those organizations because they don’t have that intimate connection with the safety and effectiveness that regulators expect for medical devices will come at it more from a confidentiality encryption point of view. Everyone is very familiar with the various financial penalties that hospitals and health systems and insurance companies have been hit because of breech of information but medical devices are cyber-physical systems. They touch patients. They measure things off of people. They are delivering therapy to people.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>In that regard, the issues of integrity and availability can sometimes take precedence over confidentiality concerns particularly if you are dealing with devices that are deployed in an emergency room or in a surgery theater. Having that understanding of being able to balance and trade off the safety aspects of things and security aspects of things is I think a unique position that AAMI has because of that connection to the regulators and the health delivery organizations.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Sometimes you’ll actually see or hear people talk about the inverting of the CIA triangle. Normally, this is demonstrated with confidentiality at the top, integrity and availability at the bottom of vertices of the triangle but really from a safety standpoint it’s really the integrity and availability are more important. Sometimes you’ll see the triangle upside down. Not that confidentiality isn’t important, but integrity and availability takes a driver’s seat and shotgun.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>I have a couple of more technical questions for you. We’ll see how many we can get through in our time today, but I am curious, because the hospitals are involved in attending these working group meetings, to a medical device manufacturer who uses the TIR 57, is that going to help them to better understand what kind of procurement questions they are going to be asked in the coming future by hospitals and other healthcare providers? What is the interface here that is going to help the manufacturer to meet not only expectations of the regulator but also expectations of the purchaser?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>I think the primary vehicle that has been used by purchasers has been the MDS2 form, which is a medical disclosure statement for a medical device security. It’s actually MDS squared. That form is a means for a device manufacturer to articulate the different security properties that are available in their device which would inform both the purchaser as well as any people in the hospital that are going to deploy a device into the hospital network, want they should expect.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>While TIR 57 doesn’t directly address a MDS2 form requirements, we do reference it. I would expect that a manufacturer that would use the expectation of that form as they do their security risk management during product design would have the information necessary to disclose on that form automatically by going through the process. That is as opposed to a manufacturer that doesn’t think about security and then is asked at the point when they are marketing the device, “Could you fill this form out?” and they really haven’t thought through the questions when they developed the device then they certainly are<span style="mso-spacerun: yes;"> </span>going to be in a weaker position.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>I would also add that there is another actual standard that plays into this communication between manufacturers and providers, and that is IEC 80001 which is also worked on by a group at AAMI which is the application of risk management for IT networks incorporating medical devices. Now, their risk management incorporates security but it also considers other types of safety risk. In one of the parts of 80001, they have actually aligned with the MDS2 categorization of the types of things to be considered in security. There is an alignment there.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>As Ken has pointed out, we do reference the MDS2. There is some good guidance in some of the annexes of the technical report but I think you’ll see actually much more of that from the post market point of view. We’re currently considering what our next technical report will be. It’s a definite possibility, especially considering the issuance of the most recent guidance on post market that we might tackle a technical report on post market as one of our next work items, but that hasn’t been decided yet.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Okay, great. One more technical question. I’m curious in the TIR 57---medical device manufacturers have very well honed processes for verification, validation and testing. What kinds of things should manufacturers expect to be unusual or maybe different from normal business in terms of testing when it comes to the security principles discussed by the TIR?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>I think in the case of verification from the standpoint of let’s take the example of outside security, essentially when we develop a device, we develop a set of requirements that both are functional and nonfunctional. Then the verification step is to actually verify that the product design and built in manufacture actually meets those requirements. Now, security is a certain nonfunctional property that requires I think some other types of testing. In the case when you look particularly at functional requirements, the universe of things that you’ve said the device must do is finite. You can enumerate what those functional requirements are. You can design tests based on particular use cases that are tied to those functional requirements.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>In the area of security, I think the more challenging thing here is that you are actually saying that the device should not do certain things. Of course the universe of things that any product should not do is essentially infinite, so we can’t enumerate all of the things that a product shouldn’t do in a very fixed sort of way. That creates certain challenges to security testing that we don’t see in a normal verification step. There should be some exploratory types of security testing, penetration testing, obviously there are going to be functional requirements tied to security. Those are obviously to be verified using the typical techniques, but then applying certain tools to actually do vulnerability scanning, fuzz testers and those sorts of things.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>Really, I think the way of thinking about this is that when you do risk management according to for example TIR 57 you’re actually creating a model of the security risk of the device. In my view, what security testing does is, it’s essentially performing an experiment that allows you to verify that your model is correct. You may find things during testing that you have not considered in your risk model, your risk management or your risk assessment of the device, and you’ll have to adjust it. You may determine that you have considered risk but your estimation of the likelihood of that risk or the level of vulnerability or the threat or the exploit-ability is higher than you anticipated.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>It’s just as in science; we create models and we actually do tests, we do experiments to determine whether our models actually fit reality. From my point of view, that is the place of security testing within the framework of risk management.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>There is one other area that goes into the post-market side of things that is somewhat different for device manufacturers as they enter the cyber security realm. It has been very traditional for safety risk for manufacturers that are expected by the regulators to have a post market device surveillance and they often rely on complaints. If a device breaks, somebody is going to call in or contact their service rep and so they have a reasonably good vehicle to collect information about how devices are failing.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>In the cyber security realm, it could be that there is vulnerabilities in their devices because they’ve perhaps used third party software. They have built it on top of a commercial operating system or they have used openSSL libraries that hardly gets discovered in. The whole process of being aware of what might be a vulnerability in your product goes beyond waiting for end users to phone in with a complaint about device failure.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>Many cyber security failures aren’t necessarily going to be noticeable by the user, so that whole process of how manufactures need to think about configuring their monitoring systems and doing diligence on newly discovered vulnerabilities is a brave new world for medical device manufactures.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Great. I’d like to relay at least an account a little story in the context of your work in this working group on medical device security. Let’s take a look at last month. Last month, January 2016, it was a doozy. Over a period of just one week in January, FDA had released its draft guidance document on post market management of cyber security. As you know, more than 500 people registered for that FDA cyber security workshop. It was sold out. People had to be turned away.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>The surprising thing to me was that week when everybody was nestled at FDA, three hospitals confirmed various cyber security attacks ranging from ransomware that had encrypted the system demanding a ransom to get the data back and even a computer virus that has been confirmed to have interrupted clinical workflow and admission systems, including one pathology department of a large hospital that resorted to blood manual processing of their blood and urine samples because of a virus infecting, as you might expect, ancient Windows XP systems.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>With these three compromises including one in Flint where allegedly some hacktivists were causing disruptions to service, with all that happening, an infusion pump company received a second ICS cert alert for what is known as a remotely exploitable buffer overflow in a drug infusion pump. That really surprised me, that this all happened in a period of one week. What I am wondering is imagine a world when the TIR 57 comes out, how is that going to help edge us away from to me it seems like really low-hanging fruit of such weak infrastructure in our healthcare system. What should we expect to see change?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Hopefully along with the TIR coming out will be a significant amount of communication both at conferences and workshops about what is in this and potentially even education processes that we can have available to try to teach manufacturers. I think a month like last month helps continue to communicate to device manufacturers that may be dragging their feet that this is actually a real problem and they do need to address it. I think some of it, as you say, is poor cyber security hygiene.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>I think some is poor choice of systems. I think a lot of manufactures and I think even purchasers of equipment are drawn to low prices and low prices can be achieved when you build on top of commercial operating systems, but building on top of something that you know is going to lose support well before end of use of the device is not really a wise decision by the manufacturer. Hopefully we’ll see better choices of underlying platform technologies and better awareness that they need to be able maintain these devices.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>I think the technical report is not obviously the complete answer. There is a number of other things that Ken particularly alluded to. For example, the alignment of the product road-maps or the third party components that you build into your devices with a very long life-cycles of typical medical devices is a critical part, so actually doing some cyber security planning in terms of life cycle alignment is going to be really important. I think in general what you’ll see from the technical report is that the devices will generally be more secure out of the box.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>Obvious sorts of defects will decrease and as they gain expertise with doing security risk management and assessment, they’ll systematize the way they actually look at the security of the device and hopefully most of these types of issues with regard to really, really poor security will be caught during the initial analysis phase. If they do it right there is a post market component to that also, which is, as new data comes in about the security of the device whether it is through complaints or cyber security incidents, we expect those security risk assessments to be updated.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;"><span style="mso-tab-count: 1;"> </span>Initially there will be more security outside of the box an as time goes on, we expect the risk assessments to be updated and the devices to be more secure in an ongoing basis throughout their lifecycle. That is my hope at least.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Kevin, I wanted to jump in one implication of the question when you mentioned the occurrence of ransomware. I have provided this as advice in other situations. If a medical device, an actual classified medical device is taken over by ransomware, the only appropriate solution is for them to repave the software on that back to an original state. I think it would be unreasonable to expect that if you paid ransom on a medical device that the attacker will return the device to an adulterated state. You really can’t trust the state of the software after such an attack has happened. The manufacturer, your biomed company should come in and set it back to some initial controlled state<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>All right, so it can be set up for the next infection.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Yeah, because the thing is, again, the integrity of the device is really paramount and whenever it is compromised, really you have to have confidence that the device is in the state that was intended by the manufacturer. It also makes it really important that manufacturers also have a good baseline of the devices before they deploy them because you want to know what actually happened. When the device is adulterated you’d like to apply some tooling to determine how the system changed. That should be input into; how was it changed and by what mechanism might it have been change and how can we prevent this in the future and then of course, it really needs to go back to its installed state.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Well, we’re rounding out this Archimedes Circular now at about pie-cubed minutes so we’re just about out of time. I did want to take any, if you have any final thoughts you’d like to share with the Archimedes audience on AAMI, the TIR 57 or any other thoughts on medical device security?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Sure. I think it’s been a fascinating process to see the growing realization amongst a larger and larger community that there is really a need for this. I think there was, when the AAMI committee was formed, I think there was a certain amount of resistance and skepticism, how is this going to impact me. I think as time goes on we’re seeing greater and greater awareness amongst both the users and the manufacturers. People are looking for the tools and methods about how to do it, so hopefully we’ll be providing something useful to the community in that regard.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>I agree with that. I would add also that we certainly want people to look at the technical report and at least try to apply some of those lessons there. Also, I’d just like to extend an open call to those involved in cyber security and medical device development to participate in our AAMI device security work-group. I think the more expertise we get in the work-group, I think the better the work product. It’ll be best for manufacturers, and most importantly, best for patients.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Kevin:<span style="mso-tab-count: 1;"> </span>Well, thank you. Thanks Ken, Geoff and Wil for speaking on the program. You’ve been listening to the Archimedes Circular on medical device security as part of the Archimedes Center for Medical Device Security. We’ll see you next time. Thank you very much.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Ken:<span style="mso-tab-count: 1;"> </span>Thank you, Kevin.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Wil:<span style="mso-tab-count: 1;"> </span>You’re welcome. Thank you, Kevin<o:p></o:p></span></div>
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--> <!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";}
</style>
<![endif]--> <!--StartFragment--> <!--EndFragment--><br />
<div class="MsoNormal" style="margin-left: 1.0in; mso-margin-top-alt: auto; text-indent: -1.0in;">
<span style="color: black; font-family: "calibri"; font-size: 11.0pt;">Geoff:<span style="mso-tab-count: 1;"> </span>Thanks, Kevin.<o:p></o:p></span></div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-18588490915163945262016-04-23T15:17:00.002-07:002016-04-23T15:17:42.649-07:00Comments on Postmarket Cybersecurity Guidance: The FDA Awakens<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMvn3BvQtS5gzJgK3i4WPcVkZwjHyPEvK1EypfkfGv7Lda6Vbok7fGalyG5R7tzEGMvPpKZ6j_7lypySRbMpiOyhTx10e3qvsGk7KWU9gjkUKyqlpwo7clz2WqwTwQEtYlfH3fe0NPmcTL/s1600/postmarket-killer-base.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhMvn3BvQtS5gzJgK3i4WPcVkZwjHyPEvK1EypfkfGv7Lda6Vbok7fGalyG5R7tzEGMvPpKZ6j_7lypySRbMpiOyhTx10e3qvsGk7KWU9gjkUKyqlpwo7clz2WqwTwQEtYlfH3fe0NPmcTL/s320/postmarket-killer-base.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">FDA's draft postmarket guidance on cybersecurity greatly<br />
improves beyond past approaches, but the devil is in the details</td></tr>
</tbody></table>
The deadline to submit comments on <a href="http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf">FDA's draft postmarket cybersecurity guidance</a> has come and gone last week. Below is a copy of my <a href="https://spqr.eecs.umich.edu/papers/FDA-post-market-Fu-2016.pdf">comments to FDA</a>.<br />
<br />
My major recommendation pertains to language choice when describing postmarket risks so as to monitor for postmarket problems without falling victim to the <a href="https://en.wikipedia.org/wiki/Streetlight_effect">streetlight effect</a>. While network-based threats are a significant part of the problem, it's just one of many postmarket problems. There's a reason we don't write guidance on how to avoid flu by sneeze, then write a different guidance document on how to avoid flu by cough. By focusing instead on <b>exposure to cybersecurity risk</b>, the industry can better prepare for shifting threats whether it be by network, USB drive, telephone social engineering, or whatever fancy technology next comes out of Silicon Valley. To ensure that the postmarket guidance can remain relevant as technology and threats change, focus on overarching exposure<b> </b>rather than streetlight modalities.<br />
<br />
I also advise manufacturers and HDOs to follow the NIST cybersecurity guidance for critical infrastructure. For example, (1) enumerate cybersecurity risks because deploying technology without understanding risk is counterproductive; (2) deploy cybersecurity controls that match the specific risks; and (3) continuously measure the effectiveness of the security controls because threats, vulnerabilities, and misconfigurations can bypass a previously effective control within seconds. For instance, if you just look for threats against your core reactor, you might forget about your <a href="http://starwars.wikia.com/wiki/Starkiller_Base">thermal oscillator</a>.<br />
<br />
My <a href="https://spqr.eecs.umich.edu/papers/FDA-post-market-Fu-2016.pdf">letter is downloadable here</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://spqr.eecs.umich.edu/papers/FDA-post-market-Fu-2016.pdf"><img border="0" height="296" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG-8qYy2qPXJeCP5K_7mzGPM0QE-16MreWOj5ICFUk9z8vwiYEGzhrfSAtxTeyWkSafmSrGNzGGqnM46VvdNr34tP81pFonqGCKb6VTDhoGenprfnq9FPSIPzT3vbaQnmj8VI3NCHB4jpa/s320/Screen+Shot+2016-04-23+at+5.58.44+PM.png" width="320" /></a></div>
<br />
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-82005215239709702622016-01-31T20:31:00.002-08:002016-01-31T21:33:13.272-08:00White House Roundtable on Cybersecurity of Hospitals and Medical Devices<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhLiCbiB9GXWP3DYfi7fMNO6UyQXKk13MtRGoJY706E0TBSQ6SPrB4u-TH_t1kTe_rP6FSFdzDKRfcqimnyzP_qKRTttSg84PROZOEdk9TYC-Gj9TRdFKg6JhYY5R7YkIrEEMsifJBl9Y5/s1600/12369191_10100736918855508_8102463691039369099_n.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhLiCbiB9GXWP3DYfi7fMNO6UyQXKk13MtRGoJY706E0TBSQ6SPrB4u-TH_t1kTe_rP6FSFdzDKRfcqimnyzP_qKRTttSg84PROZOEdk9TYC-Gj9TRdFKg6JhYY5R7YkIrEEMsifJBl9Y5/s400/12369191_10100736918855508_8102463691039369099_n.jpg" width="300" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The White House convened a leadership roundtable<br />
on the topic of cybersecurity of hospitals and<br />
medical devices.</td></tr>
</tbody></table>
Last month, the White House quietly convened a group of medical device security stakeholders and domain experts to discuss the cybersecurity challenges faced by healthcare delivery organizations and medical device manufacturers. There were actually multiple meetings. Here I summarize just one that I attended in my role as a professor leading the <a href="http://www.secure-medicine.org/">Archimedes Center for Medical Device Security at the University of Michigan</a>, and in my role as a member of the <a href="http://cra.org/ccc/about/">Computing Research Association's Computing Community Consortium (CCC) Council</a>.<br />
<br />
Convened by the <a href="https://www.whitehouse.gov/administration/eop/ostp">President's Office of Science and Technology Policy (OSTP)</a>, we sat together in the elegant Diplomatic Room in the Old Executive Office Building. I was invited because of my expertise in medical device security and FDA regulatory affairs dating back to when I briefed the FDA in October 2006 on looming cybersecurity risks and when I worked in hospital IT in the early 1990s. I was probably not invited for <a href="https://www.youtube.com/watch?v=uIw-6NLgKbA">my bread making skills</a>.<br />
<br />
The room was packed with people from a diverse set of backgrounds: techies, physicians, policy wonks, CISOs, lawyers, and more. I noticed that the group roughly divided into <a href="http://www.sacred-texts.com/cla/jcsr/dbg1.htm">three parts, like Gaul</a>:<br />
<div>
<ul>
<li>visitors like myself who responded to questions, </li>
<li>special assistants to the President who asked questions, and </li>
<li>leaders from various parts of the executive branch who listened attentively.</li>
</ul>
</div>
<div>
White House Chief Data Scientist <a href="http://fivethirtyeight.com/datalab/dj-patil-white-house-chief-data-scientist-interview/">DJ Patil</a> chaired the meeting. White House Cybersecurity Czar <a href="https://www.whitehouse.gov/blog/author/michael-daniel">Michael Daniel</a> asked many questions. There were a large number of federal representatives from </div>
<div>
<ul>
<li>various HHS agencies (FDA, CMS, OCR, ONC) plus the HHS CISO,</li>
<li>the U.S. Digital Service, </li>
<li>DOD, </li>
<li>DHS, </li>
<li>FBI, </li>
<li>NIH, </li>
<li>the National Security Council, and </li>
<li>a guy from the Secret Service who offered just his first name.</li>
</ul>
</div>
<div>
One notable techie in the room was <a href="http://www.techrepublic.com/article/mina-hsiang-engineer-healthcare-gov-rescue-team-member-health-data-wrangler/">Mina Hsiang</a>, a fellow engineer from MIT who served in the tech surge team to rescue healthcare.gov.<br />
<div>
<br /></div>
We talked about the NIST cybersecurity framework, collaboration across agencies and industry, regulatory matters to incentivize better cybersecurity, information sharing so that hospitals and manufacturers need not be in the dark about threats, incident and vulnerability response, leadership, and medical devices in general.</div>
<div>
<br /></div>
<div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4edIWyH71lnaRis8YFMt6V7GQhAnOuWwHXewbj4yGsI7ZPCnMtYDenKwdlKW5Z47rfYc5xIaMg6AE-jT3xcCAA52hJ-2ucahs2jkqFnUGcqDJPBIpRSMJqF0Xlv3Y5p15vk9BWZ2Xfqmm/s1600/klonoff-fu-White-House-Dec-2015.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj4edIWyH71lnaRis8YFMt6V7GQhAnOuWwHXewbj4yGsI7ZPCnMtYDenKwdlKW5Z47rfYc5xIaMg6AE-jT3xcCAA52hJ-2ucahs2jkqFnUGcqDJPBIpRSMJqF0Xlv3Y5p15vk9BWZ2Xfqmm/s200/klonoff-fu-White-House-Dec-2015.png" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Prof. Kevin Fu and Dr. David Klonoff</td></tr>
</tbody></table>
Michael Daniel expressed concern that the Internet was becoming a liability, but also that security problems can slow innovation. He pointed out that the median number of days to detect an intrusion has improved to an embarrassing 209 days across all industries. So what happens during those 209 days as the intrusion spreads its tentacles thru a hospital? He also expressed hope that computer scientists can find a way to decouple and better layer security into operating systems (sounds right up the alley for an <a href="http://sigops.org/sosp/sosp15/history/">SOSP paper</a>). Multiple speakers brought up the topic of Medicare/Medicaid reimbursement policies, and how it ought to use the power of the purse to incentivize purchasing of more secure, safe, and effective products. Separately reached for comment, a representative from CMS explained that they do routinely realign their reimbursement policies, especially when FDA uses new guidance (ahem, cue the new FDA <a href="http://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190.pdf">pre-market</a> and <a href="http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM482022.pdf">post-market</a> guidance). A CMS representative explained that it's not uncommon to set policies more strict than FDA requirements by pointing to industry standards (cue <a href="https://standards.aami.org/kws/public/projects/project/details?project_id=876">AAMI TIR 57</a> on medical device security).<br />
<br />
<h3>
</h3>
<h3>
It's the Simple Stuff, Stupid</h3>
<div>
I spoke about cybersecurity problems at hospitals and medical device manufacturers, why the problems exist in the first place, and how stakeholders are genuinely working on the problems. The good news is that many (but not all) manufacturers and hospitals genuinely want to find a way to mitigate cybersecurity risks. In contrast to sensationalist media reports, I emphasized that the greatest near-term risks are dirt simple: the delivery of patient care is disrupted when medical devices get compromised by garden variety, decade-old malware by accident. These devices are no longer safe and effective, and often require downtime to clean up the cybermess. My longer manifesto on this subject appears in the <a href="https://www.nae.edu/Publications/Bridge/148391/148425.aspx">National Academy of Engineering Winter 2015 newsletter</a> and as part of a workshop at the <a href="https://spqr.eecs.umich.edu/papers/fu-trustworthy-medical-device-software-IOM11.pdf">Institute of Medicine</a>.</div>
<div>
<br /></div>
<div>
The feds had many questions about <a href="http://www.nist.gov/cyberframework/">NIST guidance documents on cybersecurity</a>, and the invited guests from industry heaped praise on NIST for documents that actually get used in practice. Footnote: NIST is about to celebrate the grand opening of its new <a href="https://nccoe.nist.gov/">National Cybersecurity Center of Excellence (NCCoE)</a>. I've been asked to spread the word about their recently posted call on <a href="http://www.nist.gov/itl/acd/nccoe-seeks-vendors-to-help-secure-wireless-medical-devices.cfm">tools to protect the security of medical devices</a>.<br />
<br />
One of the more interesting conversations involved culture shock. When I spoke about the security problems that hospitals face and the sometimes adversarial relationship between IT and biomedical groups, the counsels from the American Hospital Association nodded, smiled, and sighed in agreement. They know what I am talking about: the IT security people that lock down computers to the point that clinicians can't get their job done, or the clinician who accidentally infects a cathlab with virus transferred by a USB stick from a Yahoo account on a nursing workstation. Having worked in a community hospital installing computers in patient rooms, back offices such as medical records, and administrative areas such as the CEO's office, I had first hand experience observing effective and ineffective ways of deploying technology in clinical areas. IT security people: thou shalt not interrupt clinical workflow! Period!<br />
<br /></div>
<div>
<h3>
For the academics</h3>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrznXtS2RT4ZoyYTJPY0YjqfEidmQ7D2O_8npnRL-MTWBtvGHooh27KsSQuStqhue4hq47OFhlmxucWvQSODzvvXFH5Qc-k2XHHo6Tb4-SBf4dth5HkaGm6c4cKPPDXAUHao06_Zxj7Vwg/s1600/IMG_8016.JPG" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrznXtS2RT4ZoyYTJPY0YjqfEidmQ7D2O_8npnRL-MTWBtvGHooh27KsSQuStqhue4hq47OFhlmxucWvQSODzvvXFH5Qc-k2XHHo6Tb4-SBf4dth5HkaGm6c4cKPPDXAUHao06_Zxj7Vwg/s200/IMG_8016.JPG" width="150" /></a>I'd like to encourage my fellow computer science faculty to get out of their dingy offices and educate leaders in government. Conference and journal publications are not the end point of research, but rather the beginning of impact on society at large. For faculty who might participate in future White House roundtables, here's a bit of advice. Come prepared with a single request, not a long annoying list, of how the government can help help rather than get in the way. My request was simple: use the force. That is, use the convening force of the government to bring stakeholders together. I asked them to convene medical device manufacturer CEOs, Boards of Directors, and hospital executives to ask how they are meaningfully addressing medical device security risks.<br />
<br />
<h3>
Final thoughts</h3>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiat2ZUpDqAIr93EQD5c9SsGSsP0Jkt5Ezg8xnFbEcUFKcUPCzby4DK09FUJaaR21SaeBlI1LAQ2OlzPFbI9K46Miez4nPWhFwAoPLKx9r5Pm72VC82t7yclhZoIqeiPoFroRHN5jRZ42NA/s1600/IMG_8015.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiat2ZUpDqAIr93EQD5c9SsGSsP0Jkt5Ezg8xnFbEcUFKcUPCzby4DK09FUJaaR21SaeBlI1LAQ2OlzPFbI9K46Miez4nPWhFwAoPLKx9r5Pm72VC82t7yclhZoIqeiPoFroRHN5jRZ42NA/s200/IMG_8015.JPG" width="150" /></a>The higher ranking people in federal government are just beginning to wrestle with the problem of medical device security. It's clear that the government isn't going to sit idly as hospitals continue to get infected with cybersecurity problems (three hospitals hit last week [<a href="http://www.theage.com.au/victoria/royal-melbourne-hospital-attacked-by-damaging-computer-virus-20160118-gm8m3v.html">1</a>, <a href="http://www.fierceemr.com/story/texas-hospitals-ehr-system-suffers-ransomware-attack/2016-01-27">2</a>, <a href="http://www.mlive.com/news/flint/index.ssf/2016/01/flint_hospital_confirms_cyber.html">3</a>]) and manufacturers continue to produce difficult to secure devices (<a href="https://ics-cert.us-cert.gov/advisories/ICSA-15-337-02">remote buffer overflows in drug infusion pumps</a> last week). At the end of the day, hands were shook, business cards were exchanged, speaking invitations were offered, and other passive tense events. </div>
<div>
<br /></div>
<div>
The government is a meta-organization, and you should not expect them to directly solve your problems. They will not do your homework for you, and they won't debug your software for you. But they will set expectations and desired outcomes, and they will <a href="http://www.wired.com/2015/06/hackers-can-send-fatal-doses-hospital-drug-pumps/">take action against medical device companies that prefer to bury cybersecurity problems</a>. Expect to hear about the outcomes of these types of ongoing meetings at the 4th Annual <a href="http://www.secure-medicine.org/#!workshop/r0vvb">Archimedes Workshop on Medical Device Security</a> at the University of Michigan. Ok, all for now!<br />
<div>
<br /></div>
<a href="https://web.eecs.umich.edu/~kevinfu/">Kevin Fu</a> is Associate Professor of EECS at the University of Michigan and Chief Scientist of Virta Labs, Inc.</div>
</div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-73214691764065237082016-01-19T20:05:00.003-08:002016-01-19T20:05:55.373-08:00Postmarket Management of Cybersecurity in Medical Devices: FDA Releases #2 Draft Guidance Document<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEheMh55rVQnNI7-ai3Gn7dqV8efusVXsGzKgCo5LKB23jD0DZOWvyl8zaq5xqux_-we67lwtK9EkWdvtgolFr0JbjS5Q_Xm9-9oBMXHu3Q1m6LmcyBRuxOgYswnpKstUiJ-GqWhJ71_x17t/s1600/IMG_8312.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEheMh55rVQnNI7-ai3Gn7dqV8efusVXsGzKgCo5LKB23jD0DZOWvyl8zaq5xqux_-we67lwtK9EkWdvtgolFr0JbjS5Q_Xm9-9oBMXHu3Q1m6LmcyBRuxOgYswnpKstUiJ-GqWhJ71_x17t/s320/IMG_8312.JPG" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">In the end, poost-market medical device <br />security is about peeople and respoonsibility. Photo<br />taken today outside the Washington Convention<br />Center meeting on automotive cybersecurity.</td></tr>
</tbody></table>
FDA has unleashed its long-awaited #2 guidance document on cybersecurity: its draft <a href="http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM482022.pdf">post-market guidance on medical device security</a>. Ok, ok, I conclude my Secure Health IT humor here.<br />
<br />
I'd like to commend FDA for releasing this difficult to write document. To the arm chair engineer, one might think this is easy stuff. Wrong. While the <a href="http://blog.secure-medicine.org/2014/10/fda-issues-final-version-of-long.html">already finalized pre-market guidance</a> primarily focuses on basic <b>engineering practices</b> to build security into medical device designs, the post-market guidance is mostly about <b>people and effective communication</b>. Why is writing post-market guidance so difficult? Because it's more about people than technology.<br />
<br />
There's a lot that the FDA guidance gets right, and most of my criticism pertains to word choice (and lack of puns) that can be solved by editing. The preamble of the document (that focuses on networked medical devices) does not entirely match the body of the document (that talks about all devices, not just networked). The terms "networked devices” and “connected" are red herrings. A network is not necessary for an cybersecurity exploit; malware gets in just fine by unhygienic USB drives carried by unsuspecting personnel. Social engineers still use telephones to trick personnel into enabling unauthorized remote access. The final post-market guidance will need to more deliberately draw attention to outcomes of compromise and risks of vulnerabilities rather than the constantly evolving modality of delivery of exploits. After all, when we talk about surveilling for the spread of flu, we don't limit discussions to spread by cough versus spread by sneeze. Should the document list networked and connected devices as examples of infection vectors? Yes. Should it mention only networked and connected devices? No. Outcomes, not modalities.<br />
<br />
What's my opinion on important post-market activities in general? Stakeholders need to communicate vulnerabilities more effectively, and monitor for shifting threats. Medical device manufacturers should create workflows to receive outside input on potential vulnerabilities.<br />
<br />
Security folks who discover potential problems need be aware of timescales for responses to responsible security vulnerability disclosures. As <a href="http://allan.friedmans.org/">Allan Friedman</a> explains, even if you think you're the most important person on the planet, don't expect a medical device manufacturer to simply drop everything they are doing to fix a security flaw overnight. On the other hand, it boggles the mind why a manufacturer might wait a year to meaningfully respond to a clinically significant vulnerability reported by a security researcher.<br />
<br />
I expect to see more FDA actions on the less noble manufacturers who do not catch up with this basic medical device security post-market guidance.Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-13352246430198998202015-12-03T05:42:00.002-08:002015-12-03T05:42:42.718-08:00FDA Hosts Workshop on Medical Device Cybersecurity in 2016<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVAn91mESfvc8o2CJlFxU5-0wAu9rwB6Ls4QJ3cBLnJucTmdH7gMeQn_bxHAJPXvezJVoHzv37tRR-Gzt5Kr3Nb8sA9pjDe-8eDhVb2Wc-KY97h81IFXAN1nIXpxSEoXj4qOFE3yUC7EOX/s1600/together.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVAn91mESfvc8o2CJlFxU5-0wAu9rwB6Ls4QJ3cBLnJucTmdH7gMeQn_bxHAJPXvezJVoHzv37tRR-Gzt5Kr3Nb8sA9pjDe-8eDhVb2Wc-KY97h81IFXAN1nIXpxSEoXj4qOFE3yUC7EOX/s400/together.jpg" /></a><br />
I'm pleased to announce that FDA will be holding its 2nd workshop on<b> <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm474752.htm">Collaborative Approaches to Medical Device Cybersecurity</a></b> on January 20-21, 2016 at FDA's White Oak headquarters. This public workshop will bring together the stakeholders who have been communicating over the last couple years to find collaborative ways to improve rather than whine about medical device security.<br />
<br />
On everyone's minds is the anticipated <b>FDA guidance document on post-market cybersecurity</b> as well as the <a href="https://standards.aami.org/kws/public/projects/project/details?project_id=876"><b>AAMI guidance document on medical device security</b></a> that many of us have been toiling over for multiple years to help medical device engineers incorporate cybersecurity best practices into the early requirements engineering, design, and implementation of medical devices.<br />
<div>
<br /></div>
<div>
For others in the cyberphysical systems space, one might come a day early because the <a href="http://www.nhtsa.gov/Research/Crash+Avoidance/Automotive+Cybersecurity">National Highway Traffic Safety Agency</a> will be holding a suspiciously similarly sounding <b>Vehicle Cybersecurity Roundtable</b> on January 19, 2016!</div>
<div>
<br /></div>
<div>
All these interesting workshops will be leading up to the <a href="http://secure-medicine.org/workshop/">4th Annual Archimedes Workshop on Medical Device Security</a> in May 16-17, 2016 in Ann Arbor, MI.</div>
<div>
<br /></div>
<div>
See you there!</div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-53463999046875494332015-09-29T20:02:00.000-07:002015-09-29T22:07:04.660-07:00Medical Device Security Report at the National Academy of Engineering FOE<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.eecs.umich.edu/eecs/about/articles/2015/NAE-IMG_1960.JPG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://www.eecs.umich.edu/eecs/about/articles/2015/NAE-IMG_1960.JPG" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Prof. Fu speaking with fellow engineers at the NAE Beckman Center.</td></tr>
</tbody></table>
Here you can find my newly released report "<a href="http://www.naefrontiers.org/File.aspx?id=50750">On The Technical Debt of Medical Device Security</a>" from the National Academy of Engineering web site.<br />
<br />
Earlier this month, I spoke about medical device security at the annual "<a href="http://www.naefrontiers.org/Symposia/USFOE/USFOE-PastSymposia/2015USFOE.aspx">Frontiers of Engineering</a>" event held by the <a href="https://www.nae.edu/">National Academy of Engineering</a>. All the talks were captivating and intellectually stimulating, including topics such as the <a href="http://www.naefrontiers.org/File.aspx?id=51211">James Webb Space Telescope</a>, <a href="http://www.naefrontiers.org/File.aspx?id=51129">nanostructured metamaterials</a>, and forecasting natural disasters. <br />
<br />
One of the more memorable talks was by Jeremy Banik of the Air Force Research Laboratory who demonstrated a high strain composite mechanism by unrolling an innocent looking 1 ft long Carbon Storable Tubular Extendible Member into a sturdy 20+ ft pole. The pole automatically unfurls and makes a rather loud snap as it zips itself up. It's designed for deployment in space where payloads that fit the geometry of a rocket must expand to carry out large-diameter space missions. The audience asked if TSA had ever tried opening the roll, and the answer is no, but it would be tubular, dude.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBt9X_SlucLGwkljBaUfEdZYNUE7ueD5bwtZvItWdWp8HDS9JFI316TqjU3jPjm-_N4OiMTbuqq6Uc1tL-MTkGk2W7lzl7x1O5lemiHjIO5HhUgpfcsrRRxplMW_DsQcvckDO3D4XANQq4/s1600/Screen+Shot+2015-09-29+at+10.31.19+PM.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="125" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBt9X_SlucLGwkljBaUfEdZYNUE7ueD5bwtZvItWdWp8HDS9JFI316TqjU3jPjm-_N4OiMTbuqq6Uc1tL-MTkGk2W7lzl7x1O5lemiHjIO5HhUgpfcsrRRxplMW_DsQcvckDO3D4XANQq4/s320/Screen+Shot+2015-09-29+at+10.31.19+PM.png" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div style="font-size: medium; text-align: start;">
Carbon Storable Tubular Extendible Member. Photo from <a href="http://www.naefrontiers.org/File.aspx?id=51121">Jeremy Banik</a>.</div>
</td></tr>
</tbody></table>
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-89578777899151252912015-09-14T10:27:00.002-07:002015-09-14T10:27:36.276-07:00A Musical Interlude to Medical Device SecurityWe at Archimedes have been busy running security engineering tutorials at medical device manufacturers and hospitals over the past several months, so we have not had the opportunity to post new material lately. We are also in the middle of scheduling various seminars on medical device security at hospitals as part of October's National Cybersecurity Awareness month.<br />
<br />
In the meantime...to brighten your day, here is a music video co-authored by yours truly about the woes of compilers, gdb, and autograders for programming homework to the tune of Taylor Swift's "Shake It Off."<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/bBCNkjgqatI/0.jpg" src="https://www.youtube.com/embed/bBCNkjgqatI?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-78293321090482341232015-07-25T12:23:00.005-07:002015-07-25T12:24:16.519-07:00When Will a Medical Device Endure a Cybersecurity Recall?<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://www.gannett-cdn.com/-mm-/69b87ef1f4f091c1c5a35ae1725a4319304a5618/c=72-0-464-295&r=x404&c=534x401/local/-/media/2015/07/24/DetroitFreePress/DetroitFreePress/635733344158922152-jeep-hacking.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://www.gannett-cdn.com/-mm-/69b87ef1f4f091c1c5a35ae1725a4319304a5618/c=72-0-464-295&r=x404&c=534x401/local/-/media/2015/07/24/DetroitFreePress/DetroitFreePress/635733344158922152-jeep-hacking.jpg" height="240" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Cybersecurity for the Internet of Things: A house of cars?</td></tr>
</tbody></table>
For years, I was wondering which would happen first: a medical device cybersecurity recall or an automotive cybersecurity recall. We now have the answer. By now you must have heard that <a href="http://www.nytimes.com/2015/07/25/business/fiat-chrysler-recalls-1-4-million-vehicles-to-fix-hacking-issue.html">Fiat Chrysler has earned the honor of the first cybersecurity automotive recall of 1.4 million vehicles</a>. <br />
<br />
Issuing a recall is no light matter because there are subtle risk-benefit implications. For instance, a sudden recall on a medical device could have profound risks that outweigh the benefits of a blanket recall. In a non-cybersecurity context, this debate arose not long ago when a <a href="http://www.nejm.org/doi/full/10.1056/NEJMp0800495">defibrillator lead suffered a mechanical design flaw</a>. Because removal of an electrode could pose risks to a patient when the tip had already bound to the cardiac tissue, only certain patients were recommended to replace the electrode. So whereas today automobiles have been recalled for cybersecurity reasons, there will need to be a different debate when eventually some medical device will suffer a clinically relevant cybersecurity flaw. If the flawed device is not implanted and other competing devices are available, then a recall may make sense in the risk-benefit calculus as patients can use another device (e.g., an infusion pump or bedside monitor). On the other hand, blanket recalls are likely not the answer for an implanted device where there are fewer alternatives available for patients already with certain predisposed risks.<br />
<br />
The medical device community should consider itself lucky that the automotive community has earned the dubious honor of having the first cybersecurity-only recall. Given the large number of medical devices, it's just a matter of time before some medical device company will receive a painful, late night phone call to confront challenges similar to what Fiat Chrysler is now enduring.<br />
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-31000292799781027712015-03-23T10:33:00.001-07:002015-03-23T10:33:30.995-07:00How I Met Your Founder: Kevin Fu Meets Earl Bakken of Medtronic<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeChO2aa9816hk8qGFbNcY_S9UavAwAWmY1nySpZkuSy_u40lTetlWq2aq-WnjR79AwIWu7gaL6boaGcHU4zpK9cSe_owAXJe4XbFuOyp-7pImI0RC4o3cgyhNc0OXjwRcAxa4n-Hl5zQ7/s1600/IMG_5168.JPG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjeChO2aa9816hk8qGFbNcY_S9UavAwAWmY1nySpZkuSy_u40lTetlWq2aq-WnjR79AwIWu7gaL6boaGcHU4zpK9cSe_owAXJe4XbFuOyp-7pImI0RC4o3cgyhNc0OXjwRcAxa4n-Hl5zQ7/s1600/IMG_5168.JPG" height="320" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Earl Bakken and Kevin Fu discussing <br />blended medicine, January 2015</td></tr>
</tbody></table>
I recently had the pleasure of speaking about medical device security at the <a href="http://www.ics.hawaii.edu/">University of Hawaii at Manoa</a>, touring the unique patient facilities of the <a href="http://www.nhch.com/cms/view.aspx/Show/Home">North Hawaii Community Hospital</a>, and meeting with <a href="http://www.earlbakken.com/">Earl Bakken</a> at his home on the Big Island. Earl co-founded Medtronic and is most widely known for inventing the first external, battery-operated, transistorized, wearable artificial pacemaker in 1957. At 91-years-young, Earl continues to keep a busy schedule!<br />
<div>
<br /></div>
<div>
I have to admit, nine years ago I would not have predicted that I'd be having a private lunch conversation about blended medicine with Earl in his home. Back in 2006, I became intensively preoccupied with understanding and improving the security and privacy of implantable medical devices. It took a couple years, but after a rejection, one of <a href="https://spqr.eecs.umich.edu/publications.php?q=health">our first papers on medical device security</a> was eventually published at the IEEE Symposium on Security and Privacy in 2008. Needless to say, there was initially some mutual mistrust between various parties. Here's this academic from the ivory tower warning of security problems from the future! It's only natural to be suspicious.<br />
<br />
Fast forward to 2015, and you'll find that many major medical device manufacturers understand the importance of cybersecurity, but are still working on their solutions under the spirit of NIST and AAMI security and risk frameworks. There are growing pains. That's why each May, top engineers from the medical device industry and healthcare providers descend on Ann Arbor for interdisciplinary group problem solving at the <a href="http://secure-medicine.org/workshop/">Archimedes Workshop on Medical Device Security</a>.<br />
<br />
I've got quite the tome of notes from my discussion with Earl, so I'll be updating this blog entry with stories as I get a break from teaching a large undergraduate class this semester. Stay tuned for the next photo and story!<br />
<br />
<h2>
North Hawaii Community Hospital</h2>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkwb48yUSNCVMcvYRXLH3rs17rM7jFoZYfIQ17HQl1ErJT0b1EVzjfmSslY3tPBBOVRTDwrkzQF0lG25DBmqdzmzbaTn-Gt3IvSW61L3x15EyyZM41yR03_nytFBSoeZkwLlNT1T1g74Gl/s1600/IMG_5095.JPG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkwb48yUSNCVMcvYRXLH3rs17rM7jFoZYfIQ17HQl1ErJT0b1EVzjfmSslY3tPBBOVRTDwrkzQF0lG25DBmqdzmzbaTn-Gt3IvSW61L3x15EyyZM41yR03_nytFBSoeZkwLlNT1T1g74Gl/s1600/IMG_5095.JPG" height="320" width="240" /></a></td></tr>
<tr><td class="tr-caption"><br />The radiologists hang loose at North Hawaii Community Hospital, <br />and have a funny sense of humor.<br /><br /></td></tr>
</tbody></table>
</div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-24926674974719694492014-12-01T09:12:00.006-08:002015-07-25T12:30:05.176-07:00Gary McGraw asks who is in charge of medical device security<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://cdn.ttgtmedia.com/rms/security/gmcgraw_140x180.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="http://cdn.ttgtmedia.com/rms/security/gmcgraw_140x180.jpg" /></a></div>
Gary McGraw, CTO of Cigital, recently served on a federal advisory committee panel to discuss medical device security. Gary shared <a href="http://searchsecurity.techtarget.com/opinion/McGraw-asks-whos-in-charge-of-medical-device-security" target="_blank">his thoughts and recommendations here</a>.<br />
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-82428431279921702952014-10-30T12:34:00.005-07:002014-10-30T12:36:56.944-07:00Hot Topic: Ebola, Technology, and Science<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqTpNn_FJlqL2g319QOXG5SpNK0pmQoM7MsxEySiqOg7aFMZvON5wW2ZIHzzY0cJMmSbWKojHdBKgWQXn-XRYtJddEr4GZWYTlNRcpyvMG2CyrwAYfg_puR7Rp-omZL7GAzv7Jem813xnb/s1600/IMG_4541.JPG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqTpNn_FJlqL2g319QOXG5SpNK0pmQoM7MsxEySiqOg7aFMZvON5wW2ZIHzzY0cJMmSbWKojHdBKgWQXn-XRYtJddEr4GZWYTlNRcpyvMG2CyrwAYfg_puR7Rp-omZL7GAzv7Jem813xnb/s1600/IMG_4541.JPG" height="200" width="149" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Is your IR camera giving you accurate <br />
temperature readings to diagnose Ebola??</td></tr>
</tbody></table>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBk1fTX1G9P-Ef0APLbTRksec53wb5j6aCxufnEltsGWWdhqKNl-84hpred1X45abHSKgzACuboRAGaHrTBR7RJYk65pPcHBnscSDSaWwrqkDz6a4B9zYxCf8MgfSPSeZ0zLpZUoIZMwKH/s1600/IMG_4542.JPG" imageanchor="1" style="clear: left; display: inline !important; margin-bottom: 1em; margin-left: auto; margin-right: auto; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBk1fTX1G9P-Ef0APLbTRksec53wb5j6aCxufnEltsGWWdhqKNl-84hpred1X45abHSKgzACuboRAGaHrTBR7RJYk65pPcHBnscSDSaWwrqkDz6a4B9zYxCf8MgfSPSeZ0zLpZUoIZMwKH/s1600/IMG_4542.JPG" height="200" width="149" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Maybe, maybe not. Re-calibration and angle<br />
causes a 9 degree difference on this IR camera.</td></tr>
</tbody></table>
<br />
<br />
This post diverges from medical device security for a moment to address some technical issues related to persons asymptomatic of Ebola. I happen to carry an infrared camera wherever I go. My lab uses it in research, and to leave secret thermal handprint messages on walls (they last about 5 minutes at my office). I'd like to demonstrate why one should take with a grain of salt the accuracy of temperature readings from infrared imaging to diagnose Ebola.<br />
<br />
Reports claim that <a href="http://abcnews.go.com/Health/talks-ebola-nurse-kaci-hickox-fail-governor-full/story?id=26569596" target="_blank">nurse Kaci Hickox registered an elevated temperature on an infrared scan, but then showed negative for fever with an oral thermometer</a>. This is not surprising, given that infrared cameras are prone to inaccurate results for all sorts of reasons ranging from reflected light, improper or poorly trained use, calibration, thermal changes on the surface of the sensor, or the condition of the subject. (Did you just hear a dirty joke and blush? Or were you upset by an overzealous agent?) Different IR cameras have different sensitivities, and liquid-cooled sensors will have different properties as well. So I surmise that an IR camera used by an airport security guard will have a higher probability of detecting dirty jokes with low false positives than detecting Ebola with low false positives. Thermal cameras are just tools, but one must choose the right tool for diagnosis. Try taking an <a href="http://wearcam.org/safebath_leonardo/safebath.htm" target="_blank">IR photo of a row of recently used toilets</a> if you want to feel especially squeamish in exercising the least recently used principle.<br />
<br />
Don't trust the digital readings from an infrared camera unless you are trained on its measurement and experimental error. The absolute numbers are meaningless on their own. Watch <a href="https://www.youtube.com/watch?v=Y9lxTY2s8u0" target="_blank">MIT Prof. Walter Lewin's physics lecture on measurement error</a> for certainty on this subject.<br />
<br />
<blockquote class="tr_bq">
<span style="background-color: white; color: #333333; font-family: 'Lucida Sans Unicode', 'Lucida Grande', 'Lucida Sans', Verdana, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 20.4799995422363px;">"Any measurement that you make without the knowledge of its uncertainty is completely meaningless." -</span><em style="background-color: white; color: #333333; font-family: 'Lucida Sans', 'Lucida Grande', 'Lucida Sans Unicode', Verdana, Helvetica, Arial, sans-serif; font-size: 13px; line-height: 20.4799995422363px;">Professor Walter Lewin, MIT</em></blockquote>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-63541312263163623672014-10-23T11:18:00.000-07:002014-10-23T11:18:02.430-07:00Medical device cybersecurity actions and outcomes<div class="separator" style="clear: both; text-align: left;">
After two days of vigorous discussion at the <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm412979.htm" target="_blank">FDA workshop on medical device cybersecurity</a>, Dr. <a href="http://blogs.fda.gov/fdavoice/index.php/tag/cyber-security-of-medical-devices/" target="_blank">Suzanne Schwartz</a> ended by challenging attendees to commit to (1) a specific cybersecurity action to take in the next week, and (2) a specific cybersecurity outcome to achieve in the next year.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
My action for the next week is to create a meme for security engineering. Here's my attempt.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOYtES3M8RIWwxEO7tICnwypOOmINIvdbSqk-oR1NWrg9GD0p1eKMGHj5IRHTILOd42pkctixf3VfHof8as2ckFGv0WSPSIjWrieYlH48cmq6lwtd2ypB2-nOTPSLVVq6J2m98wXjWnlTq/s1600/no-accidents-since.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOYtES3M8RIWwxEO7tICnwypOOmINIvdbSqk-oR1NWrg9GD0p1eKMGHj5IRHTILOd42pkctixf3VfHof8as2ckFGv0WSPSIjWrieYlH48cmq6lwtd2ypB2-nOTPSLVVq6J2m98wXjWnlTq/s1600/no-accidents-since.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Original image from <a href="http://www.magnatag.com/img/pages/SWEimages/SWEcover.jpg" target="_blank">here</a>.</td></tr>
</tbody></table>
<br />
<div>
<br /></div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-39416143803629748422014-10-18T14:01:00.000-07:002014-12-01T09:30:49.960-08:00FDA visits NIST federal advisory committee on security and privacy<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDVzx0vyMCa7LH8mHOiQHsYR1nDzwf4Gx-6p7sBtm_nBQ2qaajA-_ezVfrrlWPEG-Bv6tI1eSe5Kr2QcxIWg5CWM8WAnVRXQMqfK2N0KUMkQYLkbA52N3RK8ehHzxia3xnTXDvbokDkVT3/s1600/nist-medsec-2014.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDVzx0vyMCa7LH8mHOiQHsYR1nDzwf4Gx-6p7sBtm_nBQ2qaajA-_ezVfrrlWPEG-Bv6tI1eSe5Kr2QcxIWg5CWM8WAnVRXQMqfK2N0KUMkQYLkbA52N3RK8ehHzxia3xnTXDvbokDkVT3/s1600/nist-medsec-2014.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Suzanne Schwartz (FDA), Key Hoyme (Adventium Labs), <br />
Gary McGraw (Cigital), and Kevin Fu (Univ. Michigan)</td></tr>
</tbody></table>
<b>Update 11/6/2014:</b> The audio recording is now available below.<br />
<br />
<audio controls="">
<source src="http://web.eecs.umich.edu/~kevinfu/audio/ISPAB-medsec-oct-2014.MP3" type="audio/mpeg"></source>
[Your browser does not support the audio element.]
</audio>
<br />
On Friday, October 24, 2014 at 9AM in Washington, DC, the <a href="http://csrc.nist.gov/groups/SMA/ispab/index.html" target="_blank">NIST Information Security and Privacy Advisory Board (ISPAB)</a> will hold a public panel on "Updates on Embedded Device Cybersecurity: Medical Devices to Automobiles."<br />
<br />
Coming on the heels of the <a href="http://blogs.fda.gov/fdavoice/index.php/tag/collaborative-approaches-for-medical-device-and-healthcare-cybersecurity/" target="_blank">FDA workshop on cybersecurity</a>, this panel will provide cutting edge updates on federal policies and industry perspectives on embedded security. The panelists include:<br />
<br />
<ul>
<li><a href="http://www.fda.gov/EmergencyPreparedness/Counterterrorism/MedicalCountermeasures/AboutMCMi/ucm337335.htm" target="_blank">Suzanne B. Schwartz</a>, MD, MBA, Director of Emergency Preparedness/Operations & Medical Countermeasures at FDA, and organizer of the <a href="http://blogs.fda.gov/fdavoice/index.php/tag/collaborative-approaches-for-medical-device-and-healthcare-cybersecurity/" target="_blank">FDA cybersecurity workshop</a></li>
<li><a href="http://www.adventiumlabs.com/about-us/staff/technical-staff/ken-hoyme" target="_blank">Ken Hoyme</a>, PhD, Distinguished Scientist, Adventium Labs</li>
<li><a href="http://www.cigital.com/~gem/" target="_blank">Gary McGraw</a>, PhD, CTO of Cigital </li>
<li><a href="http://web.eecs.umich.edu/~kevinfu/" target="_blank">Kevin Fu</a>, PhD, Associate Professor, University of Michigan EECS (moderator)</li>
</ul>
What will the three PhDs and MD say? For details on the meeting agenda and location, see the <a href="http://csrc.nist.gov/groups/SMA/ispab/documents/agenda/2014_agenda-ispab-october-meeting.pdf" target="_blank">following PDF</a>.Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-20374132503328109052014-10-14T07:31:00.002-07:002014-10-14T07:57:04.860-07:003rd Annual Archimedes Workshop on Medical Device Security<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://secure-medicine.org/public/images/Archimedes_workshop_2014-small.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://secure-medicine.org/public/images/Archimedes_workshop_2014-small.jpg" height="224" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Dozens of medical device and security experts<br />
converge in Ann Arbor each summer.</td></tr>
</tbody></table>
Engineers from medical device manufacturers, safety and security officers from health care providers, Archimedes members, and special guests will converge in Ann Arbor, Michigan for the <a href="http://secure-medicine.org/workshop/" target="_blank">3rd Annual Archimedes Workshop on Medical Device Security</a> May 4-5, 2015. This invitation-only event brings together solution-oriented experts in medical device manufacturing and computer security to discuss the new FDA cybersecurity guidance and how to improve information security.Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-70764995463422396102014-10-03T11:14:00.003-07:002014-10-03T11:43:28.192-07:00EHR software and ebola, what could possibly go wrong?<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiX7A3plLH9pamRy4igC6mXJKvWQ3-CZ1ssASwfXflgBwWnuR1n7qg6iHBR2cb2qLMOrhLJfteANm2TvcTqfKhy-6IUMUOENaNGHdu9EMaWVcnRbZ0Ph1CBpZF__6rW0W3BnH5GqPilZqg9/s1600/cpohl.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiX7A3plLH9pamRy4igC6mXJKvWQ3-CZ1ssASwfXflgBwWnuR1n7qg6iHBR2cb2qLMOrhLJfteANm2TvcTqfKhy-6IUMUOENaNGHdu9EMaWVcnRbZ0Ph1CBpZF__6rW0W3BnH5GqPilZqg9/s1600/cpohl.jpg" height="400" width="319" /></a></div>
Forget malware on medical devices. Try ebola. The Atlantic is reporting that software flaws in the exchange of <a href="http://www.theatlantic.com/technology/archive/2014/10/the-ebola-patient-was-sent-home-because-of-an-electronic-health-record-problem/381087/" target="_blank">Electronic Health Records (EHRs) is partly to blame for an ebola patient</a> being sent home from Texas Health Dallas. More information appears on the <a href="http://www.texashealth.org/body.cfm?id=1629&action=detail&ref=1871" target="_blank">hospital's website</a>.<br />
<br />
According to Bloomberg news, the <a href="http://www.bloomberg.com/news/2014-10-03/electronic-record-gap-allowed-ebola-man-to-leave-hospital.html" target="_blank">EHR software at Texas Health Dallas is made by Epic Systems Corp</a>.Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-1795204532539098592014-10-01T10:27:00.003-07:002014-10-01T16:59:47.636-07:00FDA issues final version of long-awaited cybersecurity guidance<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDHsfNPjRY1Mi6FaKEFZUrw6yL1hLeD49etnMev6eDNpWlMIxL7oUlVOZi5Xwf-lnIuU6k-aelEjVM0D6meL12G3Cx4SM7f4t0Cj8Vp3LUAnH4uHUnpVNwaMdCr5REAbhy8fCucarTNiVu/s1600/funny+traffic+signs-003_.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDHsfNPjRY1Mi6FaKEFZUrw6yL1hLeD49etnMev6eDNpWlMIxL7oUlVOZi5Xwf-lnIuU6k-aelEjVM0D6meL12G3Cx4SM7f4t0Cj8Vp3LUAnH4uHUnpVNwaMdCr5REAbhy8fCucarTNiVu/s1600/funny+traffic+signs-003_.jpg" height="320" width="228" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The long-awaited guidance will help resolve past <br />
uncertainties about expectations of cybersecurity <br />
in the pre-market review of medical devices.</td></tr>
</tbody></table>
Today, FDA issued its <a href="http://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm416809.htm" target="_blank">long-awaited cybersecurity guidance</a> for pre-market review of medical devices. This is a document years in the making. <br />
<br />
A PDF of the actual guidance document appears <a href="http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf" target="_blank">here</a>.<br />
<br />
A second draft cybersecurity guidance document on post-market practices (e.g., vulnerability and incident reporting) is expected later this year. Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-6128736794952898042014-09-30T01:16:00.001-07:002014-09-30T01:16:08.767-07:00NBC Chicago interviews patients, physicians, and researchers on medical device security<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQJR8u677DotO5i6ZfFoR3p1Fx56JZCLHFhMhOfxafDJ6vCqrS2bA8V4EOZe0biC_9fmGx_Uzh01bn23nEAY22LM8XuO4VQQFsCr4Agzy2QFA6W0WKrs_rog-2Km8CyuR9QXFv3s_okWoU/s1600/Leitner.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQJR8u677DotO5i6ZfFoR3p1Fx56JZCLHFhMhOfxafDJ6vCqrS2bA8V4EOZe0biC_9fmGx_Uzh01bn23nEAY22LM8XuO4VQQFsCr4Agzy2QFA6W0WKrs_rog-2Km8CyuR9QXFv3s_okWoU/s1600/Leitner.png" height="169" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The TV headline is hyperbolic, but the content is level headed.</td></tr>
</tbody></table>
<br />
<br />
Tammy Leitner of NBC Chicago interviewed a number of patients, physicians, and researchers about the challenges of medical device security. Here's a link to the <a href="http://www.nbcchicago.com/investigations/Medical-Devices-Vulnerable-to-Hack-Attacks-277538441.html" target="_blank">full video</a>. <br />
<br />
<br />
<br />
<br />
Had this interview happened in 2008, the tone would have likely been more confrontational. Remember when Archimedes researchers demonstrated radio-controlled <a href="http://www.nytimes.com/2008/03/12/business/12heart-web.html?_r=0" target="_blank">security flaws in pacemaker/defibrillators</a> (also see the <a href="https://www.schneier.com/blog/archives/2008/03/hacking_medical_1.html" target="_blank">Schneier commentary</a>)? Back in 2008, manufacturers and FDA were not accustomed to interacting with security researchers reporting such software-based flaws. It's completely understandable. Imagine if an unfamiliar person showed up at your front door to point out security problems of your house. The outcome might be unpleasant. Thus, interactions initially got off to a rocky start. But that's the past.<br />
<br />
Fast forward to 2014, and times have changed significantly for the better. The <a href="http://secure-medicine.org/" target="_blank">forward-thinking manufacturers</a>, influential researchers, and health care providers regularly interact and help each other to improve medical device security. A few positive examples that brought researchers, clinicians, manufacturers, and regulators together include the <a href="http://www.aami.org/publications/aaminews/Aug2013/AAMI_Tackles_Wireless.html" target="_blank">draft technical information report on medical device cybersecurity by AAMI</a> (the IETF equivalent of the medical manufacturing world), the <a href="http://secure-medicine.org/workshop" target="_blank">Archimedes workshop</a>, and the upcoming <a href="http://blog.secure-medicine.org/2014/09/fda-to-hold-workshop-on-medical-device.html" target="_blank">FDA workshop on medical device security</a>.<br />
<br />
So if you're a future graduate student or budding security researcher, I'd encourage you to read the technical papers from the <a href="http://blog.secure-medicine.org/2014/09/fda-to-hold-workshop-on-medical-device.html" target="_blank">short history of medical device security</a>. It's no longer a cat-and-mouse game of pointing out buffer overflows and SQL injection attacks. The future is about <a href="http://thaw.org/" target="_blank">interdisciplinary computing and health care research</a> to produce technology, best practices, and policies that improve medical device security without interfering with the workflow or delivery of health care.Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-80478034995963741672014-09-28T22:36:00.000-07:002014-09-29T08:28:38.416-07:00FDA to hold workshop on medical device security<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://c2.staticflickr.com/6/5206/5227332436_ccf1693a1d.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="240" src="https://c2.staticflickr.com/6/5206/5227332436_ccf1693a1d.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Every workshop needs a bench and a good dremel. <br />
Photo credit: Travis Goodspeed</td></tr>
</tbody></table>
Update: The FDA workshop on medical device security filled to capacity, so there is now a <a href="http://www.fda.gov/MedicalDevices/NewsEvents/WorkshopsConferences/ucm412979.htm" target="_blank">wait list</a>. But the webcast remains available.<br />
<br />
Unless you've been living under a rock, you have probably heard the announcement about the <a href="http://www.gpo.gov/fdsys/pkg/FR-2014-09-23/pdf/2014-22515.pdf" target="_blank">FDA Workshop on Collaborative Approaches for Medical Device and Healthcare Cybersecurity</a>. Or as the Google translation service explains (select translate Government-ese to English): it's an FDA workshop on medical device security.<br />
<br />
This workshop is a follow up to the draft FDA guidance on cybersecurity published in 2013 [<a href="http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm356423.htm" target="_blank">here</a> and <a href="http://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM356190.pdf" target="_blank">here</a>].<br />
<br />
FDA workshops typically provide time to hear from a broad set of interest groups and stakeholders. In the hallways, you will likely see representatives or lobbyists from manufacturing associations, patient groups, physician groups, the cybersecurity industry, and more. And what might be surprising to the jaded reader: most attendees want the same thing, improved medical device security.<br />
<br />
I will be moderating one of the technical panels at the FDA workshop, but I look forward to hearing the perspectives from all the panels.<br />
<br />
Here's a quick look back at selected moments in medical device security history so you can prepare for the meeting of minds:<br />
<ul>
<li>2006 talk at FDA on medical device security challenges [<a href="http://web.eecs.umich.edu/~kevinfu/talks/Fu-FDA-slides.pdf" target="_blank">slides</a>, <a href="https://spqr.eecs.umich.edu/publications.php?q=bellissimo" target="_blank">paper</a>]</li>
<li>2008 research showing security flaws and fixes in a pacemaker/ICD [<a href="http://www.secure-medicine.org/public/publications/icd-study.pdf" target="_blank">paper</a>, <a href="https://spqr.eecs.umich.edu/publications.php?q=ICD" target="_blank">more</a>]</li>
<li>2009 Medical device security Winter begins (Kevin has a baby)</li>
<li>2010 Medical device security Winter ends (<a href="http://web.eecs.umich.edu/~kevinfu/teaching.html" target="_blank">baby goes to college</a>)</li>
<li>2011 <a href="http://www.infosecurity-magazine.com/news/barnaby-jack-hacks-diabetes-insulin-pump-live-at/" target="_blank">demonstration of security analysis of an insulin pump</a></li>
<li>2011 <a href="http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2011-03/March-2011.html" target="_blank">VA, MDISS, and GE present medical device security issues to NIST ISPAB</a></li>
<li>2011 <a href="http://web.eecs.umich.edu/~kevinfu/papers/fu-senate-comm-aging-med-dev-sw-apr-2011.pdf" target="_blank">written testimony</a> on trustworthy medical device software for the U.S. Senate</li>
<li>2011 <a href="http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6026732" target="_blank">research paper on problems and approaches for insulin pump security</a></li>
<li>2011 <a href="http://groups.csail.mit.edu/netmit/IMDShield/" target="_blank">research paper on improving security with a friendly RF shield</a></li>
<li>2011 <a href="http://www.mddionline.com/blog/devicetalk/insulin-pump-hacking-sensationalism-or-legitimate-threat" target="_blank">raising security awareness for users of insulin pumps by insulin pump user</a></li>
<li>2012 <a href="http://csrc.nist.gov/groups/SMA/ispab/documents/correspondence/ispab-ltr-to-omb_med_device.pdf" target="_blank">NIST Information Security and Privacy Advisory Board letter</a> to HHS Secretary Sebelius</li>
<li>2012 Institute of Medicine commissioned report on <a href="https://spqr.eecs.umich.edu/publications.php?q=IOM" target="_blank">trustworthy medical device software</a></li>
<li>2012 <a href="http://blog.secure-medicine.org/2012/02/nist-explores-economic-incentives-for.html" target="_blank">NIST on economic incentives to improve medical device security</a></li>
<li>2012 <a href="https://spqr.eecs.umich.edu/events/2012-medcomm/" target="_blank">ACM MedCOMM Workshop</a></li>
<li>2012 <a href="http://www.computerworld.com/article/2492453/malware-vulnerabilities/pacemaker-hack-can-deliver-deadly-830-volt-jolt.html" target="_blank">demo of pacemaker/defibrillator security analysis</a></li>
<li>2013 <a href="http://blog.secure-medicine.org/2013/01/graduate-course-on-medical-device.html" target="_blank">First graduate course on medical device security offered</a></li>
<li>2013 Archimedes Center for Medical Device Security launches <a href="http://secure-medicine.org/workshop" target="_blank">annual workshop</a></li>
<li>2013 <a href="http://blog.secure-medicine.org/2013/06/fda-publishes-draft-guidance-on-medical.html" target="_blank">FDA publishes draft guidance on medical device security</a></li>
<li>2014 <a href="http://blog.secure-medicine.org/2014/06/nist-ispab-on-emerging-guidance-and.html" target="_blank">NIST ISPAB on emerging standards and guidance for medical device security</a></li>
<li>2014 <a href="http://www.ieee-security.org/TC/SP2014/papers/SoK_c_SecurityandPrivacyinImplantableMedicalDevicesandBodyAreaNetworks.pdf" target="_blank">Survey paper on IMD security at IEEE Symposium on Security and Privacy</a></li>
</ul>
<div class="p1">
This list is far from complete, so feel free to suggest other moments of medical device security history by posting a comment on this blog along with a link to primary sources of written reports, videos, etc. Keep the bulleted text to one line.</div>
<div class="p1">
<br /></div>
<div class="p1">
Several other research papers on medical device security can be found on the <a href="http://secure-medicine.org/publications">http://secure-medicine.org/publications</a> archive. You can also find all the secure-medicine.org blog postings indexed at <a href="http://blog.secure-medicine.org/p/index.html">http://blog.secure-medicine.org/p/index.html</a>. </div>
<div class="p1">
<br /></div>
Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0tag:blogger.com,1999:blog-5112290995341860170.post-78929935040594714972014-08-20T23:42:00.001-07:002014-08-20T23:42:30.056-07:00$50,000 Internet Defense Prize awarded today at USENIX Security<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="http://media-cache-ec0.pinimg.com/736x/2e/8a/0e/2e8a0e06944f84c5dfb6a4f7f52a55c7.jpg" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="http://media-cache-ec0.pinimg.com/736x/2e/8a/0e/2e8a0e06944f84c5dfb6a4f7f52a55c7.jpg" height="235" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><a href="http://media-cache-ec0.pinimg.com/736x/2e/8a/0e/2e8a0e06944f84c5dfb6a4f7f52a55c7.jpg" target="_blank">Graduate Research</a></td></tr>
</tbody></table>
Today, <a href="https://www.facebook.com/notes/protect-the-graph/internet-defense-prize-awarded-at-23rd-usenix-security-symposium/1491475121092634" target="_blank">Facebook awarded $50,000 to a pair of security researchers</a> who authored a peer-reviewed paper at the <a href="https://www.usenix.org/conference/usenixsecurity14/technical-sessions" target="_blank">23rd Annual USENIX Security Symposium</a> on “<span class="s2"><a href="https://www.usenix.org/sec14/dahse">Static Detection of Second-Order Vulnerabilities in Web Applications</a>." The authors intend to use the funds to take their software prototype to the next level. As the program chair of the USENIX Security Symposium, I am delighted that Facebook selected our conference to search for the best defensive work</span> that prevents vulnerabilities and reduces the effectiveness of attacks. Facebook intends to make this an annual prize, and may even increase the prize amount.<br />
<br />
The reason I mention this award here is for the medical device community to think about effective strategies to encourage the security research community to engage in constructive problem solving to improve medical device security. I think the industry would see a shift in thinking if constructive problem solving were better rewarded.<br />
<br />Kevin Fuhttp://www.blogger.com/profile/00903011797098404947noreply@blogger.com0