647516
editorial2016
DSTXXX10.1177/1932296816647516Journal of Diabetes Science and TechnologyKlonoff and Kleidermacher
Editorial
Now Is the Time for a Cybersecurity Standard for Connected Diabetes Devices
Journal of Diabetes Science and Technology 2016, Vol. 10(3) 623–626 © 2016 Diabetes Technology Society Reprints and permissions: sagepub.com/journalsPermissions.nav DOI: 10.1177/1932296816647516 dst.sagepub.com
David C. Klonoff, MD, FACP, FRCP (Edin), Fellow AIMBE1 and David N. Kleidermacher, BS2 Keywords diabetes, cybersecurity, device, standard, security
Executive Overview Diabetes is a worldwide epidemic. In the United States, almost 10% of the population has this disease1 and approximately half of adults have diabetes or prediabetes.2 People with diabetes make therapeutically significant decisions each day about the type and quantity of foods to eat and how much insulin to administer. Over the past two decades, these patients have benefitted from increasingly sophisticated technology to assess blood glucose levels on demand or automatically, recommend medication doses, and even dose on demand or automatically.3 Diabetes patients use four main types of connected devices to measure and react to their glucose data: blood glucose monitors, continuous glucose monitors, insulin pumps, and closedloop artificial pancreas systems.4 Early examples of these devices were not connected to the Internet or each other. Modern devices, however, often leverage computer-networking technology to improve ease of use and enable new treatment paradigms. For example, diabetes data may be transmitted to a smartphone or reader and sometimes to the cloud, enabling improved decision support recommendations and real time alarms for out of range physiology or behaviors. The definition of security is the protection of resources against threat of malicious attack against those resources. In the case of connected diabetes devices, these resources include the data and command information stored within and communicated (usually wirelessly) by devices as well as safe operation of the devices themselves. Threats against connected diabetes devices include unauthorized disclosure and modification of therapeutic data and forced loss of safe device function.
Introduction to DTSec In July 2015 the California-based nonprofit organization Diabetes Technology Society (DTS) launched DTSec (DTS Cybersecurity Standard for Connected Diabetes Devices project).5 A standard has been developed that provides the framework for specifying the security requirements for connected diabetes devices and how to obtain a requisite level of
independent assurance that the devices meet those requirements. Thus, the standard is intended for industry, clinicians, patients, payers, and regulators to assess whether there is adequate cybersecurity in any new or marketed connected diabetes device. This standard contributes to the realization of Presidential Executive Order 13636, which aims to increase the level of core capabilities for the US critical infrastructure in 16 critical sectors, including health care.6 Specifically, this standard contributes to a goal described in the Order, which is to leverage voluntary consensus standards and industry best practices and then build them into a cybersecurity framework. The DTSec working group includes a wide spectrum of stakeholders who use, prescribe, pay for, regulate, and manufacture diabetes devices. From the US government sector our steering committee has had representation from FDA, DHS, NIST, NIH, NASA, and USAF. The Canadian government has participated through Health Canada. Other steering committee members come from professional organizations (American Diabetes Association, Juvenile Diabetes Research Foundation, Endocrine Society, and American Association of Diabetes Educators), academia (medicine, nursing, engineering, mathematics, and law), industry (medical device manufacturers as well as component suppliers and independent cybersecurity experts), and the patient community, which is represented by both users and ethical hackers of these connected devices. To our knowledge such a broad and international coalition of stakeholders has not previously been assembled to develop a consensus cybersecurity standard for medical devices. DTSec leverages ISO 15408, also known as Common Criteria (CC), for specifying security threats, objectives, and 1
Diabetes Research Institute, Mills-Peninsula Health Services BlackBerry Limited, Pleasanton, CA, USA
2
Corresponding Author: David C. Klonoff, MD, FACP, FRCP (Edin), Fellow AIMBE, Diabetes Research Institute, Mills-Peninsula Health Services, 100 S San Mateo Dr, San Mateo, CA 94401 USA. Email: [email protected]
624 requirements for families of products and specific product instantiations.7 While national frameworks exist for specifying security requirements (eg, NIST SP 800-53 in the United States), the CC enjoys the broadest international acceptance for specifying such requirements. 26 nations recognize the CC as a unified approach to specify and evaluate electronic product security requirements. DTSec aims to offer a path to international connected medical device regulatory environments and markets. The CC employs 2 types of specifications: Protection Profile, which is a document-identifying common security requirement for a family of products, and Security Target, which is a document specifying security requirement for a particular marketable product. When the product is a member of a product family covered by a Protection Profile, the product’s Security Target is derived and tailored from the family Protection Profile. Both the Protection Profile and Security Target include two types of requirements: Security Functional Requirements, which define the relevant security controls for applicable products; and Security Assurance Requirements, which are measures used to assure conformance to the claimed security controls.
Relationship of DTSec to other Regulatory Guidance In the United States, several agencies have recently issued cybersecurity guidance, including NIST’s cybersecurity framework8 and FDA’s premarket9 and postmarket10 guidances for cybersecurity of medical devices. Both NIST and FDA guidelines follow a historical risk management approach to medical device quality and safety, wherein security threats are considered yet another risk to safety that must be assessed and managed by manufacturers and caregivers. NIST and FDA guidance are valuable for developers in helping to ensure they are properly considering cybersecurity risk throughout product lifecycles and their organizations. The NIST framework provides a catalog and categorization of typical cybersecurity activities and controls that should be considered by an enterprise. The catalog references existing security specification standards, such as NIST SP 800-53 and ISO 15408. However, neither NIST nor FDA guidance addresses how to map the universe of potential security requirements to specific medical devices. Furthermore, current guidance does not include programs for gaining confidence in a product, system, or organization’s conformity to these requirements via some form of conformity assessment. Therefore, independent stakeholders (eg, caregivers, users, payers) are generally unable to gain confidence in a vendor or product’s security capabilities from existing guidance alone. Even if a vendor self-affirms conformity to a set of risk-based security requirements and is willing to disclose supporting conformance evidence (such as test results and design documentation), claims are unlikely
Journal of Diabetes Science and Technology 10(3) to yield significant independent assurance if not vetted by independent, unbiased cybersecurity evaluation experts following a common evaluation methodology. As stated in the current NIST Cybersecurity framework FAQs: “NIST has no plans to develop a conformity assessment program. NIST encourages the private sector to determine its conformity needs, and then develop appropriate conformity assessment programs.”11 DTSec aims to provide the connected medical device sector with an efficient, standardized approach to provide, through conformity assessment, confidence that the medical device is able to protect itself against applicable security threats.
How DTSec Maps to FDA Guidance As an example of how DTSec may fit into a nation’s medical device regulatory guidance, consider recent FDA premarket guidance.9 The “General Principles” section within this guidance document lists five elements of a vulnerability and management approach. For each element, we explain here how DTSec helps manufacturers implement the FDA guidance: 1. Identification of assets, threats, and vulnerabilities DTSec helps developers identify and document, using ISO 15408 standard methodology, device-specific assets, and threats. The DTSec conformity assessment program helps identify vulnerabilities. 2. Assessment of the impact of threats and vulnerabilities on device functionality and end users/patients DTSec helps to assess the impact of threats and vulnerabilities on device functionality and end users/patients by requiring developers to consider relevant threats and how they might impact safe clinical use. For example, if a diabetic patient makes clinical decisions based on the readings from a glucose monitor, the developer must consider how threats borne over its wireless connection could potentially corrupt the integrity of these readings, leading to unsafe clinical decisions. This assessment leads to the inclusion of appropriate mitigating controls (security functional requirements) in the Security Target specification. DTSec conformity assessments also help assess the impact of discovered vulnerabilities. 3. Assessment of the likelihood of a threat and of a vulnerability being exploited During DTSec conformity assessment, the security evaluator will attempt to understand not only whether a vulnerability is exploitable but also what level of attack potential is required to exploit. This helps developers assess the probability of a threat converting to active exploit based on this potential.
625
Klonoff and Kleidermacher For example, a low potential exploit is likely to have a higher probability of exploit in practice than a high potential exploit beyond the technical and economic reach of most attackers. 4. Determination of risk levels and suitable mitigation strategies As part of the Protection Profile and Security Target authoring process, DTSec working group members, evaluators, and developers work together to ensure that functional requirements are carefully chosen to mitigate security threats while balancing overall safe clinical use. For example, it may be determined that a Bluetooth-connected diabetes device should use a simpler pairing scheme to meet clinical usability requirements and require documented physical security controls and user training to augment the pairing mechanism for an overall suitable security approach (as documented in the Security Target). 5. Assessment of residual risk and risk acceptance criteria DTSec conformity assessment determines whether risks are acceptable relative to the assurance requirements specified in the Security Target. For example, if a vulnerability exploit requires an attack potential higher than what is specified in the Security Target, the evaluator, working in close consultation with the product developer and potentially other stakeholders, must affirm whether the residual risk associated with this vulnerability is acceptable. Like the NIST cybersecurity framework, the DTSec standard does not provide a one-size-fits-all set of security requirements. The standard’s use of ISO 15408 Protection Profiles and Security Targets enable requirements to vary across device products, based on business drivers, threat models, information value under protection, safety criticality, human factors considerations, and other risk-relevant inputs.
The Way Forward We believe that a formal standard for specifying security requirements and program for assessing conformity to those requirements fills an important gap and essential need in the connected medical device industry, and that the lack of such a standard and program not only increases safety risk to patients but also increases overall cybersecurity program costs across the medical device industry, where current risk assessment programs are internalized, with little or no crossindustry sharing and economies of scale. DTSec can reduce cost by collecting, from a wide range of stakeholders, common threats, objectives, and requirements that can be rapidly understood and directly used by manufacturers and evaluators. Yet, the Security Target approach provides ample space to tailor family-based requirements to specific products that may have varying design, usability, and implementation
constraints. DTSec can also help reduce industry costs by leveraging a single conformity assessment across all health care device purchasers, owners, and payers rather than having each organization take on device security assessments to manage their risk. The benefits of a cybersecurity standard and costeffective conformity assessment program go beyond the product itself. With every publicized hack, consumers are becoming increasingly concerned with security of medical systems, and manufacturers can gain competitive advantage by providing confidence via DTSec. Consumers, clinicians, payers, and regulators will favor products with independently validated and standardized cybersecurity. Furthermore, we can expect increasing numbers of lawsuits related to cybersecurity failures. Potential losses motivate improved cybersecurity practices. In fact, many medical industry suppliers feel they already have sound cybersecurity and do not want independent conformity assessment that adds to development cost. Unfortunately, most hacks and data breaches happen to organizations (and their users) that prior to the incidents believed they had adequate cybersecurity. We feel the best way to protect our patients is to advocate for a standard that includes standardized security specification and independent conformity assessment. Adherence to independently assessed security also demonstrates due diligence that helps an organization respond to legal attacks. DTS believes that nondiabetes products would also benefit from the work of DTSec because the principles of applying a risk assessment approach to derive common security threats, objectives, and requirements and efficiently assess conformity to those requirements apply equally well to medical devices intended for other diseases. The first version of DTSec was posted for 45 days of public review. All comments will be addressed and revisions to the documents made where appropriate. The standard is scheduled to be released at the inaugural MEDSec meeting (The Internet of Medical Things) on May 23-24, 2016, in San Jose, California. We expect DTSec will become a valuable standard for all stakeholders in the field of connected medical devices. Abbreviations CC, Common Criteria; DTS, Diabetes Technology Society; DTSec, DTS Cybersecurity Standard for Connected Diabetes Devices project.
Declaration of Conflicting Interests The author(s) declared the following potential conflicts of interest with respect to the research, authorship, and/or publication of this article: DCK is a consultant for Bayer, Lifecare, and Voluntis. DNK is an employee of Blackberry.
Funding The author(s) received no financial support for the research, authorship, and/or publication of this article.
626 References 1. Centers for Disease Control and Prevention. Diabetes latest. Available at: http://www.cdc.gov/features/diabetesfactsheet/. Accessed April 8, 2016. 2. Menke A, Casagrande S, Geiss L, Cowie CC. Prevalence of and trends in diabetes among adults in the United States, 19882012. JAMA. 2015;314(10):1021-1029. 3. Franklin V. Influences on technology use and efficacy in type 1 diabetes [published online ahead of print March 27, 2016]. J Diabetes Sci Technol. 1932296816639315. 4. Klonoff DC. Cybersecurity for connected diabetes devices. J Diabetes Sci Technol. 2015;9(5):1143-1147. 5. DTSec DTS Cybersecurity Standard for Connected Diabetes Devices. Diabetes Technology Society. Available at: https://www. diabetestechnology.org/dtsec.shtml. Accessed April 8, 2016. 6. Department of Homeland Security. Fact Sheet: Executive Order (EO) 13636 Improving Critical Infrastructure Cybersecurity and Presidential Policy Directive (PPD)-21 Critical Infrastructure Security and Resilience. Available at: https://www.dhs.gov/ publication/fact-sheet-eo-13636-improving-critical-infrastructure-cybersecurity-and-ppd-21-critical. Accessed April 8, 2016.
Journal of Diabetes Science and Technology 10(3) 7. Common Criteria. Available at: https://www.commoncriteriaportal.org/. Accessed April 8, 2016. 8. National Institute of Standards and Technology. NIST Cybersecurity Framework. Available at: http://www.nist.gov/ cyberframework/. Accessed April 8, 2016. 9. US Food and Drug Administration. Content of premarket submissions for management of cybersecurity in medical devices. October 2, 2014. Available at: http://www.fda. gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190.pdf. Accessed April 8, 2016. 10. US Food and Drug Administration. Postmarket cybersecurity in medical devices. January 22, 2016. Available at: http:// www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf. Accessed April 8, 2016. 11. National Institute of Standards and Technology. Cybersecurity framework frequently asked questions. Number 32. Available at: http://www.nist.gov/cyberframework/cybersecurity-frameworkfaqs-using-the-framework.cfm#conformity. Accessed April 8, 2016.
editorial2016
DSTXXX10.1177/1932296816647516Journal of Diabetes Science and TechnologyKlonoff and Kleidermacher
Editorial
Now Is the Time for a Cybersecurity Standard for Connected Diabetes Devices
Journal of Diabetes Science and Technology 2016, Vol. 10(3) 623–626 © 2016 Diabetes Technology Society Reprints and permissions: sagepub.com/journalsPermissions.nav DOI: 10.1177/1932296816647516 dst.sagepub.com
David C. Klonoff, MD, FACP, FRCP (Edin), Fellow AIMBE1 and David N. Kleidermacher, BS2 Keywords diabetes, cybersecurity, device, standard, security
Executive Overview Diabetes is a worldwide epidemic. In the United States, almost 10% of the population has this disease1 and approximately half of adults have diabetes or prediabetes.2 People with diabetes make therapeutically significant decisions each day about the type and quantity of foods to eat and how much insulin to administer. Over the past two decades, these patients have benefitted from increasingly sophisticated technology to assess blood glucose levels on demand or automatically, recommend medication doses, and even dose on demand or automatically.3 Diabetes patients use four main types of connected devices to measure and react to their glucose data: blood glucose monitors, continuous glucose monitors, insulin pumps, and closedloop artificial pancreas systems.4 Early examples of these devices were not connected to the Internet or each other. Modern devices, however, often leverage computer-networking technology to improve ease of use and enable new treatment paradigms. For example, diabetes data may be transmitted to a smartphone or reader and sometimes to the cloud, enabling improved decision support recommendations and real time alarms for out of range physiology or behaviors. The definition of security is the protection of resources against threat of malicious attack against those resources. In the case of connected diabetes devices, these resources include the data and command information stored within and communicated (usually wirelessly) by devices as well as safe operation of the devices themselves. Threats against connected diabetes devices include unauthorized disclosure and modification of therapeutic data and forced loss of safe device function.
Introduction to DTSec In July 2015 the California-based nonprofit organization Diabetes Technology Society (DTS) launched DTSec (DTS Cybersecurity Standard for Connected Diabetes Devices project).5 A standard has been developed that provides the framework for specifying the security requirements for connected diabetes devices and how to obtain a requisite level of
independent assurance that the devices meet those requirements. Thus, the standard is intended for industry, clinicians, patients, payers, and regulators to assess whether there is adequate cybersecurity in any new or marketed connected diabetes device. This standard contributes to the realization of Presidential Executive Order 13636, which aims to increase the level of core capabilities for the US critical infrastructure in 16 critical sectors, including health care.6 Specifically, this standard contributes to a goal described in the Order, which is to leverage voluntary consensus standards and industry best practices and then build them into a cybersecurity framework. The DTSec working group includes a wide spectrum of stakeholders who use, prescribe, pay for, regulate, and manufacture diabetes devices. From the US government sector our steering committee has had representation from FDA, DHS, NIST, NIH, NASA, and USAF. The Canadian government has participated through Health Canada. Other steering committee members come from professional organizations (American Diabetes Association, Juvenile Diabetes Research Foundation, Endocrine Society, and American Association of Diabetes Educators), academia (medicine, nursing, engineering, mathematics, and law), industry (medical device manufacturers as well as component suppliers and independent cybersecurity experts), and the patient community, which is represented by both users and ethical hackers of these connected devices. To our knowledge such a broad and international coalition of stakeholders has not previously been assembled to develop a consensus cybersecurity standard for medical devices. DTSec leverages ISO 15408, also known as Common Criteria (CC), for specifying security threats, objectives, and 1
Diabetes Research Institute, Mills-Peninsula Health Services BlackBerry Limited, Pleasanton, CA, USA
2
Corresponding Author: David C. Klonoff, MD, FACP, FRCP (Edin), Fellow AIMBE, Diabetes Research Institute, Mills-Peninsula Health Services, 100 S San Mateo Dr, San Mateo, CA 94401 USA. Email: [email protected]
624 requirements for families of products and specific product instantiations.7 While national frameworks exist for specifying security requirements (eg, NIST SP 800-53 in the United States), the CC enjoys the broadest international acceptance for specifying such requirements. 26 nations recognize the CC as a unified approach to specify and evaluate electronic product security requirements. DTSec aims to offer a path to international connected medical device regulatory environments and markets. The CC employs 2 types of specifications: Protection Profile, which is a document-identifying common security requirement for a family of products, and Security Target, which is a document specifying security requirement for a particular marketable product. When the product is a member of a product family covered by a Protection Profile, the product’s Security Target is derived and tailored from the family Protection Profile. Both the Protection Profile and Security Target include two types of requirements: Security Functional Requirements, which define the relevant security controls for applicable products; and Security Assurance Requirements, which are measures used to assure conformance to the claimed security controls.
Relationship of DTSec to other Regulatory Guidance In the United States, several agencies have recently issued cybersecurity guidance, including NIST’s cybersecurity framework8 and FDA’s premarket9 and postmarket10 guidances for cybersecurity of medical devices. Both NIST and FDA guidelines follow a historical risk management approach to medical device quality and safety, wherein security threats are considered yet another risk to safety that must be assessed and managed by manufacturers and caregivers. NIST and FDA guidance are valuable for developers in helping to ensure they are properly considering cybersecurity risk throughout product lifecycles and their organizations. The NIST framework provides a catalog and categorization of typical cybersecurity activities and controls that should be considered by an enterprise. The catalog references existing security specification standards, such as NIST SP 800-53 and ISO 15408. However, neither NIST nor FDA guidance addresses how to map the universe of potential security requirements to specific medical devices. Furthermore, current guidance does not include programs for gaining confidence in a product, system, or organization’s conformity to these requirements via some form of conformity assessment. Therefore, independent stakeholders (eg, caregivers, users, payers) are generally unable to gain confidence in a vendor or product’s security capabilities from existing guidance alone. Even if a vendor self-affirms conformity to a set of risk-based security requirements and is willing to disclose supporting conformance evidence (such as test results and design documentation), claims are unlikely
Journal of Diabetes Science and Technology 10(3) to yield significant independent assurance if not vetted by independent, unbiased cybersecurity evaluation experts following a common evaluation methodology. As stated in the current NIST Cybersecurity framework FAQs: “NIST has no plans to develop a conformity assessment program. NIST encourages the private sector to determine its conformity needs, and then develop appropriate conformity assessment programs.”11 DTSec aims to provide the connected medical device sector with an efficient, standardized approach to provide, through conformity assessment, confidence that the medical device is able to protect itself against applicable security threats.
How DTSec Maps to FDA Guidance As an example of how DTSec may fit into a nation’s medical device regulatory guidance, consider recent FDA premarket guidance.9 The “General Principles” section within this guidance document lists five elements of a vulnerability and management approach. For each element, we explain here how DTSec helps manufacturers implement the FDA guidance: 1. Identification of assets, threats, and vulnerabilities DTSec helps developers identify and document, using ISO 15408 standard methodology, device-specific assets, and threats. The DTSec conformity assessment program helps identify vulnerabilities. 2. Assessment of the impact of threats and vulnerabilities on device functionality and end users/patients DTSec helps to assess the impact of threats and vulnerabilities on device functionality and end users/patients by requiring developers to consider relevant threats and how they might impact safe clinical use. For example, if a diabetic patient makes clinical decisions based on the readings from a glucose monitor, the developer must consider how threats borne over its wireless connection could potentially corrupt the integrity of these readings, leading to unsafe clinical decisions. This assessment leads to the inclusion of appropriate mitigating controls (security functional requirements) in the Security Target specification. DTSec conformity assessments also help assess the impact of discovered vulnerabilities. 3. Assessment of the likelihood of a threat and of a vulnerability being exploited During DTSec conformity assessment, the security evaluator will attempt to understand not only whether a vulnerability is exploitable but also what level of attack potential is required to exploit. This helps developers assess the probability of a threat converting to active exploit based on this potential.
625
Klonoff and Kleidermacher For example, a low potential exploit is likely to have a higher probability of exploit in practice than a high potential exploit beyond the technical and economic reach of most attackers. 4. Determination of risk levels and suitable mitigation strategies As part of the Protection Profile and Security Target authoring process, DTSec working group members, evaluators, and developers work together to ensure that functional requirements are carefully chosen to mitigate security threats while balancing overall safe clinical use. For example, it may be determined that a Bluetooth-connected diabetes device should use a simpler pairing scheme to meet clinical usability requirements and require documented physical security controls and user training to augment the pairing mechanism for an overall suitable security approach (as documented in the Security Target). 5. Assessment of residual risk and risk acceptance criteria DTSec conformity assessment determines whether risks are acceptable relative to the assurance requirements specified in the Security Target. For example, if a vulnerability exploit requires an attack potential higher than what is specified in the Security Target, the evaluator, working in close consultation with the product developer and potentially other stakeholders, must affirm whether the residual risk associated with this vulnerability is acceptable. Like the NIST cybersecurity framework, the DTSec standard does not provide a one-size-fits-all set of security requirements. The standard’s use of ISO 15408 Protection Profiles and Security Targets enable requirements to vary across device products, based on business drivers, threat models, information value under protection, safety criticality, human factors considerations, and other risk-relevant inputs.
The Way Forward We believe that a formal standard for specifying security requirements and program for assessing conformity to those requirements fills an important gap and essential need in the connected medical device industry, and that the lack of such a standard and program not only increases safety risk to patients but also increases overall cybersecurity program costs across the medical device industry, where current risk assessment programs are internalized, with little or no crossindustry sharing and economies of scale. DTSec can reduce cost by collecting, from a wide range of stakeholders, common threats, objectives, and requirements that can be rapidly understood and directly used by manufacturers and evaluators. Yet, the Security Target approach provides ample space to tailor family-based requirements to specific products that may have varying design, usability, and implementation
constraints. DTSec can also help reduce industry costs by leveraging a single conformity assessment across all health care device purchasers, owners, and payers rather than having each organization take on device security assessments to manage their risk. The benefits of a cybersecurity standard and costeffective conformity assessment program go beyond the product itself. With every publicized hack, consumers are becoming increasingly concerned with security of medical systems, and manufacturers can gain competitive advantage by providing confidence via DTSec. Consumers, clinicians, payers, and regulators will favor products with independently validated and standardized cybersecurity. Furthermore, we can expect increasing numbers of lawsuits related to cybersecurity failures. Potential losses motivate improved cybersecurity practices. In fact, many medical industry suppliers feel they already have sound cybersecurity and do not want independent conformity assessment that adds to development cost. Unfortunately, most hacks and data breaches happen to organizations (and their users) that prior to the incidents believed they had adequate cybersecurity. We feel the best way to protect our patients is to advocate for a standard that includes standardized security specification and independent conformity assessment. Adherence to independently assessed security also demonstrates due diligence that helps an organization respond to legal attacks. DTS believes that nondiabetes products would also benefit from the work of DTSec because the principles of applying a risk assessment approach to derive common security threats, objectives, and requirements and efficiently assess conformity to those requirements apply equally well to medical devices intended for other diseases. The first version of DTSec was posted for 45 days of public review. All comments will be addressed and revisions to the documents made where appropriate. The standard is scheduled to be released at the inaugural MEDSec meeting (The Internet of Medical Things) on May 23-24, 2016, in San Jose, California. We expect DTSec will become a valuable standard for all stakeholders in the field of connected medical devices. Abbreviations CC, Common Criteria; DTS, Diabetes Technology Society; DTSec, DTS Cybersecurity Standard for Connected Diabetes Devices project.
Declaration of Conflicting Interests The author(s) declared the following potential conflicts of interest with respect to the research, authorship, and/or publication of this article: DCK is a consultant for Bayer, Lifecare, and Voluntis. DNK is an employee of Blackberry.
Funding The author(s) received no financial support for the research, authorship, and/or publication of this article.
626 References 1. Centers for Disease Control and Prevention. Diabetes latest. Available at: http://www.cdc.gov/features/diabetesfactsheet/. Accessed April 8, 2016. 2. Menke A, Casagrande S, Geiss L, Cowie CC. Prevalence of and trends in diabetes among adults in the United States, 19882012. JAMA. 2015;314(10):1021-1029. 3. Franklin V. Influences on technology use and efficacy in type 1 diabetes [published online ahead of print March 27, 2016]. J Diabetes Sci Technol. 1932296816639315. 4. Klonoff DC. Cybersecurity for connected diabetes devices. J Diabetes Sci Technol. 2015;9(5):1143-1147. 5. DTSec DTS Cybersecurity Standard for Connected Diabetes Devices. Diabetes Technology Society. Available at: https://www. diabetestechnology.org/dtsec.shtml. Accessed April 8, 2016. 6. Department of Homeland Security. Fact Sheet: Executive Order (EO) 13636 Improving Critical Infrastructure Cybersecurity and Presidential Policy Directive (PPD)-21 Critical Infrastructure Security and Resilience. Available at: https://www.dhs.gov/ publication/fact-sheet-eo-13636-improving-critical-infrastructure-cybersecurity-and-ppd-21-critical. Accessed April 8, 2016.
Journal of Diabetes Science and Technology 10(3) 7. Common Criteria. Available at: https://www.commoncriteriaportal.org/. Accessed April 8, 2016. 8. National Institute of Standards and Technology. NIST Cybersecurity Framework. Available at: http://www.nist.gov/ cyberframework/. Accessed April 8, 2016. 9. US Food and Drug Administration. Content of premarket submissions for management of cybersecurity in medical devices. October 2, 2014. Available at: http://www.fda. gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190.pdf. Accessed April 8, 2016. 10. US Food and Drug Administration. Postmarket cybersecurity in medical devices. January 22, 2016. Available at: http:// www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm482022.pdf. Accessed April 8, 2016. 11. National Institute of Standards and Technology. Cybersecurity framework frequently asked questions. Number 32. Available at: http://www.nist.gov/cyberframework/cybersecurity-frameworkfaqs-using-the-framework.cfm#conformity. Accessed April 8, 2016.
