« ロシアと北朝鮮のハッカーがCOVID 19のワク​​チン研究者からデータを盗もうとしている by Microsoft | Main | NIST SP 800-181 Rev. 1 Workforce Framework for Cybersecurity (NICE Framework) »

2020.11.17

NIST パブコメ SP 1800-30 (Draft) Securing Telehealth Remote Patient Monitoring Ecosystem 遠隔患者監視エコシステムのセキュリティ確保

こんにちは、丸山満彦です。

NIST が遠隔患者監視エコシステムのセキュリティ確保に関するガイドラインとして、SP 1800-30 (Draft) Securing Telehealth Remote Patient Monitoring Ecosystem を公開し、意見を募集していますね・・・

日本でも遠隔医療等の導入の検討も進んでいますが、参考になると思います。全てを遠隔でするわけにはいかないですが、病院までの交通の便や通院による感染リスクを考えた場合、選択肢として必要なんでしょうね。。。

● NIST - ITL

・2020.11.16 SP 1800-30 (Draft) Securing Telehealth Remote Patient Monitoring Ecosystem

Draft SP 1800-30 volumes and Project homepage

  • [PDF] SP 1800-30A-C
  • [PDF] SP 1800-30A: Executive Summary 
  • [PDF] SP 1800-30B: Approach, Architecture, and Security Characteristics 
  • [PDF] SP 1800-30C: How-To Guides 

 


目次

1 Summary
1.1 Challenge
1.2 Solution
1.3 Benefits

2 How to Use This Guide
2.1 Typographic Conventions

3 Approach
3.1 Audience
3.2 Scope
3.3 Assumptions
3.4 Risk Assessment
 3.4.1 Threats
 3.4.2 Vulnerabilities
 3.4.3 Problematic Data Actions for Privacy
 3.4.4 Risk
 3.4.5 Mitigating Risk
3.5 Security Control Map
3.6 Technologies

4 Architecture
4.1 Layering the Architecture
4.2 High-Level Architecture Communications Pathwaysp
4.2.1 Cellular Data Pathways
4.2.2 Broadband Pathways
4.3 Data and Process Flows
4.4 Security Capabilities
 4.4.1 Telehealth Platform Provider
 4.4.2 Risk Assessment Controls
 4.4.3 Identity Management, Authentication, and Access Control
 4.4.4 Data Security
 4.4.5 Anomalies and Events and Security Continuous Monitoring
4.5 Final Architecture

5 Security and Privacy Characteristic Analysis
5.1 Assumptions and Limitations
5.2 Pervasive Controls
5.3 Telehealth Platform Providers
5.4 Risk Assessment (ID.RA and ID.RA-P)
5.5 Identity Management, Authentication, and Access Control (PR.AC and PR.AC-P) Protective Technology (PR.PT-P)
5.6 Data Security (PR.DS and PR.DS-P)
5.7 Anomalies and Events, Security Continuous Monitoring (DE.AE, DE.CM) and Data Processing Management (CT.DM-P)

6 Functional Evaluation
6.1 RPM Functional Test Plan
 6.1.1 RPM Functional Evaluation
 6.1.2 Test Case: RPM-1
 6.1.3 Test Case: RPM-2
 6.1.4 Test Case: RPM-3
 6.1.5 Test Case: RPM-4
 6.1.6 Test Case: RPM-5
 6.1.7 Test Case: RPM-6
 6.1.8 Test Case: RPM-7
 6.1.9 Test Case: RPM-8
 6.1.10 Test Case: RPM-9

7 Future Build Considerations

Appendix A List of Acronyms

Appendix B References

Appendix C Threats and Risks
C-1 Discussion on the Risk Management Framework
C-2 Information and Information System Categorization
C-3 Risk Context
C-4 Threats
C-5 Threat Sources
C-5.1 Business Processes
C-6 Vulnerabilities
C-7 Threat Modeling
 C-7.1 Modeling Threats to the Patient Home
 C-7.2 Linking Threats to Adverse Actions

Appendix D Problematic Data Actions and Risks
D-1 Privacy Risk Assessment Methodology (PRAM)
D-2 Problematic Data Actions and Mitigations
 D-2.1 Privacy Risk 1: Unauthorized individuals may access data on devices 
 D-2.2 Privacy Risk 2: Biometric device types can indicate patient health problems that individuals would prefer not to disclose beyond their healthcare provider
 D-2.3 Privacy Risk 3: Incorrect data capture of readings by devices may impact quality of patient care 
 D-2.4 Privacy Risk 4: Aggregated data may expose patient information
 D-2.5 Privacy Risk 5: Exposure of patient information through multiple providers of system components
D-3 Mitigations Applicable Across Various Data Actions

Appendix E Future Consideration: Applying Micro169 Segmentation Solutions for RPM Solutions


 


Announcement

Increasingly, healthcare delivery organizations (HDOs) are relying on telehealth and remote patient monitoring (RPM) capabilities to treat patients at home. RPM is convenient, cost effective, and its adoption rate has increased. Without adequate privacy and cybersecurity measures, unauthorized individuals may expose sensitive data or disrupt patient monitoring services.

The NCCoE at NIST analyzed risk factors surrounding the RPM ecosystem and leveraged the NIST Cybersecurity Framework and other relevant guidance to develop an example implementation that demonstrates how HDOs can use standards-based, commercially available cybersecurity technologies to implement cybersecurity and privacy controls to enhance telehealth RPM resiliency.

The comment period is open through December 18, 2020. Comments will be made public.


Abstract

Increasingly, healthcare delivery organizations (HDOs) are relying on telehealth and remote patient monitoring (RPM) capabilities to treat patients at home. RPM is convenient and cost-effective, and its adoption rate has increased. However, without adequate privacy and cybersecurity measures, unauthorized individuals may expose sensitive data or disrupt patient monitoring services.

RPM solutions engage multiple actors as participants in a patient’s clinical care. These actors include HDOs, telehealth platform providers, and the patients themselves. Each participant uses, manages, and maintains different technology components within an interconnected ecosystem, and each is responsible for safeguarding their piece against unique threats and risks associated with RPM 60 technologies.

This practice guide assumes that the HDO engages with a telehealth platform provider that is a separate entity from the HDO and patient. The telehealth platform provider manages a distinct infrastructure, applications, and set of services. The telehealth platform provider coordinates with the HDO to provision, configure, and deploy the RPM components to the patient home and assures secure communication between the patient and clinician.

The NCCoE analyzed risk factors regarding an RPM ecosystem by using risk assessment based on the NIST Risk Management Framework. The NCCoE also leveraged the NIST Cybersecurity Framework, NIST Privacy Framework, and other relevant standards to identify measures to safeguard the ecosystem. In collaboration with healthcare, technology, and telehealth partners, the NCCoE built an RPM ecosystem in a laboratory environment to explore methods to improve the cybersecurity of an RPM.

Technology solutions alone may not be sufficient to maintain privacy and security controls on external environments. This practice guide notes the application of people, process, and technology as necessary to implement a holistic risk mitigation strategy.

This practice guide’s capabilities include helping organizations assure the confidentiality, integrity, and availability of an RPM solution, enhancing patient privacy, and limiting HDO risk when implementing an RPM solution.


1 Summary

This practice guide demonstrates how healthcare delivery organizations (HDOs) can implement cybersecurity and privacy controls to enhance the resiliency of telehealth services. In collaboration with industry partners, the National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) built a laboratory environment to simulate the telehealth ecosystem and enable remote patient monitoring (RPM) services for patients.

RPM is convenient, cost-effective, and growing, but it comes with security and privacy risks. Patient monitoring systems are often found in healthcare facilities, in controlled environments. RPM is different in that monitoring equipment is deployed in the patient’s home, which may not offer the same level of cybersecurity or physical-security control to prevent misuse or compromise. Without privacy or cybersecurity controls in place within the RPM ecosystem, patient data and the ability to communicate with the care providers may be compromised.

This practice guide explores a situation in which a care provider prescribes deploying an RPM device to the patient home. The RPM device captures biometric data on regular intervals, conveys the data to the clinical care team and allows patient-clinician communication without the patient making an in-person visit to the HDO. RPM enables care based on the patient’s needs, regardless of geographic constraints.

Capturing biometric data at regular intervals allow clinicians to have broader insight into a patient’s condition. With larger data sets, clinicians can monitor the patient’s condition and make diagnosis and treatment decisions with more robust information. RPM solutions allow audio and video communication in addition to utilizing biometric data and supports the patient-clinician relationship.

Implementing an RPM ecosystem involves multiple parties and environments. In developing the reference architecture for this practice guide, the NCCoE considered components that would be deployed in three distinct domains that encompass the RPM ecosystem: the patient home environment, the telehealth platform provider, and the HDO. The practice guide engaged with a telehealth platform provider that leveraged cloud services and facilitated audio- and videoconferencing between the patient home and the HDO. The telehealth platform provider provisioned and managed biometric devices that were deployed in the patient home, and routed data and communication between the patient home and the HDO.

The NCCoE built a laboratory environment to simulate the telehealth ecosystem, performed a risk assessment, and developed an example implementation that demonstrates how HDOs can use standards-based, commercially available cybersecurity technologies and collaborate with telehealth platform providers to assure privacy and security biometric devices that are deployed to the patient home.

For ease of use, the following paragraphs provide a short description of each section of this volume.

Section 1, Summary, presents the challenge addressed by the NCCoE project, with an in-depth look at our approach, the architecture, and the security characteristics we used; the solution demonstrated to  address the challenge; benefits of the solution; and the collaborators who participated in building, demonstrating, and documenting the solution.

Section 2, How to Use This Guide, explains how business decision makers, program managers, information technology (IT) professionals (e.g., systems administrators), and biometric engineers might use each volume of the guide.

Section 3, Approach, offers a detailed treatment of the scope of the project, the risk assessment that informed platform development, and the technologies and components that industry collaborators gave us to enable platform development.

Section 4, Architecture, specifies the components within the RPM ecosystem from business, security, and infrastructure perspectives and details how data and processes flow throughout the ecosystem. This section also describes the security capabilities and controls referenced in the NIST Cybersecurity Framework through tools provided by the project collaborators.

Section 5, Security and Privacy Characteristic Analysis, provides details about the tools and techniques used to perform risk assessments pertaining to RPM.

Section 6, Functional Evaluation, summarizes the test sequences employed to demonstrate security platform services, the NIST Cybersecurity Framework Functions to which each test sequence is relevant, and the NIST Special Publication (SP) 800-53 Revision 4 controls demonstrated in the example implementation.

Section 7, Future Build Considerations, is a brief treatment of other applications that NIST might explore in the future to further protect a telehealth environment.

The appendixes provide acronym translations, references, a deeper dive into the threats and risks associated with RPM, the review of the NIST Privacy Risk Assessment Methodology (PRAM), and a list of additional informative security references cited in the framework. Acronyms used in figures and tables are in the List of Acronyms appendix.


 

 

|

« ロシアと北朝鮮のハッカーがCOVID 19のワク​​チン研究者からデータを盗もうとしている by Microsoft | Main | NIST SP 800-181 Rev. 1 Workforce Framework for Cybersecurity (NICE Framework) »

Comments

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



« ロシアと北朝鮮のハッカーがCOVID 19のワク​​チン研究者からデータを盗もうとしている by Microsoft | Main | NIST SP 800-181 Rev. 1 Workforce Framework for Cybersecurity (NICE Framework) »