Appendix A List of Acronyms¶
AD |
Active Directory |
AES |
Advanced Encryption Standard |
AI |
Artificial Intelligence |
AMP |
Advanced Malware Protection |
CIA |
Confidentiality, Integrity, and Availability |
COI |
Community of Interest |
CTI |
Cyber Threat Intelligence |
DC |
Domain Controller |
DHCP |
Dynamic Host Configuration Protocol |
DNS |
Domain Name System |
EHR |
Electronic Health Record |
FTD |
Firepower Threat Defense |
HDO |
Healthcare Delivery Organization |
HIPAA |
Health Insurance Portability and Accountability Act |
HIS |
Health Information System |
HTTP |
Hypertext Transfer Protocol |
IEC |
International Electrotechnical Commission |
IIS |
Internet Information Services |
IP |
Internet Protocol |
ISO |
International Organization for Standardization |
IT |
Information Technology |
IoT |
Internet of Things |
LAN |
Local Area Network |
LTE |
Long-Term Evolution |
MAC |
Media Access Control |
NCCoE |
National Cybersecurity Center of Excellence |
NFC |
Near Field Communication |
NICE |
National Initiative for Cybersecurity Education |
NIST |
National Institute of Standards and Technology |
OS |
Operating System |
OSI |
Open Systems Interconnection |
PACS |
Picture Archiving and Communication System |
PAN |
Personal Area Network |
PRAM |
Privacy Risk Assessment Methodology |
RMF |
Risk Management Framework |
RPM |
Remote Patient Monitoring |
SaaS |
Software as a Service |
SC |
Security Categorization |
SD |
Secure Digital |
SIEM |
Security Incident and Event Management |
SIM |
Subscriber Identity Module |
SMC |
Stealthwatch Management Console |
SP |
Special Publication |
TLS |
Transport Layer Security |
URL |
Uniform Resource Locator |
USB |
Universal Serial Bus |
VLAN |
Virtual Local Area Network |
ZTA |
Zero Trust Architecture |
Appendix B References¶
- B1
R. Ross et al., Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171 Revision 2, NIST, Gaithersburg, Md., Feb. 2020. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf.
- B2
R. Petersen et al., Workforce Framework for Cybersecurity (NICE Framework), NIST SP 800-181 Revision 1, NIST, Gaithersburg, Md., Nov. 2020. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-181r1.pdf.
- B3
Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1 (NIST Cybersecurity Framework), NIST, Gaithersburg, Md., Apr. 16, 2018. Available: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf.
- B4
NIST. Risk Management Framework: Quick Start Guides. Available: https://csrc.nist.gov/projects/risk-management/risk-management-framework-quick-start-guides.
- B5(1,2)
NIST. NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0 (Privacy Framework). Jan. 16, 2020. Available: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf.
- B6
NIST. Computer Security Resource Center. Available: https://csrc.nist.gov/glossary/term/confidentiality_integrity_availability.
- B7
NIST. NIST Privacy Risk Assessment Methodology (PRAM). Jan. 16, 2020. Available: https://www.nist.gov/privacy-framework/nist-pram.
- B8
NIST. Privacy Engineering Program: Privacy Risk Assessment Methodology (PRAM), Catalog of Problematic Data Actions and Problems. Available: https://www.nist.gov/itl/applied-cybersecurity/privacy-engineering/resources.
- B9(1,2,3,4)
Joint Task Force Transformation Initiative, Guide for Conducting Risk Assessments, NIST SP 800-30 Revision 1, NIST, Gaithersburg, Md., Sept. 2012. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf.
- B10
Joint Task Force, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53 Revision 5, NIST, Gaithersburg, Md., Sept. 2020. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf.
- B11
Application of risk management for IT networks incorporating medical devices–Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and controls, International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) Technical Report (TR) 80001-2-2, Edition 1.0 2012-07, International Electrotechnical Commission.
- B12
U.S. Department of Health and Human Services Office for Civil Rights, HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework, Feb. 2016. Available: https://www.hhs.gov/sites/default/files/nist-csf-to-hipaa-security-rule-crosswalk-02-22-2016-final.pdf.
- B13
ISO/IEC, Information technology–Security techniques–Information security management systems–Requirements, ISO/IEC 27001:2013, 2013.
- B14
J. Cawthra et al., Securing Picture Archiving and Communication System (PACS) Project Description, NIST, Gaithersburg, Md., Jan. 2018. Available: https://www.nccoe.nist.gov/sites/default/files/library/project-descriptions/hit-pacs-project-description-final.pdf.
- B15
NIST. NIST Privacy Framework, NIST Privacy Framework and Cybersecurity Framework to NIST Special Publication 800-53, Revision 5 Crosswalk, Dec. 2020. Available: https://www.nist.gov/privacy-framework/nist-privacy-framework-and-cybersecurity-framework-nist-special-publication-800-53.
- B16
World Health Organization. Health Topics. Diabetes. Available: https://www.who.int/health-topics/diabetes#tab=tab_1.
- B17
P. Lee et al., The impact of telehealth remote patient monitoring on glycemic control in type 2 diabetes: a systematic review and meta-analysis of systematic reviews of randomised controlled trials, U.S. National Library of Medicine, National Institutes of Health. Available: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6019730/.
- B18
U.S. National Library of Medicine. Cardiac Rehabilitation. Available: https://medlineplus.gov/cardiacrehabilitation.html#summary.
- B19
U.S. National Library of Medicine. Pulmonary Rehabilitation. Available: https://medlineplus.gov/pulmonaryrehabilitation.html.
- B20
G. O’Brien et al., Securing Wireless Infusion Pumps in Healthcare Delivery Organizations, NIST SP 1800-8, NIST, Gaithersburg, Md., Aug. 2018. Available: https://www.nccoe.nist.gov/sites/default/files/library/sp1800/hit-wip-nist-sp1800-8.pdf.
- B21
M. Fagan et al., IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, NIST SP 800-213, NIST, Gaithersburg, Md., Nov. 2021. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-213.pdf.
- B22(1,2)
S. Rose et al., Zero Trust Architecture, NIST SP 800-207, NIST, Gaithersburg, Md., Aug. 2020. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf.
- B23
C. Johnson et al., Guide to Cyber Threat Information Sharing, NIST SP 800-150, NIST, Gaithersburg, Md., Oct. 2016. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-150.pdf.
- B24
K. Dempsey et al., Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, Information Security, NIST SP 800-137, NIST, Gaithersburg, Md., Sept. 2011. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf.
- B25(1,2,3,4)
J. Cichonski et al., Guide to LTE Security, NIST SP 800-187, NIST, Gaithersburg, Md., Dec. 2017. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-187.pdf.
- B26
K. McKay and D. Cooper, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, NIST SP 800-52 Revision 2, NIST, Gaithersburg, Md., Aug. 2019. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf.
- B27
E. Barker, Recommendation for Key Management: Part 1–General, NIST SP 800-57 Part 1 Revision 5, NIST, Gaithersburg, Md., May 2020. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf.
- B28
U.S. Department of Commerce, Advanced Encryption Standard (AES), NIST Federal Information Processing Standards (FIPS) Publication 197, Nov. 26, 2001. Available: https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-197.pdf.
- B29(1,2,3)
U.S. Department of Commerce, Standards for Security Categorization of Federal Information and Information Systems, NIST Federal Information Processing Standards Publication 199, Feb. 2004. Available: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf.
- B30(1,2)
K. Stine et al., Guide for Mapping Types of Information and Information Systems to Security Categories Volume I, NIST SP 800-60 Volume I Revision 1, NIST, Gaithersburg, Md., Aug. 2008. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v1r1.pdf.
- B31(1,2,3,4)
K. Stine et al., Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories Volume II, NIST SP 800-60 Volume II Revision 1, NIST, Gaithersburg, Md., Aug. 2008. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-60v2r1.pdf.
- B32
U.S. Department of Commerce, Minimum Security Requirements for Federal Information and Information Systems, NIST Federal Information Processing Standards Publication 200, Mar. 2006. Available: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf.
- B33
S. Quinn et al., National Checklist Program for IT Products–Guidelines for Checklist Users and Developers, NIST SP 800-70 Revision 4, NIST, Gaithersburg, Md., Feb. 2018. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-70r4.pdf.
- B34(1,2)
Joint Task Force Transformation Initiative, Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans, NIST SP 800-53A Revision 4, NIST, Gaithersburg, Md., Dec. 2014. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
- B35(1,2)
Joint Task Force, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, NIST SP 800-37 Revision 2, NIST, Gaithersburg, Md., Dec. 2018. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r2.pdf.
- B36
S. Brooks et al., An Introduction to Privacy Engineering and Risk Management in Federal Systems, NIST Internal Report 8062, NIST, Gaithersburg, Md., Jan. 2017. Available: https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.
- B37(1,2,3)
J. Padgette et al., Guide to Bluetooth Security, NIST SP 800-121 Revision 2, NIST, Gaithersburg, Md., May 2017. Available: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf.
- B38
NIST Cybersecurity for IoT Program, Feb. 2021. Available: https://www.nist.gov/programs-projects/nist-cybersecurity-iot-program.
- B39
International Organization for Standardization/International Electrotechnical Commission, Information technology–Open Systems Interconnection–Basic Reference Model: The Basic Model, ISO/IEC 7498-1, 1994.
Appendix C Threats and Risks¶
Organizations need to understand risks associated with systems they deploy. The National Institute of Standards and Technology (NIST) provides two bodies of work that enable organizations to examine risk and determine how risks may be mitigated. The National Cybersecurity Center of Excellence (NCCoE) uses the NIST Cybersecurity Framework as guidance for managing risks in healthcare technology. Dovetailing with the Cybersecurity Framework is the NIST Risk Management Framework (RMF). This appendix discusses how the Cybersecurity Framework and the RMF may be applied when managing risks for the remote patient monitoring (RPM) environment.
C-1 Discussion on the Risk Management Framework¶
This practice guide implements concepts in the NIST RMF [B4]. The NIST RMF consists of a series of documents that may be applied in categorizing systems, selecting controls, assessing controls, and monitoring the security state of the overall architecture. The RMF captures this concept by describing a six-step process.
The RMF security life cycle can be described as follows:
Step |
Description |
Guidance Document(s) |
---|---|---|
1 |
categorize |
Federal Information Processing Standards (FIPS) 199 [B29]; NIST Special Publication (SP) 800-60 [B30], [B31] |
2 |
select |
|
3 |
implement |
NIST SP 800-70 [B33] |
4 |
assess |
NIST SP 800-53A [B34] |
5 |
authorize |
NIST SP 800-37 [B35] |
6 |
monitor |
Figure C-1 Risk Management Framework [C35]
Note that this practice guide does not apply the RMF sequentially as described. The NIST RMF, in this stepped approach, applies to new systems as they are evaluated for their suitability to transition from development to production environments. For this RPM practice guide, components are already developed. The approach that the project team uses in applying the RMF is first categorizing the system, then assessing risk and understanding threats that may result in risk. The team then selects controls to disrupt threats.
C-2 Information and Information System Categorization¶
An initial step in performing a system risk assessment and then selecting and applying appropriate controls is to perform an information and information system categorization exercise. A method to categorize is described in NIST SP 800-60 Volumes I and II [B30] [B31], as well as in FIPS 199 [B29]. These documents are a foundational step in the NIST Risk Management Framework. The NIST SP 800-60 volumes provide guidance on identifying information categories and provide recommended categorization, based on confidentiality (C), integrity (I), and availability (A) security objectives.
In reviewing information types described in NIST SP 800-60 Volume II [B31], the engineers selected two information types as relevant for the representative build: C.2.8.9, personal identity and authentication; and D.14.1, access to care. The two information types were recorded in Table C-1, Information Types and Categorizations, and provisional impact levels were captured, with the category levels corresponding to the recommended value found in NIST SP 800-60 Volume II [B31].
Table C-1 Information Types and Categorizations
Information Type |
NIST SP 800-60 Volume II Refernce (e.g., C.2.8.9) |
Confidentiality |
Integrity |
Availability |
Justification (to change an impact level) |
---|---|---|---|---|---|
personal identity and authentication |
C.2.8.9 |
moderate |
moderate |
moderate |
N/A |
access to care |
D.14.1 |
low |
moderate |
low |
N/A |
Overall Rating |
moderate |
moderate |
moderate |
N/A |
After identifying the information categories, one may determine the security objectives. Security objectives use a scale of low, medium, and high. FIPS 199 provides guidance in applying security categorization (SC). This practice guide identifies two information types: personal identity and authentication, as well as access to care. RPMʼs SC may be expressed as {(confidentiality, MODERATE), (integrity, MODERATE), (availability, MODERATE)} [B29]. The SC provides a base guide for security controls selection.
C-3 Risk Context¶
This practice guide describes risk from a systemic perspective while contextualizing risk. The RPM system for this practice guide consists of three domains. For this document, a domain is a group of assets whose maintenance and underlying infrastructure are the responsibility of discrete entities. In RPM, this practice guide implements a reference architecture that uses the patient home, the telehealth platform provider, and the healthcare delivery organization (HDO) as domains.
Because each domain is managed and used by different entities, risks and threats may manifest differently in each domain. While HDOs and telehealth platform providers are corporate entities that are subject to regulatory obligations, the patient home tends to be managed by individuals. For RPM, HDOs and telehealth platform providers should provide guidance to patients in safeguarding their systems and information. Controls may be implemented on provisioned devices managed by HDOs or telehealth platform providers; however, other controls may need to be addressed through education and awareness.
Despite how controls may be implemented, this practice guide examines the contextualized risks and threats and describes how the NCCoE implemented mitigating controls. Organizations that implement RPM practices should ensure that they apply due diligence by examining their own risk scenarios, including legal and regulatory obligations that may apply to their locale. Risks and threats should be analyzed based on their context. This practice guide applies contextualized controls to disrupt threats as its strategy to mitigate risk.
C-4 Threats¶
In this practice guide, the NCCoE identified a threat taxonomy for the entire system. Threats may manifest differently to the system depending on the domain in which they appear. Environments that may have resources to maintain security tools and procedures may have mitigating circumstances that reduce the likelihood of attack and minimize impact based on pervasive controls. This practice guide considers scenarios where patient homes may have less resource and capability to minimize threats when compared with telehealth platform providers and HDOs. Also, for the purposes of this practice guide, some threats may target HDOs to a greater extent than patient homes or telehealth platform providers, given a more target-rich data set that may attract threat actors.
The following tables describe events and consider the likelihood of variation based on this context. Note that the assigned values are notional. Practitioners who perform similar exercises may determine different assignments. For purposes of this exercise, likelihood is categorized using a range that extends from very low to very high, consistent with a model described in Appendix G of NIST 800-30 [B9]. An abstract of the table appears below. The qualitative values from the Table C-2 describes threat likelihood.
Table C-2 Assessment Scale: Likelihood of Threat Event Initiation
Qualitative Values |
Frequency (derived from nonadversarial table) |
Description (derived from adversarial table) |
---|---|---|
very high |
Error, accident, or act of nature is almost certain to occur or occurs more than 100 times per year. |
Adversary is almost certain to initiate the threat event. |
high |
Error, accident, or act of nature is highly likely to occur or occurs 10-100 times per year. |
Adversary is highly likely to initiate the threat event. |
moderate |
Error, accident, or act of nature is somewhat likely to occur or occurs 1-10 times per year. |
Adversary is somewhat likely to initiate the threat event. |
low |
Error, accident, or act of nature is unlikely to occur or occurs less than once a year but more than every ten years. |
Adversary is unlikely to initiate the threat event. |
very low |
Error, accident, or act of nature is highly unlikely to occur or occurs less than once every ten years. |
Adversary is highly unlikely to initiate the threat event. |
The patient home may include technology and network infrastructure that offer malicious actors the opportunity to introduce disruption. Patients and individuals in the patient home come from different walks of life and may have varying degrees of experience in ensuring that privacy and cybersecurity are appropriately implemented for the devices that they may use. Malicious actors may opportunistically leverage a lack of robust controls in the patient home. While the patient home environment may have limited data to exfiltrate and data that pertain to a few individuals, the ability to compromise a patient home environment may pose fewer challenges than better resourced companies and hospital systems.
Table C-3 Threats Applied to the Patient Home
C, I, A |
Threat Event |
Description |
Likelihood |
---|---|---|---|
C |
phishing |
Patients and individuals in the patient home may be susceptible to phishing attempts. |
high |
I, A |
malicious software |
Patients and individuals in the patient home may be susceptible to permitting or introducing malicious software into the patient home environment. |
moderate |
I, A |
command and control |
Patients and individuals in the patient home may be susceptible to enabling malware that gives threat actors the ability to exercise command and control on devices. |
moderate |
A |
ransomware |
Ransomware may be introduced into the patient home environment either as links or attachments found in phishing emails or may be introduced through local media. |
moderate |
C |
credential escalation |
Malware may be introduced to the patient home environment that allows threat actors to execute arbitrary code and perform privileged functions. |
low |
I, A |
operating system (OS) or application disruption |
Malware may be introduced into the patient home environment that disrupts the operating system or applications. Libraries or subsystems may be affected. |
moderate |
C |
data exfiltration |
Sensitive data may be exposed to unauthorized individuals, e.g., via social engineering disclosure or malware that allows threat actors to retrieve data arbitrarily. Malware may be used for this purpose. |
moderate |
Using the same threat matrix, an examination is made of the telehealth platform provider. In general, the threat table considers when threat actors target workforce members who may have privileged access. The assumption is that telehealth platform providers may implement pervasive controls and have privacy and cybersecurity resources deployed that mitigate likelihood. The caveat in these assumptions is that HDOs that engage with telehealth platform providers should be provided assurance that third parties that they engage deploy mature privacy and cybersecurity programs.
Table C-4 Threats Applied to the Telehealth Platform Provider
C, I, A |
Threat Event |
Description |
Likelihood |
---|---|---|---|
C |
phishing |
Telehealth platform provider workforce with privileged access may be susceptible to spear phishing attacks. |
high |
I, A |
malicious software |
Telehealth platform provider workforce with privileged access to permitting allows malicious software to be introduced into the telehealth platform environment. |
moderate |
I, A |
command and control |
Telehealth platform provider workforce with privileged access to permitting allows threat actors to execute arbitrary code and perform privileged functions. |
low |
A |
ransomware |
Ransomware may be introduced into the telehealth platform provider environment either as links or attachments found in phishing emails or may be introduced through local media. |
moderate |
C |
credential escalation |
Malware may be introduced to the telehealth platform provider environment that allows threat actors to execute arbitrary code and perform privileged functions. |
moderate |
I, A |
OS or application disruption |
Malware may be introduced into the telehealth platform provider environment that disrupts the operating system or applications. Libraries or subsystems may be affected. |
low |
C |
data exfiltration |
Sensitive data may be exposed to unauthorized individuals, e.g., via social engineering disclosure or malware that allows threat actors to retrieve data arbitrarily. |
moderate |
The table below represents a notional HDO model. As with the telehealth platform provider above, many assumptions have been made about implementing pervasive controls.
Table C-5 Threats Applied to the HDO
C, I, A |
Threat Event |
Description |
Likelihood |
---|---|---|---|
C |
phishing |
HDO workforce with privileged access may be susceptible to spear phishing attacks. |
high |
I, A |
malicious software |
HDO workforce with privileged access to permitting allows malicious software to be introduced into the HDO environment. |
moderate |
I, A |
command and control |
HDO workforce with privileged access to permitting allows threat actors to execute arbitrary code and perform privileged functions. |
moderate |
A |
ransomware |
Ransomware may be introduced into the HDO environment either as links or attachments found in phishing emails or may be introduced through local media. |
moderate |
C |
credential escalation |
Malware may be introduced to the HDO environment that allows threat actors to execute arbitrary code and perform privileged functions. |
moderate |
I, A |
OS or application disruption |
Malware may be introduced into the HDO environment that disrupts the operating system or applications. Libraries or subsystems may be affected. |
moderate |
C |
data exfiltration |
Sensitive data may be exposed to unauthorized individuals, e.g., via social engineering disclosure or malware that allows threat actors to retrieve data arbitrarily. |
high |
A |
denial of service attack |
Flooding network connection with high-volume traffic to disrupt communication in patient home, between home and telehealth platform, or between telehealth platform provider and HDO. Such type of attack could also be used to damage a device, e.g., through accelerated battery depletion. |
high |
C-5 Threat Sources¶
Threat sources describe those groups or individuals that may expose weaknesses to the RPM infrastructure. Threat sources may take actions that expose or leverage vulnerabilities either through unintentional actions or by actively attacking components within the RPM infrastructure. The following table lists the threat sources identified for this risk assessment. The table is derived from one referenced in NIST Special Publication 800-30 revision 1 (page D-2) [B9].
Table C-6 Taxonomy of Threat Sources
Type of Threat Source |
Description |
Characteristics |
---|---|---|
unintentional–patient |
The patient has physical access to biometric devices, workstations, and mobile devices that may be used as part of the RPM patient home environment. |
|
unintentional–care provider (e.g., family member, friend, or others with relationship to the patient) |
Care providers or other trusted individuals that may have physical access to biometric devices, workstations, and mobile devices that may be used as part of the RPM patient home environment |
|
unintentional–other actors |
Other actors may include clinical or technical staff who may be involved in deploying the RPM infrastructure in the patient’s home and may have local or remote access to data or systems used as part of the overall RPM system. Other actors may interact with components at the software as a service (SaaS) provider or at the HDO location. |
|
intentional-domestic-criminal |
Criminal actors may be domestic and are motivated primarily by financial interest. Criminal actors may disrupt RPM deployments either directly or by affecting other devices. Threat actions may be direct or through a chain of attacks. |
|
intentional-nation-state |
Some foreign nation-states may want to disrupt another nation’s critical infrastructure. A malicious nation-state’s intent may be difficult to discern as it pertains to an individual. Attacks may be sophisticated and challenging to attribute definitively to a specific attacker. |
|
domestic or international-non-nation-state actors (e.g., hacktivists or terrorists) |
Non-nation-state actors include those parties that operate as large, disparate organizations that are not necessarily tethered to a government entity. Non-nation-state actors implement attacks based on political or social motivations. |
|
C-5.1 Business Processes¶
Several functions are performed with the RPM system, with those functions performed in the respective scopes: patient data are gathered and stored, and patients interact from the patient home; communications between patients and care teams are routed through the telehealth platform provider, which is cloud hosted; and clinicians receive and interact with patient data from the HDO. Table C-7 identifies these and other business processes that support the RPM functions.
Table C-7 RPM Functions and Processes
Function |
Description |
Components Used |
Domain |
---|---|---|---|
interface with biometric devices |
Patients may connect biometric devices to their bodies. Physical contact occurs between the device and the patient to allow the device to capture health data. Physical interface is a continuous process in that patients may make physical contact with the biometric device on a daily or more frequent basis. |
biometric device |
patient home |
store biometric data |
Biometric data are stored to physical media. Physical media are nonvolatile media types, meaning that data are recorded to the media and available for retrieval after a device has been power cycled. Physical media may consist of flash memory, secure digital (SD) cards, or hard drives associated with the biometric device or a device hosting a healthcare app or application (e.g., a mobile device, laptop, desktop, or other workstation-type device). |
biometric device mobile device laptop desktop dedicated device gateway |
patient home |
connect to cloud environment |
Biometric devices may connect to a local device that uses a telehealth app or application, or the devices may connect to a cloud-hosted telehealth platform provider directly. Connections originate from the patient home connected to the cloud-hosted telehealth platform. |
biometric device mobile device laptop desktop dedicated device gateway cloud-hosted components |
patient home telehealth platform |
connect to HDO environment |
The telehealth platform provider serves as a routing mechanism that connects communications between the patient home and the HDO. The telehealth platform provider handles in-transit data as well as manages the underlying technology to enable RPM. |
telehealth platform provider gateway or end-point devices at the HDO |
telehealth platform provider HDO |
conduct video- or audioconferencing |
Patients may initiate video or audio communication with the clinical care team through the telehealth app or application. Communications will route through the telehealth platform provider and be routed to the HDO. |
mobile device laptop desktop cloud-hosted components HDO mobile devices HDO workstations |
patient home telehealth platform provider HDO |
remote configuration or settings updates |
HDOs may periodically push configuration or other settings updates to biometric devices. The connection initiates from the HDO and connects to the biometric device located in the patient home. |
HDO-hosted servers biometric devices |
HDO patient home |
review patient biometric data |
Physicians access patient biometric data and review and analyze them. |
HDO workstation HDO mobile device |
HDO |
add biometric data to clinical notes |
Biometric data may not ingest directly to an electronic health record (EHR) system. A physician may need to manually enter information based on the biometric data to the EHR. |
HDO workstation EHR |
HDO |
C-6 Vulnerabilities¶
Below is a customized application on identifying vulnerabilities that aggregates vulnerabilities identified in NIST SP 800-30 Revision 1 [B9]. As noted in the document, a vulnerability is a deficiency or weakness that a threat source may exploit, resulting in a threat event. The document further describes that vulnerabilities may exist in a broader context, i.e., that they may be found in organizational governance structures, external relationships, and mission/business processes. The following table enumerates those vulnerabilities, using a holistic approach, and represents those vulnerabilities that this project identified and for which it offers guidance. For further description, readers should reference NIST SP 800-30 Revision 1 [B9].
Table C-8 Vulnerability Taxonomy
Vulnerability Description |
Vulnerability Severity |
Predisposing Condition |
Pervasiveness of Predisposing Condition |
---|---|---|---|
out-of-date software |
high |
Systems may not have patches deployed in a timely fashion, or software may not be validated to assure that applications may operate appropriately should the underlying operating system receive new updates. |
high |
permissive configuration settings |
high |
Underlying operating systems or security components (e.g., firewall) may have configuration settings that allow actions that exceed the minimum necessary to operate the application. |
high |
unmanaged or improperly managed credentials |
high |
Applications may use service or other privileged accounts to operate, or operating systems may have privileged accounts that have expansive access to the host system(s). These access privileges may exceed the minimum necessary to operate applications. |
high |
unprotected data |
high |
Data on systems may lack restrictions that limit accessibility. |
high |
failing or missing integrity or authenticity verification |
high |
Data path may lack end-to-end data integrity or authenticity verification. |
high |
C-7 Threat Modeling¶
Thus far, this practice guide has discussed several elements that make up an attack. Threats involve threat actors that may leverage vulnerabilities found in components. Components represent end-point devices found in the overall system. Components are made up of several subcomponents. The threat-modeling exercise described below identifies adverse actions that may expose vulnerabilities at the subcomponent level.
This practice guide considers that threats may include multiple actions taken that ultimately result in risk. These multiple actions are described herein as adverse actions. A threat may involve one or more adverse actions leveraging vulnerabilities at the subcomponent level that then result in risk.
The patient home environment is used as a representative domain by which the threat-modeling exercise is applied. Practitioners may wish to perform a similar, granular level of analysis for other domains in their deployment.
For the RPM solution, components are identified in three distinct domains: the patient home, the telehealth platform provider, and the HDO. This section describes a means by which threats may occur contextually. Adverse actions that align with threats may target specific subcomponents, with different risk outcomes based on the domain within which the threat actor executes the attack. Practitioners should note that while this practice guide does not apply any particular threat-modeling methodology, several are available that provide guidance for performing similar exercises for an organization’s environment.
C-7.1 Modeling Threats to the Patient Home¶
The patient home domain poses several challenges when considering threats. For example, patients or care providers may not have the resources or technology background to address these threats independently. Telehealth platform providers and HDOs may not have the ability to manage the patient home environment entirely. Patients may have devices that are unrelated to RPM operating in their home environment. Other individuals within the patient home may have physical access to RPM devices.
Components that may be present in the RPM system’s environment are outlined in Table C-9.
Table C-9 Components in the Patient Home Environment
Component |
Description |
Communicates with |
Provisioned by |
---|---|---|---|
biometric device |
A sensor device that interfaces with the patient and captures biometric data that are conveyed to the clinician |
patient (direct, tactile interface) interface device wireless personal area network (PAN) (e.g., Bluetooth, Wi-Fi) telehealth platform provider (Wi-Fi) |
telehealth platform HDO |
interface device |
A device that potentially retrieves data from biometric devices and is used as a communications device by which pa tient-clinician communications may occur. The device may be a mobile device such as a tablet or a connected phone running a dedicated application, may be a full-feature device such as a laptop or desktop workstation, or may be a p urpose-designed device. |
biometric device (e.g., near-field commun ication[NFC], Bluetooth, Wi-Fi) telehealth platform provider |
telehealth platform provider HDO |
Wi-Fi access point |
A device that provides the RPM environment a wireless means to communicate with devices by using internet protocols |
biometric device interface device unrelated equipment |
telehealth platform provider HDO patient |
internet router |
A device that allows computing devices in the home to communicate via the internet over broadband infrastructure (e.g., cable, fiber-optic, telephone) |
biometric device interface device unrelated equipment |
patient |
Personally-owned device |
A device that is not part of the RPM solution; however, it may have communications capabilities to components. These devices may include patient-owned devices such as personal computers, mobile devices, or connected home devices |
biometric device interface device internet router Wi-Fi access point |
patient |
unknown device |
A device belonging to individuals other than the patient. This may include guests or unknown individuals. |
unknown biometric device interface device internet router Wi-Fi access point |
unknown individuals |
The RPM solution deployed in the patient home is not a closed system. Elements that may be provisioned by the patient include Wi-Fi or cellular access points and the internet router. Further, the patient may have other devices on the home network. These may include connected home devices, personal computers, mobile devices, and gaming and entertainment systems.
The biometric device may consist of several subcomponents. Biometric devices may have PAN interfaces that support short-distance communication (e.g., Bluetooth). Biometric devices may also support Wi-Fi connectivity. A biometric device has a tactile interface that makes physical contact with an individual. There may be a display that acts as a user interface, and there may be storage media embedded in the device. There may be onboard storage. Physical external interfaces are ports for data communication (e.g., Universal Serial Bus [USB]), acceptance of removable media (e.g., SD card), and power.
Threats may be introduced based on the proximity of the subcomponent, as described in Table C-10. Threats that involve physical interaction with the subcomponent may be regarded as “local”. Threats that originate from an external network may be regarded as “remote”. Threats that use communications that are contained within the local environment may be described as “near remote”.
Table C-10 Biometric Device Subcomponent Breakdown
Subcomponent |
Adverse Action |
Proximity |
C, I, A |
Adverse Outcome |
Unmitigated Likelihood |
---|---|---|---|---|---|
tactile interface |
An individual other than the patient attaches the biometric device and introduces nonpatient data. |
local |
I |
biometric data would be false; do not pertain to the patient. |
high |
display |
An individual other than the patient may be able to navigate the user interface and view patient biometric data. |
local |
C |
unauthorized individuals may have access to biometric data. |
high |
display |
The display may be damaged so that navigation is not possible. |
local |
A |
biometric device usage degraded |
high |
onboard storage |
Storage media that maintains biometric device system files may be damaged or made unavailable. |
local |
A |
biometric device rendered inoperative |
low |
data communication port |
An individual may access the biometric device and expose a subsystem (e.g., operating system). |
local |
I, A |
exposing a subsystem such as an operating system may enable a malicious actor to escalate privileges and modify, install, or execute arbitrary code. |
low |
personal area network |
An individual may retrieve communications between the biometric device and the interface device. |
near remote |
C |
unauthorized individuals may have access to biometric data. |
low |
removable media |
An individual may be able to leverage removable media and extract data from the biometric device. |
local |
C |
unauthorized individuals may have access to biometric data. |
moderate |
removable media |
An individual may be able to introduce removable media to convey malicious software. |
local |
I, A |
unauthorized individuals may introduce unauthorized or malicious software to the biometric device and alter functionality or render the device inoperative. |
moderate |
cellular communications |
Cellular communications may be damaged. |
local; remote |
A |
cellular communications may be inoperative. |
low |
cellular communications |
Cellular communications may become compromised. |
local; remote |
A |
cellular data may be exposed to unauthorized in dividuals. |
low |
Wi-Fi communications |
Wi-Fi communications may be damaged. |
local |
A |
Wi-Fi communications may be inoperative. |
low |
Wi-Fi communications |
Wi-Fi communications may be compromised. |
local; remote |
C |
data carried over Wi-Fi may be exposed to unauthorized individuals. |
moderate |
The interface device may be a connected phone, tablet, laptop, or desktop device. Depending on the device type and manufacturer, subcomponents may vary. The first threat model profile offered below assumes that the interface device is a connected phone or tablet. Connected phones and tablets are assumed to have similar characteristics for the purposes of developing the threat model considered in this practice guide.
Table C-11 Interface Device Subcomponent Breakdown
Subcomponent |
Adverse Action |
Proximity |
C, I, A |
Adverse Outcome |
Unmitigated Likelihood |
---|---|---|---|---|---|
display |
Display may become damaged. |
local |
A |
device may be inoperable or unusable |
high |
display |
An unauthorized individual who has access to the display may be able to obtain biometric data (e.g., fingerprint). |
local |
A |
biometric data lost |
low |
data access port |
An individual may access the mobile device and expose a subsystem (e.g., operating system). |
local |
I, A |
unauthorized code may be introduced that compromises the device integrity or renders the device inoperable for intended purposes |
low |
operating system |
The operating system may be susceptible to known vulnerability exposure. |
local; remote |
C, I, A |
vulnerability exposure may allow unauthorized removal of data, allow introduction of unauthorized code that could compromise the device operational integrity, or render the device inoperable |
moderate |
RPM app |
The RPM app may not be patched to current versions and may allow exposure to known vulnerabilities. |
local; remote |
C, I, A |
apps on the device may include flaws or vulnerabilities that result in unauthorized data exposure or compromise to an app or to device operational integrity or that render the app or device inoperable |
moderate |
other apps |
Apps may be installed on the device that include unauthorized code. |
local; remote |
C |
unauthorized actors may exfiltrate data from the device |
moderate |
other apps |
Apps may be installed on the device that include unauthorized code. |
local; remote |
I, A |
unauthorized actors may disrupt the device’s functionality |
moderate |
onboard storage media |
Onboard storage media may become damaged. |
local |
A |
device may become inoperative or unable to obtain or transmit biometric data |
low |
removable media |
A device that allows removable media may enable a means by which files may be moved or copied. |
local |
C |
data may be exfiltrated |
low |
removable media |
A device that allows removable media may allow code installation. |
local |
C, I, A |
unauthorized software is introduced on the device |
low |
camera |
The camera may become damaged, rendering videoconferencing inoperative. |
local |
A |
images and videos may not be obtained |
moderate |
camera |
Malicious actors may be able to compromise subsystems and allow unauthorized control of camera functions. |
remote |
C |
sensitive video data may be exposed |
moderate |
audio microphone |
Audio microphone may become damaged. |
local |
C |
audio communication may not function appropriately |
low |
cellular communications |
Cellular communications may be damaged. |
local |
A |
cellular communications may be inoperative |
low |
cellular communications |
Cellular communications may become compromised. |
local; remote |
C |
cellular data may be exposed to unauthorized individuals |
low |
Wi-Fi communications |
Wi-Fi communications may be damaged. |
local |
A |
Wi-Fi communications may be inoperative |
low |
Wi-Fi communications |
Wi-Fi communications may be compromised. |
local; remote |
C |
data carried over Wi-Fi may be exposed to unauthorized individuals |
moderate |
Table C-12 Laptop Subcomponent Breakdown
Subcomponent |
Adverse Action |
Proximity |
C, I, A |
Adverse Outcome |
Unmitigated Likelihood |
---|---|---|---|---|---|
data access port |
An individual may access the mobile device and expose a subsystem (e.g., operating system). |
local |
I, A |
unauthorized code may be introduced that compromises the device integrity or renders the device inoperable for intended purposes |
low |
display |
An unauthorized individual who has access to the display may be able to obtain biometric data (e.g., fingerprint). |
local |
A |
biometric data lost |
low |
operating system |
The operating system may not be patched to current versions and may allow known vulnerability exposure. |
local; remote |
C, I, A |
vulnerability exposure may allow unauthorized removal of data, allow introduction of unauthorized code that could compromise the device operational integrity, or render the device inoperable |
moderate |
RPM application |
The RPM application may not be patched to current versions and may allow known vulnerability exposure. |
local; remote |
C, I, A |
applications on the device may include flaws or vulnerabilities that result in unauthorized data exposure, compromise the app or device operational integrity, or render the application or device inoperable |
moderate |
other applications |
Applications may be installed on the device that include unauthorized code. |
local; remote |
C |
unauthorized actors may exfiltrate data from the device |
moderate |
other applications |
Applications may be installed on the device that include unauthorized code. |
local; remote |
C |
unauthorized actors may exfiltrate data from the device |
moderate |
onboard storage media |
Onboard storage media may become damaged. |
local |
A |
device may become inoperative or unable to obtain or transmit biometric data |
low |
removable media |
A device that allows removable media may allow code installation. |
local |
I |
unauthorized software is introduced on the device |
low |
camera |
The camera may become damaged, rendering videoconferencing inoperative. |
local |
A |
images and videos may not be obtained |
moderate |
camera |
Unauthorized actors may be able to compromise subsystems and allow unauthorized control of camera functions. |
remote |
C |
sensitive video data may be exposed |
moderate |
audio microphone |
Audio microphone may become damaged. |
local |
A |
audio communication may not function appropriately |
low |
Wi-Fi communications |
Wi-Fi communications may be damaged. |
local |
A |
Wi-Fi communications may be inoperative |
low |
Wi-Fi communications |
Wi-Fi communications may be compromised. |
local; remote |
C |
data carried over Wi-Fi may be exposed to unauthorized individuals |
moderate |
Table C-13 Desktop Subcomponent Breakdown
Subcomponent |
Adverse Action |
Proximity |
C, I, A |
Adverse Outcome |
Unmitigated Likelihood |
---|---|---|---|---|---|
data access port |
An unintended device may obtain communications channels by using data access ports (e.g., USB). |
local |
I, A |
unauthorized code may be conveyed via the data access port and expose or corrupt subsystem libraries (e.g., operating system) |
low |
display port |
The display port may become physically damaged. |
local |
A |
information may not be displayed; interaction with the system may be prevented |
low |
operating system |
The operating system may not be patched to current versions. |
local; remote |
C, I, A |
vulnerabilities may persist |
moderate |
RPM application |
The RPM application may not be patched. |
local; remote |
C, I, A |
vulnerabilities may persist |
moderate |
other applications |
Applications may be installed on the device that include malicious code. |
local; remote |
C |
unauthorized actors may exfiltrate data from the device |
moderate |
other applications |
Applications may be installed on the device that include malicious code. |
local; remote |
C |
unauthorized actors may exfiltrate data from the device |
moderate |
onboard storage media |
Onboard storage media may become damaged. |
local |
A |
device may become inoperative or unable to obtain or transmit biometric data |
low |
removable media |
A device that allows removable media may allow code installation. |
local |
C |
unauthorized software is introduced on the device |
low |
camera |
The camera may become damaged, rendering videoconferencing inoperative. |
local |
A |
images and videos may not be obtained |
moderate |
camera |
Unauthorized actors may be able to compromise subsystems and allow unauthorized control of camera functions. |
remote |
C |
sensitive video data may be exposed |
moderate |
audio microphone |
Audio microphone may become damaged. |
local |
A |
audio communication may not function appropriately |
low |
Ethernet network port |
Ethernet port may be damaged. |
local |
A |
Wi-Fi communications may be inoperative |
low |
Ethernet network port |
Ethernet communications may be compromised. |
local; remote |
C |
data carried over Wi-Fi may be exposed to unauthorized individuals |
moderate |
Wi-Fi communications |
Wi-Fi communications may be damaged. |
local |
A |
Wi-Fi communications may be inoperative |
low |
Wi-Fi communications |
Wi-Fi communications may be compromised. |
local; remote |
C |
data carried over Wi-Fi may be exposed to unauthorized individuals |
moderate |
C-7.2 Linking Threats to Adverse Actions¶
For the threat-modeling exercise, this practice guide examines concepts at a granular level. The exercise examined the concept that threats may be evaluated at the subcomponent level through introduction of adverse actions. The adverse actions that the threat-modeling exercise included in themselves do not represent the enterprise threat environment but, rather, events that may occur that, in combination, may be how threats are found in the three domains that the practice guide describes as composing the RPM architecture.
Table C-14 Threat Event to Adverse Action Mapping
C, I, A |
Threat Event |
Attack Description |
Target Component |
Adverse Action |
---|---|---|---|---|
C |
phishing |
A social engineering attack that solicits an authorized user to perform an action that is beyond intended function. Phishing typically is delivered via an email that falsely claims authenticity. A phishing email may contain payloads such as attachments or links that then run arbitrary code. |
interface device mobile device laptop desktop |
escalation of privilege |
I, A |
unauthorized software |
Unauthorized software may include arbitrary code that compromises system integrity or system stability. |
biometric device interface device laptop desktop |
system integrity compromise: system availability degraded |
I, A |
command and control |
Unauthorized software is introduced that allows unintended actors to initiate connections to the target device. |
biometric device interface device laptop desktop |
system integrity compromise: system availability degraded |
A |
ransomware |
A form of unauthorized software that prevents legitimate access to the system and resources |
interface device laptop desktop |
system availability degraded |
C |
credential escalation |
Unauthorized individuals can leverage credentials and view sensitive data. |
interface device laptop desktop |
information exposure |
I, A |
OS or application disruption |
Resource requests or application of unauthorized software may compromise the integrity or stability of the RPM application. |
interface device laptop desktop |
system integrity compromise: system availability degraded |
C |
data exfiltration |
Unauthorized users may be able to remove sensitive data from the device. |
biometric device interface device laptop desktop |
information exposure |
Appendix D Problematic Data Actions and Risks¶
While the project team was writing this practice guide, the National Institute of Standards and Technology (NIST) published the NIST Privacy Framework, Version 1.0 [B5]. Privacy concerns should be addressed particularly in healthcare environments. The project team examined the NIST Privacy Framework and included approaches that lead toward better understanding and managing the privacy risks that may be present in remote patient monitoring (RPM) deployments.
Structurally, the NIST Privacy Framework is like the NIST Cybersecurity Framework. Both frameworks should be applied when evaluating enterprise programs and developing mitigation strategies. Applying the Privacy Framework does not supersede the NIST Cybersecurity Framework. Rather, the Privacy Framework provides organizations with information to understand privacy-specific risks. For more information about the NIST Privacy Framework, healthcare delivery organizations (HDOs) should review NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0 [B5].
D-1 Privacy Risk Assessment Methodology¶
The project team applied the NIST Privacy Risk Assessment Methodology (PRAM) to conduct a privacy risk assessment for the RPM architecture. The PRAM helps an organization analyze privacy risks and facilitates communication regarding how it is managing privacy risks to achieve business/mission objectives. Processing can include collection, retention, logging, analysis, generation, transformation, merging, disclosure, transfer, and disposal of data. The PRAM also uses the privacy risk model and privacy engineering objectives described in NIST Internal Report 8062 [B36] to analyze data processing for problematic data actions. A problematic data action is any data processing operation that could lead to an adverse effect, or problem, for individuals.
The occurrence or potential occurrence of problematic data actions is a privacy event. For this RPM solution, the PRAM helped elucidate how RPM solutions can present privacy concerns for individuals. The PRAM, being a risk assessment, also supports the risk assessment task in the Prepare step of the NIST Risk Management Framework as discussed in Section C-1 of this guide. The privacy events identified are discussed in Section C-2. A blank version of the PRAM is available for download on NIST’s website [B7]. When conducting the PRAM for this RPM solution, metadata was not assessed as it is out of scope for this project; therefore, this practice guide does not provide guidance to help an organization with securing any possible metadata if it may be leaked on devices within the telehealth ecosystem. An organization should consider the risk that could result from this incident occurring in its telehealth ecosystem.
Figure D-1 depicts the privacy view of the RPM solution dataflow and was used to conduct the privacy risk assessment. The dataflow is broken into seven data processing activities (described here as “data actions” and appearing in the diagram as a sequence labelled from 1 to 7). The dataflow shows the relationships between the key operators throughout the full lifecycle of the solution as well as the types of data processing that occur as the data moves between operators. The operators include the patient, biometric device, RPM mobile device, biometric device vendor, telehealth platform, and the HDO (comprised of the Clinician and electronic health record). Symbols are used to depict the types of data actions performed, including collection, retention/logging, generation/transformation, disclosure/transfer, disposal.
Data Action 1 shows the patient connecting to a biometric device so that it can begin collecting readings.
Data Action 2 shows that the biometric data generated by the patient is read by and retained on the biometric device before being transmitted to either the RPM Mobile Device (via Bluetooth or Wi-Fi) or the Biometric Device Vendor (via cellular network) when a retrieval request is sent.
Data Action 3 describes two possible paths for collecting biometric data, one via an RPM Mobile Device, and another via the Biometric Device Vendor. The RPM Mobile Device or Biometric Device Vendor collects and retains the biometric data and then forwards the biometric data to the Telehealth Platform.
Data Action 4 shows that patient data may be generated or transformed as the Telehealth Platform evaluates and correlates data and alerts the clinician when a patient data threshold is passed. The Telehealth Platform also maintains a history of readings and trends.
Data Action 5 shows that the Clinician accesses the Telehealth Platform, evaluates the patient data and determines whether and how to respond, which may generate additional patient data. When needed, the Clinician also transfers patient data to update the EHR for later reference.
Data Action 6 shows that the Clinician may meet with the patient using an PRM Mobile Device. This interaction may result in collection and of additional information that is stored in the EHR.
Data Action 7 shows that HDOs may choose to initiate a patient survey
The diagram shows that the Data Actions 4-7 are out of the scope of this solution and the privacy risk assessment.
Figure D-1 Privacy View of RPM Solution Dataflow
D-2 Problematic Data Actions and Mitigations¶
The NIST Privacy Framework refers to the concept of problematic data actions, which derives from the NIST PRAM. Problematic data actions are discovered by conducting a privacy risk assessment and analyzing the likelihood that an operation performed by a system would create a problem for individuals when processing data and the impact of the problematic data action should it occur. This section provides representative problematic data actions identified in the RPM architecture and the mitigations that an organization may use to reduce or prevent potential risk.
The discussion of problematic data actions is structured as follows:
Privacy Risk: descriptive name for the issue that can arise in the RPM solution from data processing
Data Action: a data life-cycle operation in the RPM solution, including collection, retention, logging, generation, transformation, use, disclosure, sharing, transmission, and disposal
Problematic Data Action: a data action in the RPM solution that could cause an adverse effect for individuals (based on the NIST Catalog of Problematic Data Actions and Problems)
Potential Problems for Individuals: discussion regarding the nature of the problematic data action and the specific privacy problems that can arise for patients (based on the NIST Catalog of Problematic Data Actions and Problems)
Mitigations: examples of mitigations for the problematic data action, including those that this RPM solution addresses as well as other mitigations that organizations may wish to consider beyond the direct capabilities built into their RPM solution
D-2.1 Privacy Risk 1: Storage and movement of data create multiple points of potential exposure after data are collected from the patient¶
Data Action: Patients’ readings are taken from the biometric device and forwarded to the telehealth platform.
Problematic Data Action: Insecurity
Potential Problems for Individuals:
Data shared between devices in the RPM data ecosystem may not be
protected at rest or in transit. Data may include sensitive information.
Unauthorized data disclosure may result in patient harm. For example,
disclosure could lead to dignity loss or embarrassment or may cause
patients to distrust the RPM system.
The solution relies on communication between the patient’s biometric device(s) and the HDO. Biometric devices forward the information to the HDO via the telehealth platform provider. In this solution, data flow from the biometric device either directly to the telehealth platform provider or are routed via an RPM mobile device via Bluetooth, Wi-Fi, or over the cellular network. Each device, system, and dataflow in the process introduces an exposure point, several of which would not arise in a traditional healthcare setting, such as a doctor’s appointment (e.g., if the patient’s reading is taken in a doctor’s office). Any failure to protect data stored on the biometric and RPM mobile devices and forwarded may allow unauthorized individuals to view sensitive information. In this event, someone other than a patient-approved individual can access data that are unencrypted on the biometric device or RPM mobile device or during forwarding. The patient may experience dignity loss due to their health information being exposed and may also experience loss of trust for the HDO and RPM mobile device.
Mitigation(s):
RPM Solution Mitigation:
Physical device security is out of scope for this lab solution.
Protect data at rest and in transit between devices and telehealth platforms.
Protecting data on the biometric device, e.g., by using encryption, prior to moving it to the telehealth platform and using encrypted connections to protect the contents of data in transit reduces the risk of exposure. Robust network security controls should be in place to help protect data in transit. For example, firewalls and network access control will help secure the data against ransomware, malware, and other attacks. If data are not encrypted, unauthorized individuals may be able to retrieve the data, which can lead to inappropriate use of information. Encryption methods should be used in preventing health information disclosure.
Additional Privacy Mitigations for Organizations to Consider:
Develop and adopt enterprise encryption policies.
Policies should be created, developed, and adopted for systematically categorizing and classifying all healthcare data, including metadata, no matter where the data are stored.
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¶
Data Action: Patients are provided one or more biometric devices that monitor biometric data and send that data to their healthcare providers to help assess the physical health condition of the patient between visits with the provider.
Problematic Data Action: Unanticipated Revelation
Potential Problems for Individuals: Patients with given medical conditions may use certain biometric devices, alone or in combination. If communications from these devices are accessed by unauthorized individuals, they may disclose particular health problems. For example, a glucometer can indicate that a patient is being monitored for diabetes. This assumption could be more obvious if that same patient is also known to be using a blood pressure monitor, weight scale, and activity tracker.
Patient sensitivities regarding their health status can vary widely. Unauthorized individuals may be able to determine a patientʼs medical condition based on knowing a combination of factors. For example, knowledge of the device type and the biometric data may enable individuals to conclude the patientʼs health condition. Revealing a health condition that a patient would prefer not to disclose or disclosure of a patientʼs medical treatment and their course of treatment outside their healthcare provider can lead to dignity loss, such as embarrassment, emotional distress, and loss of trust in the HDO and RPM system. This could damage the relationship with a patient, including losing the opportunity for the HDO to continue providing care. Intercepting communications sessions may have a lower likelihood of occurrence than aggregated data compromise.
When biometric devices participate in an RPM solution, they may share device metadata (e.g., device identifiers, device type, or manufacturer) as they communicate with the vendor, telehealth platform, or the HDO. This device metadata may reveal the information that indicates a patient condition (e.g., type of device). Additionally, communications may be vulnerable to eavesdropping, which could give away the device type. Evaluating device metadata and communications should be included in the organization’s risk assessment.
Mitigation(s):
RPM Solution Mitigation(s):
Protect data transmitted between parties and in storage.
Data-in-transit protection, e.g., by encrypting communications channels, reduces the risk of compromise of information transmitted between parties. Reducing the risk of compromise and any resulting exposures reduces the risk of unintentional exposure of the information. Biometric devices communicate through a mobile device that uses a Bluetooth connection, and the RPM solution assumes that these devices are deployed using an appropriate encryption mode [B25] [B37]. The RPM solution uses devices that are equipped to communicate over 4G long-term evolution (LTE), which uses asymmetric encryption between the device and the cellular tower. Additionally, all data at rest is protected with AES-256 encryption [B28].
Limit or disable access to data.
Conduct a system-specific privacy risk assessment to determine how access to data in the telehealth platform provider can be limited. Using access controls to limit staff access to biometric and patient data can be important in preventing associating health conditions with specific individuals.
D-2.3 Privacy Risk 3: Incorrect data capture of readings by devices may impact quality of patient care¶
Data Action: The RPM solution relies on the patient to take readings by using the patient’s assigned biometric device(s) when required according to their care plan.
Problematic Data Action: Distortion
Potential Problems for Individuals: Devices may be inaccurately applied by the patient (e.g., not properly using or inadvertently changing settings), which can impact the ability of a biometric device to take proper readings. Anomalies may also be introduced by other individuals who may have physical access to the device (e.g., allowing someone other than the patient to use the device), which may introduce biometric readings other than the patientʼs into the system. Data integrity may be compromised, causing confusion regarding the patient’s actual health and possibly leading to physical harm to the patient.
Mitigation(s):
RPM Solution Mitigation(s):
Physical device security is out of scope for this lab solution. Ultimately, responsibility for monitoring patient data, including identifying anomalies, falls on the clinician.
Additional Privacy Mitigations for Organizations to Consider:
Educate patients regarding practices for handling biometric device(s) and the importance of following their monitoring plan.
Educating patients regarding how their interactions with the biometric devices assigned to them affect the quality of the data provided to the telehealth platform provider, HDO, healthcare provider, and ultimately the quality of care they receive and their health safety will encourage them to use the biometric devices as designed and intended.
D-2.4 Privacy Risk 4: Aggregated data may expose patient information¶
Data Action: Patients use one or more biometric devices to monitor the condition of their health. The biometric data generated are transmitted through multiple entities, including cellular or broadband internet providers, biometric device vendors, telehealth platform providers, cloud service providers, and HDOs before reaching the healthcare provider.
Problematic Data Action: Re-identification
Potential Problems for Individuals: The RPM architecture integrates data from multiple organizations, each of which may have different data that pertain to the patient. The biometric data generated by the solution indicates an individual’s health status. Aggregation of biometric data with patient identifiers associates information about the patient that, if revealed to an entity other than their healthcare provider and care team, may result in dignity losses, such as embarrassment or emotional distress, as well as loss of trust in the HDO and provider.
Mitigation(s):
RPM Solution Mitigation(s):
Combine biometric data with patient identifiers only when operationally required.
The device manufacturer may aggregate data received from patients. Biometric data do not include patient identifiers but will include device identifiers. The telehealth platform provider may associate the biometric data to patients by using device identifiers. In this RPM solution, the telehealth platform provider does not combine these data until the point at which it is necessary to perform patient analytics that enable the healthcare delivery organization to manage the patient’s care. The telehealth platform provider uses a biometric device identifier to correlate a patient with the biometric data that a device transmits.
Protect data transmitted between parties and in storage.
Data protection, e.g., by using encryption, reduces the risk that compromised data can be easily used and combined with other data to re-identify patients. Biometric devices communicate through a mobile device that uses Bluetooth connections, and the RPM solution assumes that these devices are deployed using an appropriate encryption mode [B25] [B37]. The RPM solution uses devices that are equipped to communicate over 4G LTE, which uses asymmetric encryption between the device and the cellular tower. Additionally, all data at rest is protected with AES-256 encryption.
D-2.5 Privacy Risk 5: Exposure of patient information through multiple providers of system components increases the likelihood of exposure of patient data to unintended recipients¶
Data Action: Data about individuals and their devices flow between various applications and analytical tools, some of which are managed by third parties.
Problematic Data Action: Unanticipated Revelation
Potential Problems for Individuals: Multiple organizations work together to provide individual components of the RPM solution, and each organization that plays a role in data processing represents an exposure point for patient information. Patient biometric data travel from devices to the HDO through device vendors and telehealth platform providers over cellular and broadband networks. Some of the data also flows through cloud solutions. These third parties beyond the HDO and patient’s provider may conduct system monitoring, analytics, and other operational activities as part of the solution. System administrators have access to otherwise private healthcare information through knowledge of biometric device types and the data they generate, which may reveal information about patients that results in dignity losses, such as embarrassment or emotional distress.
Data transmission about patients and their biometric devices among a variety of different parties could be confusing for patients who might not know who has access to information about them. This transmission could reveal personal information about the patient to parties they would not expect to have such information. This lack of patient visibility and awareness of data-sharing practices may also cause patient loss of trust in the provider.
Additionally, the communications between RPM devices and systems generate metadata that may pose additional risk of exposure. For example, device identifiers in some contexts may indicate the type of device that is communicating, which can provide insights into a patient’s condition even without viewing the data transmitted. Metadata was not evaluated as part of this solution; however, organizations planning to implement RPM solutions should include an evaluation of metadata in their risk assessment.
Mitigation(s):
RPM Solution Mitigation(s):
Combine biometric data with patient identifiers only when operationally required.
The device manufacturer may aggregate data received from patients. Biometric data do not include patient identifiers, however, will include device identifiers. The telehealth platform provider may associate the biometric data to patients by using device identifiers. In this RPM solution, the telehealth platform provider does not combine these data until the point at which it is necessary to perform patient analytics that enable the healthcare delivery organization to manage the patient’s care. The telehealth platform provider uses a biometric device identifier to correlate the biometric data with a patient.
Protect data transmitted between parties and in storage.
Data protection, e.g., using encryption, reduces the risk of compromise of information transmitted between parties. Biometric devices communicate through a mobile device that uses Bluetooth connections, and the RPM solution assumes that these devices are deployed using an appropriate encryption mode. The RPM solution uses devices that are equipped to communicate over 4G LTE, which uses asymmetric encryption between the device and the cellular tower [B25] [B37]. Additionally, all data at rest is protected with AES-256 encryption.
Limit or disable collection of specific data elements.
Conduct a system-specific privacy risk assessment to determine what elements can be limited. The RPM solution sends only biometric and device data from the device to the RPM interface and vendors and excludes identifying information about the patient. This would limit insight into patient health status by outsiders or telehealth platform provider administrators if the security of the information is compromised.
Additional Privacy Mitigations for Organizations to Consider:
Limit or disable access to data.
Conduct a system-specific privacy risk assessment to determine how access to data can be limited. Using access controls to limit staff access to compliance information, especially when associated with patients, can be important in preventing association of specific biometric data with individuals.
Use contracts to limit third-party data processing.
Establish contractual policies to limit data processing by third parties to only the processing that facilitates delivery of security services and to no data processing beyond those explicit purposes.
D-3 Additional Program Mitigations Applicable Across Various Data Actions¶
Organizations that deploy RPM solutions will conduct their own risk assessment and determine what mitigations are most appropriate for their environment, including organizational activities outside the direct control of their RPM solution. This section includes several examples of mitigations that may be common across the organization and is not intended to be all-encompassing.
Mitigations:
Ensure that privacy notices address end-to-end dataflows in the RPM solution between patient and provider.
RPM solutions empower patients as active participants in their healthcare. Privacy notices—information such as the data collected about the patient, the reason they are collected, how they are processed by an organization, how they are protected, and how long an organization plans to use them—are one way that HDOs can help patients understand their relationship and expectations with an organization. Privacy notices are also a precursor to requesting consent so that patients understand what agreements they are making and how to withdraw consent at any time during the program. Effective notices that cover the RPM solution should be specific enough to help patients understand the PRM solution and should be written in clear terms that are easily understood by any individuals (i.e., individuals do not need healthcare, RPM, or privacy expertise to interpret the privacy notice). Patients may not be aware of or easily able to discern what is happening with the information generated by their biometric device(s), such as analytics and trend analyses that telehealth platform providers can conduct and how a provider may use this information for their care. Information regarding the RPM solution that includes a discussion of privacy helps patients better understand how the system processes their data, which enhances predictability. One example of providing an effective RPM privacy notice would be to create an RPM website or pamphlet, separate from the overall operational privacy notice that an HDO may have, that explains the RPM program.
Provide a support point of contact.
Providing patients with a point of contact in the organization who can respond to privacy inquiries and concerns regarding the RPM solution helps patients better understand how the system processes their data, which enhances predictability.
Define and communicate clear retention policies.
To minimize security and privacy risk to patients (e.g., deciding based on outdated data that could impact the quality of care provided through an RPM solution), HDOs should use the results of their risk assessment to determine how each solution component impacts their retention policies for each step in the dataflow process. When an HDO relies on other entities to support data processing activities, the HDO should clearly communicate its data retention and privacy risk management needs to those entities.
Implement program-specific privacy and security training and awareness activities.
Privacy and security may be compromised while performing business functions if employees do not understand how to incorporate security and privacy practices into their operational activities. Each organization that plays a role in healthcare RPM solutions must evaluate its role in the data ecosystem, the privacy and security risks that arise in the context of that role, and the training and awareness activities that will be most impactful for addressing those risks.
Establish and communicate a process for patients to withdraw from the program.
HDOs should work with their privacy program to consider in advance the privacy implications when patients decide to no longer participate in the RPM program and the processes that must occur to conclude their participation. For example, organizations will have data retention considerations for managing patient information collected as part of the program. HDOs should assure patients are aware that they have the ability to withdraw their consent prior to and during their participation in the program and that they have instructions for withdrawal. For example, HDOs may provide potential participants information regarding withdrawal from the program and who to contact with questions about that process in the telehealth informed consent documentation prior to their enrollment in the program. HDOs should consider an explicit consent model rather than an implicit consent. Patients may also directly request removal of their data from the RPM platform. HDOs will need to establish capabilities for decommissioning patients in the RPM solution as well as for communicating any related requirements to platform providers and other partners in the RPM solution.
Appendix E Benefits of IoT Device Cybersecurity Requirements¶
The National Institute of Standards and Technology’s (NIST’s) Cybersecurity for the Internet of Things (IoT) program [B38] supports development and application of standards, guidelines, and related tools to improve the cybersecurity of connected devices and the environments in which they are deployed. By collaborating with stakeholders across government, industry, international bodies, and academia, the program aims to cultivate trust and foster an environment that enables innovation on a global scale.
Computing devices that integrate physical and/or sensing capabilities and network interface capabilities are being designed, developed, and deployed at an ever-increasing pace. These devices are fulfilling customer needs in all sectors of the economy. Many of these computing devices are connected to the internet. IoT devices combine network connectivity with the ability to sense or affect the physical world. Individuals may find challenges with applying privacy and cybersecurity controls as devices include greater functionality.
NIST’s Cybersecurity for IoT program has defined a baseline set of device cybersecurity capabilities that manufacturers should consider integrating into their IoT devices and that consumers should consider enabling/configuring in those devices. Device cybersecurity capabilities are cybersecurity features or functions that IoT devices provide through their own technical means (i.e., device hardware and software). Nontechnical supporting capabilities are actions that a manufacturer or third-party organization performs in support of the cybersecurity of an IoT device. Examples of nontechnical support include providing information about software updates, instructions for configuration settings, and supply chain information.
Used together, device cybersecurity capabilities and nontechnical supporting capabilities can help mitigate cybersecurity risks related to the use of IoT devices while assisting customers in achieving their goals. Device cybersecurity capabilities and nontechnical supporting capabilities—if properly defined and integrated into the RPM devices and RPM architectural environment—can assist in securely deploying and configuring an RPM ecosystem.
E-1 Device Capabilities Mapping¶
Table E-1 below builds on the Security Control Map in Section 3.5 of this document. The table lists both device cybersecurity capabilities and nontechnical supporting capabilities that map to NIST Cybersecurity Framework Subcategories that were considered relevant to RPM ecosystem risks. Selecting devices and/or third parties that provide these capabilities can support the secure deployment and configuration of the RPM ecosystem. The column listing mapping from Cybersecurity Framework Subcategories to the Health Insurance Portability and Accountability Act (HIPAA) Security Rule is included as an important sector-specific standard.
Note: In the table below, the HIPAA Security Rule elements listed in the last column were previously mapped to the Cybersecurity Framework Subcategories. The device cybersecurity capabilities and nontechnical supporting capabilities listed were mapped to the Cybersecurity Framework Subcategories, not to the HIPAA Security Rule elements. In this sense, the Cybersecurity Framework Subcategories served as the central element joining the device cybersecurity capabilities and nontechnical supporting capabilities with the HIPAA Security Rule elements.
Table E-1 Mapping of Device Cybersecurity Capabilities and Nontechnical Supporting Capabilities to NIST Cybersecurity Framework Subcategories of the RPM Project
Cybersecurity Framework v1.1 Subcategory |
Device Cybersecurity Capabilities |
Manufacturer Nontechnical Supporting Capabilities |
HIPAA Security Rule Mapping to Cybersecurity Framework Subcategory |
---|---|---|---|
ID.AM-1: Physical devices and systems within the organization are inventoried. |
|
|
45 C.F.R §§
164.308(a)(1)(ii)(A)
164.308(a)(4)(ii)(A)
164.308(a)(7)(ii)(E)
164.308(b)
164.310(d)
164.310(d)(2)(iii)
|
ID.AM-2: Software platforms and applications within the organization are inventoried. |
|
N/A |
45 C.F.R §§
164.308(a)(1)(ii)(A)
164.308(a)(7)(ii)(E)
|
ID.AM-4: External information systems are catalogued. |
N/A |
|
45 C.F.R §§
164.308(a)(4)(ii)(A)
164.308(b)
164.314(a)(1)
164.314(a)(2)(i)(B)
164.314(a)(2)(ii)
164.316(b)(2)
|
ID.AM-5: Resources (e.g., hardware, devices, data, time, personnel, and software) are prioritized based on their classification, criticality, and business value. |
N/A |
N/A |
45 C.F.R §§
164.308(a)(7)(ii)(E)
|
ID.RA-1: Asset vulnerabilities are identified and documented. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(A)
164.308(a)(4)(ii)(A)
164.308(a)(7)(ii)(E)
164.308(b)
164.310(d)
164.310(d)(2)(iii)
|
ID.RA-4: Potential business impacts and likelihoods are identified. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(1)(ii)(A)
164.308(a)(1)(ii)(B)
164.308(a)(6)
164.308(a)(7)(ii)(E)
164.308(a)(8)
|
ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(A)
164.308(a)(1)(ii)(B)
164.308(a)(1)(ii)(D)
164.308(a)(7)(ii)(D)
164.308(a)(7)(ii)(E)
164.316(a)
|
ID.RA-6: Risk responses are identified and prioritized. |
|
|
45 C.F.R. §§
164.308(a)(1)(ii)(B)
164.314(a)(2)(i)(C)
164.314 (b)(2)(iv)
|
PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes. |
|
|
45 C.F.R. §§
164.308(a)(3)(ii)(B)
164.308(a)(3)(ii)(C)
164.308(a)(4)(i)
164.308(a)(4)(ii)(B)
164.308(a)(4)(ii)(C)
164.312(a)(2)(i)
|
PR.AC-2: Physical access to assets is managed and protected. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(B)
164.308(a)(7)(i)
164.308(a)(7)(ii)(A)
164.310(a)(1)
164.310(a)(2)(i)
164.310(a)(2)(ii)
|
PR.AC-3: Remote access is managed. |
|
N/A |
45 C.F.R. §§
164.308(a)(4)(i)
164.308(b)(1)
164.308(b)(3)
164.310(b)
164.312(e)(1)
164.312(e)(2)(ii)
|
PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties. |
|
|
45 C.F.R. §§
164.308(a)(3)
164.308(a)(4)
164.310(a)(2)(iii)
164.310(b)
164.312(a)(1)
164.312(a)(2)(i)
|
PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation). |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(4)(ii)(B)
164.310(a)(1)
164.310(b)
164.312(a)(1)
164.312(b)
164.312(c)
|
PR.AC-6: Identities are proofed and bound to credentials and asserted in interactions. |
|
N/A |
|
PR.AC-7: Users, devices, and other assets are authenticated (e.g., single- factor, multi- factor) commensurate with the risk of the transaction (e.g., individuals’ security and privacy risks and other organizational risks). |
|
|
|
PR.DS-1: Data- at-rest is protected. |
|
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(b)(1)
164.310(d)
164.312(a)(1)
164.312(a)(2)(iii)
164.312(a)(2)(iv)
|
PR.DS-2: Data-in-transit is protected. |
|
|
45 C.F.R. §§
164.308(b)(1)
164.308(b)(2)
164.312(e)(1)
164.312(e)(2)(i)
164.312(e)(2)(ii)
164.314(b)(2)(i)
|
PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(1)(ii)(A)
164.310(a)(2)(ii)
164.310(a)(2)(iii)
164.310(a)(2)(iv)
164.310(d)(1)
164.310(d)(2)
|
PR.DS-4: Adequate capacity to ensure availability is maintained. |
|
N/A |
45 C.F.R. §§
164.308(a)(1)(ii)(A)
164.308(a)(1)(ii)(B)
164.308(a)(7)
164.310(a)(2)(i)
164.310(d)(2)(iv)
164.312(a)(2)(ii)
|
PR.DS-5: Protections against data leaks are implemented. |
|
N/A |
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(a)(3)
164.308(a)(4)
164.310(b)
164.310(c)
164.312(a)
|
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity. |
|
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.312(b)
164.312(c)(1)
164.312(c)(2)
164.312(e)(2)(i)
|
PR.IP-4: Backups of information are conducted, maintained, and tested. |
N/A |
|
164.308(a)(7)(ii)(A)
164.308(a)(7)(ii)(B)
164.308(a)(7)(ii)(D)
164.310(a)(2)(i)
164.310(d)(2)(iv)
|
PR.IP-6: Data is destroyed according to policy. |
|
|
45 C.F.R. §§
164.310(d)(2)(i)
164.310(d)(2)(ii)
|
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(6)
164.308(a)(6)(i)
164.308(a)(7)
164.310(a)(2)(i)
164.312(a)(2)(ii)
|
PR.IP-10: Response and recovery plans are tested. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(7)(ii)(D)
|
PR.IP-12: A vulnerability management plan is developed and implemented. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(1)(ii)(A)
164.308(a)(1)(ii)(B)
|
PR.MA-1: Maintenance and repair of organizational assets are performed and logged, with approved and controlled tools. |
N/A |
|
45 C.F.R. §§
164.308(a)(3)(ii)(A)
164.310(a)(2)(iv)
|
PR.MA-2: Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(a)(3)(ii)(A)
164.310(d)(1)
164.310(d)(2)(ii)
164.310(d)(2)(iii)
164.312(a)
164.312(a)(2)(ii)
164.312(a)(2)(iv)
164.312(b)
164.312(d)
164.312(e)
|
PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy. |
|
|
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
164.308(a)(5)(ii)(C)
164.308(a)(2)
164.308(a)(3)(ii)(A)
|
PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities. |
|
N/A |
45 C.F.R. §§
164.308(a)(3)
164.308(a)(4)
164.310(a)(2)(iii)
164.310(b)
164.310(c)
164.312(a)(1)
|
PR.PT-4: Communications and control networks are protected. |
|
N/A |
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.312(a)(1)
164.312(b)
164.312(e)
|
DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.312(b)
|
DE.AE-2: Detected events are analyzed to understand attack targets and methods. |
|
|
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
164.308(a)(5)(ii)(C)
164.308(6)(i)
164.308(a)(6)(i)
|
DE.CM-1: The network is monitored to detect potential cybersecurity events. |
|
|
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
164.308(a)(5)(ii)(C)
164.308(a)(2)
164.308(a)(3)(ii)(A)
|
DE.CM-2: The physical environment is monitored to detect potential cybersecurity events. |
N/A |
|
45 C.F.R. §§
164.310(a)(2)(ii)
164.310(a)(2)(iii)
|
DE.CM-4: Malicious code is detected. |
N/A |
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
|
DE.CM-5: Unauthorized mobile code is detected. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
|
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed. |
|
|
45 C.F.R. §§
164.308(a)(1)(ii)(D)
164.308(a)(5)(ii)(B)
164.308(a)(5)(ii)(C)
164.310(a)(1)
164.310(a)(2)(ii)
164.310(a)(2)(iii)
|
DE.CM-8: Vulnerability scans are performed. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(1)(i)
164.308(a)(8)
|
RS.RP-1: Response plan is executed during or after an event. |
|
|
45 C.F.R. §§
164.308(a)(6)(ii)
164.308(a)(7)(i)
164.308(a)(7)(ii)(A)
164.308(a)(7)(ii)(B)
164.308(a)(7)(ii)(C)
164.310(a)(2)(i)
164.312(a)(2)(ii)
|
RS.IM-1: Response plans incorporate lessons learned. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(7)(ii)(D)
164.308(a)(8)
164.316(b)(2)(iii)
|
RS.IM-2: Response strategies are updated. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(7)(ii)(D)
164.308(a)(8)
|
RC.RP-1: Recovery plan is executed during or after a cybersecurity incident. |
N/A |
N/A |
45 C.F.R. §§
164.308(a)(7)
164.308(a)(7)(i)
164.308(a)(7)(ii)
164.308(a)(7)(ii)(C)
164.310(a)(2)(i)
164.312(a)(2)(ii)
|
E-2 Device Capabilities Supporting Functional Evaluations¶
Table E-2 below builds on the functional evaluations included in Section 6 of this document. The table lists both device cybersecurity capabilities and nontechnical supporting capabilities that map to each of the functional test cases. Selecting devices and/or third parties that provide these capabilities can help achieve the respective functional requirements.
Table E-2 Device Cybersecurity Capabilities and Nontechnical Supporting Capabilities that Map to Each of the Functional Test Cases
Test Case Identification (ID) and Description with Relevant Cybersecurity Framework Subcategories |
Device Cybersecurity Capabilities |
Manufacturer Nontechnical Supporting Capabilities |
---|---|---|
RPM-1 Asset Management: Device Management Demonstrate the ability to verify that provisioned devices are associated with the intended patient who has enrolled in an RPM program. ID.AM-1
ID.AM-5
|
|
|
RPM-2 Risk Assessment: End-Point Vulnerability Scanning Demonstrate the ability to perform vulnerability scans on assets and view results in a dashboard format with risk-scoring evaluations. ID.RA-1
ID.RA-4
ID.RA-5
ID.RA-6
|
|
|
RPM-3 Identity Management, Authentication, and Access Control: Role-based Access Demonstrate the ability to limit and disable access to data by implementing role-based access control on the Vivify platform. PR.AC-1
PR.AC-2
PR.AC-3
PR.AC-4
PR.AC-5
PR.AC-6
|
|
|
RPM-4 Identity Management, Authentication, and Access Control: Domain User Authentication and Authorization Demonstrate the ability to create new domain users and enforce restrictions on nonadmin users. PR.AC-1
PR.AC-2
PR.AC-3
PR.AC-4
PR.AC-5
PR.AC-6
|
|
|
RPM-5 Identity Management, Authentication, and Access Control: Network Segmentation and Access Control Policy Demonstrate the use of network segmentation and an access control policy to allow permitted traffic to selected network devices. PR.AC-1
PR.AC-2
PR.AC-3
PR.AC-4
PR.AC-5
PR.AC-6
|
|
|
RPM-6 Security Continuous Monitoring: Malware Protection Demonstrate the ability to protect the network and end points from malicious services by blocking the service before a connection is made. DE.CM-1
DE.CM-2
DE.CM-4
DE.CM-7
DE.CM-8
|
|
|
RPM-7 Security Continuous Monitoring: Malicious Activity Detection Demonstrate the ability to detect anomalous network traffic and create an alert for further investigation. DE.CM-1
DE.CM-2
DE.CM-4
DE.CM-7
DE.CM-8
|
|
|
RPM-8 Security Continuous Monitoring: End-Point Monitoring and Protection Demonstrate the ability to detect unusual authentication behaviors and file integrity changes on protected end points. DE.CM-1
DE.CM-2
DE.CM-4
DE.CM-7
DE.CM-8
|
|
|
RPM-9 Security Continuous Monitoring: End-Point Network Access Monitoring This test case demonstrates the ability to create alarms for unauthorized network traffic. DE.CM-1
DE.CM-2
DE.CM-4
DE.CM-7
DE.CM-8
|
|
|
RPM-10 Data Security: Data in Transit Is Protected Demonstrate the ability to protect data in transit between the patient home and the telehealth platform. PR.DS-2 |
|
|
Appendix F Applying the OSI Model in Understanding Zero Trust Architecture¶
Networking professionals often refer to the Open Systems Interconnection (OSI) model when implementing network protocols. The International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) describe the OSI model as consisting of seven layers called Application, Presentation, Session, Transport, Network, Data Link, and Physical, where layers are numerically ordered in reverse. That is, the Application Layer is regarded as Layer 7, whereas the Physical Layer is regarded as Layer 1 [B39].
Layer 2 aligns with the OSI model’s Data link layer. Devices operating at Layer 2 have media access control (MAC) addresses by which devices, such as biometric devices, may communicate across a local area network (LAN) segment. Layer 3 aligns with the OSI model’s Network layer. Devices implement the Network layer with Internet Protocol (IP) addresses. Layer 2 over Layer 3 solutions enable devices that do not implement the Network layer to have broader interconnectivity. Layer 2 over Layer 3 solutions provide security by limiting access to devices and securing the data-in-transit communications, e.g., with encryption. Layer 2 over Layer 3 solutions may be used to create secure enclaves, grouping small numbers of devices that may require enhanced network security. Creating secure enclaves aligns with the concept of micro-segmentation.
Organizations may consider Layer 2 over Layer 3 solutions for devices that may be prone to internet threats. Biometric devices may implement Layer 2 and Layer 3 interconnectivity; however, they do not have robust controls that prevent unauthorized remote access. Secure enclaves may be created that encapsulate biometric devices with other devices when secure cross communication is required. This practice guide deployed a Layer 2 over Layer 3 solution as part of a proof of concept within the healthcare lab.
National Institute of Standards and Technology (NIST) Special Publication (SP) 800-207, Zero Trust Architecture [B22], describes an enclave gateway model that may be applied to a telehealth remote patient monitoring (RPM) architecture. In the enclave gateway model, a zero-trust solution operates in two conceptual planes: a control and a data plane. Micro-segmentation management devices operate in a control plane. These management devices provide administrative and policy capabilities to support secure enclaves. Operational components, such as biometric devices, telehealth platform provider services, and devices hosted by healthcare delivery organizations, may operate in the data plane. Figure F-1 depicts the enclave gateway model.
Figure F-1 Enclave Gateway Model [B25]
The Layer 2 over Layer 3 solution used in this practice guide brings principles on zero trust architecture (ZTA) to telehealth RPM. Managed biometric devices may be subject to threats that may be present in the patient home network. The Layer 2 over Layer 3 approach segments the RPM components from other devices that may operate in the patient home. Devices not associated with the deployed RPM components do not have a communication pathway to the RPM devices. ZTA allows the biometric devices to authenticate into the Layer 2 over Layer 3 security solution so that only traffic from the RPM components traverses the Layer 2 over Layer 3 network. Practitioners should refer to NIST SP 800-207, Zero Trust Architecture, for guidance [B22].