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

FIPS 200 [B32]; NIST SP 800-53 [B10]

3

implement

NIST SP 800-70 [B33]

4

assess

NIST SP 800-53A [B34]

5

authorize

NIST SP 800-37 [B35]

6

monitor

NIST SP 800-37 [B35]; NIST SP 800-53A [B34]

Figure C-1 Risk Management Framework [C35]

../_images/image9.PNG

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.

  • able to access components in patient home domain

  • intend to access components

  • patient may be targeted by malicious actors.

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

  • able to access components in patient home domain

  • intend to access components

  • individuals may be targeted by malicious actors.

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.

  • able to access components or data as part of the RPM system

  • intend to access the system (e.g., through maintenance or data review)

  • individuals may be targeted by malicious actors or may represent insider threats where actors have legitimate access; however, component use or data access is not aligned with providing patient care.

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.

  • ability to access components is not initially provisioned. Criminal actors may perform discovery to identify vulnerable components and may seek means to deploy malicious software that would allow them access and control of the components.

  • intent often is driven by financial motivation. Criminal elements may seek to obtain information that allows them to obtain funds directly (e.g., credit or bank account numbers) or indirectly (e.g., personal information that would allow criminals to fraudulently obtain financial accounts, to commit insurance fraud, or to sell sensitive information).

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.

  • ability to access components is not initially provisioned. Nation-state actors may perform discovery to identify vulnerable components, may try to obtain user or administrator credentials, or may seek to deploy malicious software that would allow them access to and control of the components.

  • nation-states may obfuscate their identity, posing as legitimate users, other nation-states, criminals, or activists.

  • nation-states have significant resources to implement complex or advanced attacks.

  • nation-states may act to disrupt critical infrastructure to either do physical damage or cause sociopolitical discord.

  • nation-state actors may seek to obtain intellectual property (e.g., designs, formularies, clinical research).

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.

  • ability to access components is not initially provisioned. Non-nation-state actors may perform discovery to identify vulnerable components and may seek to deploy malicious software that would allow them access to and control of the components.

  • non-nation-state actors primarily seek to further a social or political agenda.

  • attacks may seek to disrupt critical infrastructure to either do physical damage or cause sociopolitical discord.

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

Graphical user interface Description automatically generated with low confidence

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.

  • Ability to detect unauthorized hardware and software components.

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing IoT device customers with the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing IoT device customers with the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

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.

  • Ability to identify software loaded on the IoT device based on IoT device identity.

  • Ability to detect unauthorized hardware and software components.

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

  • Providing documentation detailing all the cloud services used to support the IoT device.

  • Providing a detailed description of all logical interfaces to the IoT device and documenting the interfaces used by the manufacturer’s third parties, and the purposes for such uses.

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

  • Providing details for performing the tests necessary for IoT device and related system software updates, for effectiveness and to identify potential side effects, before installation.

  • Providing communications describing the types of security and privacy tests necessary for the IoT device and software before installation.

  • Providing training and awareness information to IoT device customers that describe newly identified vulnerabilities and threats (such as zero-day malware) for the associated IoT device.

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

  • Providing the details necessary for the installation of IoT devices and associated systems security-relevant software updates within an organizationally defined time period from the vendor release of the updates.

  • Providing education describing the operational impacts of the anti-malware activities on mission critical processes in the system where the IoT device is used.

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

  • Providing education explaining the responsibilities of IoT device customers to perform their own risk assessments, using information provided by the manufacturer, to determine the risks the IoT device will bring into the IoT device customer’s systems.

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.

  • Ability to differentiate between when a device will likely operate as expected from when it may be in a degraded cybersecurity state.

  • Providing the details necessary for the installation of IoT devices and associated systems security-relevant software updates within an organizationally defined time period from the vendor release of the updates.

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.

  • Ability to uniquely identify the IoT device logically.

  • Ability to uniquely identify a remote IoT device.

  • Ability for the device to support a unique device ID (e.g., to allow it to be linked to the person or process assigned to use the IoT device).

  • Ability to configure IoT device access control policies using IoT device identity.

  • Ability to verify the identity of an IoT device.

  • Ability to add a unique physical identifier at an external or internal location on the device authorized entities can access.

  • Ability for the IoT device to hide or mask authentication information during authentication process.

  • Ability to set and change authentication configurations, policies and limitations settings for the IoT device.

  • Ability to revoke access to the device.

  • Ability to create unique IoT device user accounts.

  • Ability to identify unique IoT device user accounts.

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

  • Providing education explaining how to establish and enforce approved authorizations for logical access to IoT device information and system resources.

  • Providing education explaining how to control access to IoT devices implemented within IoT device customer information systems.

  • Providing education explaining how to enforce authorized access at the system level.

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

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device based upon the determined risk level that the device brings to the IoT customer’s system.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

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.

  • Ability to configure IoT device access control policies using IoT device identity.

    • Ability to hide IoT device identity from non-authorized entities.

    • Ability for the IoT device to differentiate between authorized and unauthorized remote users.

    • Ability for the IoT device to differentiate between authorized and unauthorized physical device users.

  • Ability to authenticate external users and systems.

  • Ability to securely interact with authorized external, third-party systems.

  • Ability to identify when an external system meets the required security requirements for a connection.

  • Ability to establish secure communications with internal systems when the device is operating on external networks.

  • Ability to establish requirements for remote access to the IoT device and/or IoT device interface, including:

    • usage restrictions

    • configuration requirements

    • connection requirements

    • manufacturer established requirement

  • Ability to enforce the established local and remote access requirements.

  • Ability to prevent external access to the IoT device management interface.

  • Ability to control the IoT device’s logical interface (e.g., locally or remotely).

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

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.

  • Ability to revoke access to the device.

  • Ability to establish access to the IoT device to perform organizationally defined user actions without identification or authentication.

  • Ability to assign roles to IoT device user accounts.

  • Ability to support a hierarchy of logical access privileges for the IoT device based on roles (e.g., admin, emergency, user, local, temporary)

    • Ability to establish user accounts to support role-based logical access privileges.

    • Ability to administer user accounts to support role-based logical access privileges.

    • Ability to use organizationally defined roles to define each user account’s access and permitted device actions.

    • Ability to support multiple levels of user/process account functionality and roles for the IoT device.

  • Ability to apply least privilege to user accounts (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions)

    • Ability to create additional processes, roles (e.g., admin, emergency, temporary) and accounts as necessary to achieve least privilege.

    • Ability to apply least privilege settings within the device (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions).

    • Ability to limit access to privileged device settings that are used to establish and administer authorization requirements.

    • Ability for authorized users to access privileged settings.

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Ability to implement dynamic access control approaches (e.g., service-oriented architectures) that rely on:

    • run-time access control decisions facilitated by dynamic privilege management.

    • organizationally defined actions to access/use device

  • Ability to allow information sharing capabilities based upon the type and/or role of user attempting to share the information.

  • Ability to restrict access to IoT device software, hardware, and data based on user account roles, used with proper authentication of the identity of the user to determine type of authorization.

  • Ability to establish pre-defined restrictions for information searches within the device.

  • Ability to establish limits on authorized concurrent device sessions for:

    • user accounts

    • roles

    • groups

    • dates

    • times

    • locations

    • mananufacture-established parameters

  • Ability to restrict updating actions to authorized entities.

  • Ability to restrict access to the cybersecurity state indicator to authorized entities.

  • Ability to enforce the established local and remote access requirements.

  • Ability to update the device’s software through remote (e.g., network download) and/or local (e.g., removable media) means.

  • Ability to store and process session identifiers.

  • Ability to identify and track sessions with identifiers.

  • Ability to enforce access to memory space through the kernel.

  • Ability to prevent a process from accessing memory space of another process.

  • Providing the tools, assistance, instructions, and other types of information to support establishing a hierarchy of role-based privileges within the IoT device.

  • Providing details about the specific types of manufacturer’s needs to access the IoT device interfaces; such as for specific support, updates, ongoing maintenance, and other purposes.

  • Providing documentation with instructions for the IoT device customer to follow for how to restrict interface connections that enable specific activities.

  • Providing descriptions of the types of access to the IoT device that the manufacturer will require on an ongoing or regular basis.

  • Providing detailed instructions for how to implement management and operational controls based on the role of the IoT device user, and not on an individual basis.

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing a detailed description of the other types of devices and systems that will access the IoT device during customer use of the device, and how they will access it.

  • Providing communications and detailed instructions for implementing a hierarchy of privilege levels to use with the IoT device and/or necessary associated information systems.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing education explaining how to establish and enforce approved authorizations for logical access to IoT device information and system resources.

  • Providing education explaining how to control access to IoT devices implemented within IoT device customer information systems.

  • Providing education explaining how to enforce authorized access at the system level.

  • Providing education and supporting materials explaining how to establish roles and responsibilities for IoT device data security, using the device capabilities and/or other services that communicate or interface with the device.

  • Providing education and supporting materials describing the IoT device capabilities for role-based controls, and how to establish different roles within the IoT device.

  • Providing education and supporting materials for how to establish roles to support IoT device policies, procedures and associated documentation.

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.

  • Ability to obtain and validate certificates.

  • Ability to identify unique users interacting with the device (to allow for user session monitoring).

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).

  • Ability to configure IoT device access control policies using IoT device identity.

    • Ability to hide IoT device identity from non-authorized entities.

    • Ability for the IoT device to differentiate between authorized and unauthorized remote users.

    • Ability for the IoT device to differentiate between authorized and unauthorized physical device users.

  • Ability for the IoT device to identify itself as an authorized entity to other devices.

  • Ability for the IoT device to require authentication prior to connecting to the device.

  • Ability for the IoT device to support a second, or more, authentication method(s) through an out-of-band path such as:

    • temporary passwords or other one-use log-on credentials

    • third-party credential checks

    • biometrics

    • text messages

    • hard tokens

    • manufacturer proprietary method

  • Ability to set the time period for how long the device will remain locked after an established configurable limit of unsuccessful login attempts has been met.

  • Ability to disable or lock access to the device after an established number of unsuccessful login attempts.

  • Ability to display and/or report the previous date and time of the last successful login authentication.

  • Ability to automatically disable accounts for the IoT device after an established period of inactivity.

    • Ability to support automatic logout of inactive accounts after a configurable established time period.

    • Ability to support automatic removal of temporary, emergency and other special use accounts after an established time period.

  • Ability to authenticate external users and systems.

  • Ability to display to IoT device users an organizationally defined system use notification message or banner prior to successful IoT device authentication.

  • Ability to create an organizationally defined system use notification message or banner to be displayed on the IoT device.

    • Ability to edit an existing IoT device display.

    • Ability to establish the maximum size (e.g., in characters, bytes) of the available device display.

  • Ability to keep the notification message or banner on the device screen until the device user actively acknowledges and agrees to the usage conditions.

  • Ability to identify authorized users and processes.

  • Ability to differentiate between authorized and unauthorized users (physical and remote).

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Ability to restrict access to IoT device software, hardware, and data based on user account roles, used with proper authentication of the identity of the user to determine type of authorization.

  • Ability to establish secure communications with internal systems when the device is operating on external networks.

  • Ability to verify and authenticate any update before installing it.

  • Providing detailed instructions and guidance for establishing activities performed by the IoT device that do not require identification or authentication.

  • Providing documentation describing the specific IoT platforms used with the device to support required IoT authentication control techniques.

  • Providing documentation with details describing external authentication by IoT platforms and associated authentication methods that can be used with the IoT device.

PR.DS-1: Data- at-rest is protected.

  • Ability to execute cryptographic mechanisms of appropriate strength and performance.

  • Ability to obtain and validate certificates.

  • Ability to perform authenticated encryption algorithms.

  • Ability to change keys securely.

  • Ability to generate key pairs.

  • Ability to store encryption keys securely.

  • Ability to cryptographically store passwords at rest, as well as device identity and other authentication data.

  • Ability to support data encryption and signing to prevent data from being altered in device storage.

  • Ability to secure data stored locally on the device.

  • Ability to secure data stored in remote storage areas (e.g., cloud, server).

  • Ability to utilize separate storage partitions for system and user data.

  • Ability to protect the audit information through:

    • encryption

    • digitally signing audit files

    • securely sending audit files to another device

    • other protections created by the device manufacturer

  • Providing detailed instructions for how to implement management and operational controls for securely handling and retaining IoT device data, associated systems data, and data output from the IoT device.

  • Providing education describing how to securely handle and retain IoT device data, associated systems data, and data output from the IoT device to meet requirements of the IoT device customers’ organizational security policies, contractual requirements, applicable Federal laws, Executive Orders, directives, policies, regulations, standards, and other legal requirements.

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.

  • Ability to execute cryptographic mechanisms of appropriate strength and performance.

  • Ability to perform authenticated encryption algorithms.

  • Ability to change keys securely.

  • Ability to store encryption keys securely.

  • Ability to secure data stored in remote storage areas (e.g., cloud, server).

  • Ability to support trusted data exchange with a specified minimum-strength cryptography algorithm.

  • Ability to support data encryption and signing to prevent data from being altered in transit.

  • Ability to utilize one or more capabilities to protect transmitted data from unauthorized access and modification.

  • Ability to use cryptographic means to validate the integrity of data transmitted.

  • Ability to protect the audit information through:

    • encryption

    • digitally signing audit files

    • securely sending audit files to another device

    • other protections created by the device manufacturer

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing education describing how to securely handle and retain IoT device data, associated systems data, and data output from the IoT device to meet requirements of the IoT device customers’ organizational security policies, contractual requirements, applicable Federal laws, Executive Orders, directives, policies, regulations, standards, and other legal requirements.

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.

  • Ability to enforce configured disk quotas.

  • Ability to provide sufficient resources to store and run the operating environment (e.g., operating systems, firmware, applications).

  • Ability to utilize file compression technologies (e.g., to protect against denial of service).

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.

  • Ability to control device responses to device input.

  • Ability to control output from the device.

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.

  • Ability to identify software loaded on the IoT device based on IoT device identity.

  • Ability to verify digital signatures.

  • Ability to run hashing algorithms.

  • Ability to perform authenticated encryption algorithms.

  • Ability to compute and compare hashes.

  • Ability to utilize one or more capabilities to protect transmitted data from unauthorized access and modification.

  • Ability to use cryptographic means to validate the integrity of data transmitted.

  • Ability to verify software updates come from valid sources by using an effective method (e.g., digital signatures, checksums, certificate validation).

  • Ability to verify and authenticate any update before installing it.

  • Ability to store the operating environment (e.g., firmware image, software, applications) in read-only media (e.g., Read Only Memory).

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing communications to IoT device customers describing how to implement management and operational controls to protect IoT device data integrity and associated systems data integrity.

  • Providing IoT device customers with the details necessary to support secure implementation of the IoT device and associated systems data integrity controls.

  • Providing IoT device customers with documentation describing the data integrity controls built into the IoT device and how to use them. If there are no data integrity controls built into the IoT device, include documentation explaining to IoT device customers the ways to achieve IoT device data integrity.

  • Providing details for how to review and update the IoT device and associated systems while preserving data 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

  • Providing education to IoT device customers covering the instructions and details necessary for them to create accurate backups and to recover the backups when necessary.

  • Providing education to IoT device customers that includes instructions describing how to back up data from systems where IoT device data is stored.

  • Providing awareness reminders and tips to IoT device customers (e.g., directly in person, in videos, in an online webinar) for various aspects involved with backing up the IoT device data.

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.

  • Ability to sanitize or purge specific or all data in the device.

  • Providing documentation describing how to irreversibly delete data from the IoT device.

  • Providing IoT device customers the details necessary for them to know when and how to remove all data from IoT devices prior to removing the devices from facilities for offsite maintenance or repairs.

  • Providing information describing how to use the IoT device capabilities to remove all data from the device.

  • Providing education that explains and/or demonstrates how to securely and irreversibly delete data from the IoT device and any associated data storage locations.

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

  • Providing communications and documentation detailing the manufacturer’s recommended vulnerability and patch management plan.

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

  • Providing details about the types of, and situations that trigger, local and/or remote maintenance activities required once the device is purchased and deployed in the organization’s digital ecosystem or within an individual consumer’s home.

  • Providing instructions and documentation describing the physical and logical access capabilities necessary to the IoT device to perform each type of maintenance activity.

  • Providing other information and actions as necessary for physically securing, and securely using, the IoT device based upon the IoT device use, purpose, and other contextual factors related to the digital ecosystem(s) within which they are intended to be used.

  • Providing the details necessary for IoT device customers to implement only organizationally approved IoT device diagnostic tools within their system.

  • Providing detailed documentation describing the tools manufacturers require for IoT device diagnostics activities.

  • Providing the details and instructions to perform necessary IoT device maintenance activities and repairs.

  • Providing communications and comprehensive documentation describing the IoT device maintenance operations performed by the manufacturer and the manufacturer’s supporting entities.

  • Providing communications and comprehensive documentation describing maintenance operations that the IoT device customer is required to perform. If such comprehensive IoT device maintenance operations documentation does not exist, the manufacturer should clearly communicate to IoT device customers that the user must perform these operations themselves.

  • Providing communications that include details for the recommended events that will trigger IoT device system reviews and/or maintenance by the manufacturer.

  • Providing communications and documentation detailing how to perform recommended local and/or remote maintenance activities.

  • Providing the details necessary to enable IoT device customers to monitor onsite and offsite IoT device maintenance activities.

  • Providing the details necessary to implement management and operational controls for IoT device maintenance personnel and associated authorizations, and record-keeping of maintenance organizations and personnel.

  • Providing communications describing the type and nature of the local and/or remote maintenance activities that will involve and require manufacturer personnel, or their contractors, once the device is purchased and deployed in the IoT device customer’s organization.

  • Providing IoT device customers with the details necessary to implement management and operational controls in support of their security policies and legal requirements for IoT device maintenance for assigned organizationally defined personnel or roles to follow.

  • Providing documented descriptions of the specific maintenance procedures for defined maintenance tasks.

  • Providing the details necessary for customers to document attempts to obtain IoT device components or IoT device information system service documentation when such documentation is either unavailable or nonexistent, and documenting the appropriate response for manufacturer employees, or supporting entities, to follow.

  • Following procedures to obtain input from IoT device customers about the breadth and depth of the technical documentation provided with the IoT device to determine if it is acceptable to support customer needs.

  • Providing a process for IoT device customers to contact the manufacturer to ask questions or obtain help related to the IoT device configuration settings.

  • Providing information to allow for in-house support from within the IoT device customer organization.

  • Providing education explaining how to inspect IoT device and/or use maintenance tools to ensure the latest software updates and patches are installed.

  • Providing education for how to scan for critical software updates and patches.

  • Providing education that explains the legal requirements governing IoT device maintenance responsibilities or how to meet specific types of legal requirements when using the IoT device.

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

  • Providing details about the types of, and situations that trigger, local and/or remote maintenance activities required once the device is purchased and deployed in the organization’s digital ecosystem or within an individual consumer’s home.

  • Providing instructions and documentation describing the physical and logical access capabilities necessary to the IoT device to perform each type of maintenance activity.

  • Providing other information and actions as necessary for physically securing, and securely using, the IoT device based upon the IoT device use, purpose, and other contextual factors related to the digital ecosystem(s) within which they are intended to be used.

  • Providing the details and instructions to perform necessary IoT device maintenance activities and repairs.

  • Providing communications and comprehensive documentation describing the IoT device maintenance operations performed by the manufacturer and the manufacturer’s supporting entities.

  • Providing communications and documentation detailing how to perform recommended local and/or remote maintenance activities.

  • Providing the details necessary to enable IoT device customers to monitor onsite and offsite IoT device maintenance activities.

  • Providing the details necessary for maintaining records for nonlocal IoT device maintenance and diagnostic activities.

  • Providing the details necessary to implement management and operational controls for IoT device maintenance personnel and associated authorizations, and record-keeping of maintenance organizations and personnel.

  • Providing communications describing the type and nature of the local and/or remote maintenance activities that will involve and require manufacturer personnel, or their contractors, once the device is purchased and deployed in the IoT device customer’s organization.

  • Providing IoT device customers with the details necessary to implement management and operational controls in support of their security policies and legal requirements for IoT device maintenance for assigned organizationally defined personnel or roles to follow.

  • Providing documented descriptions of the specific maintenance procedures for defined maintenance tasks.

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.

  • Ability to preserve system state information.

  • Ability to support a list of events that are necessary for auditing purposes (to support the organizational auditing policy).

  • Ability to identify and capture organizationally defined events using a persistent method.

  • Ability to capture information from organizationally defined cybersecurity events (e.g., cybersecurity state, time) through organizationally defined means (e.g., logs).

  • Ability to create audit logs within the device for organizationally defined and auditable events (e.g., account creation, modification, enabling, disabling, removal actions, notifications).

  • Ability to track users interacting with the device, the time they interacted with the device, the time the user logged out of the device, and to list this information in an audit log.

  • Ability to log information pertaining to:

    • the type of event that occurred

    • the time that the event occurred

    • where the event occurred

    • the source of the event

    • the outcome of the event

    • the identity of users/processes associated with the event

  • Ability to support auditing of configuration actions such as:

    • Current configuration state.

    • History of configuration changes.

    • When changes in configuration occurred.

    • Which account made the configuration change.

  • Ability to provide information as to why the device captured a particular event or set of events.

  • Ability to capture organizationally defined information to support examination of security incidents.

  • Ability to record stored data access and usage.

  • Ability to comply with organizational policy for storing persistent audit logs up to a predefined size.

  • Ability to comply with organizational policy for audit log retention period.

  • Ability to delete audit logs in accordance with organizational policy.

  • Ability to send alerts when the logs are too big for the device to continue to store (if the predefined amount of time has not yet passed to delete them).

  • Ability to support organizationally defined granularity in device timing measurements.

  • Ability to use synchronization with a verified time source to determine the validity of a time stamp.

  • Ability to record timestamps convertible to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) to support a standardized representation of timing.

  • Ability to log timing measurements outside a threshold value (e.g., enabling alerts if the device’s system time is not reliable).

  • Ability to run audit scans (automated or otherwise) to provide specific information (e.g., requested for an external process to audit the device).

  • Ability to send requested audit logs to an external audit process or information system (e.g., where its auditing information can be checked to allow review, analysis, and reporting).

  • Ability to keep an accurate internal system time.

  • Providing the details requested by IoT device customers to perform periodic checks and/or audits to ensure IoT device security controls are functioning as intended following maintenance and repairs.

  • Providing IoT device customers, upon their request, with the tools, assistance, instructions, and other support for the IoT device to perform audit and log maintenance and repairs.

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.

  • Ability to restrict use of IoT device components (e.g., ports, functions, microphones, video).

  • Ability to logically or physically disable any local and network interfaces that are not necessary for the core functionality of the device.

  • Ability to restrict use of IoT device services.

  • Ability to execute code in confined virtual environments.

  • Ability to separate IoT device processes into separate execution domains.

  • Ability to separate the levels of IoT device user functionality.

  • Ability to authorize various levels of IoT device functionality.

  • Ability to restrict components/features of the IoT device (e.g., ports, functions, protocols, services) in accordance with organizationally defined policies.

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.

  • Ability to support wireless technologies needed by the organization (e.g., microwave, packet radio, ultrahigh frequency/very high frequency]), Bluetooth, manufacturer defined).

  • Ability to support communications technologies (including but not limited to):

    • IEEE 802.11

    • Bluetooth

    • Ethernet

    • Manufacturer defined

  • Ability to establish and configure IoT device settings for wireless technologies, including authentication protocols (e.g., Extensible Authentication Protocol [EAP]/TLS, Protected Extensible Authentication Protocol [PEAP]).

  • Ability to enforce traffic flow policies.

  • Ability to utilize standardized protocols.

  • Ability to establish network connections.

  • Ability to terminate network connections (e.g., automatically based on organizationally defined parameters).

  • Ability to de-allocate Transmission Control Protocol/Internet Protocol (TCP/IP) address/port pairings.

  • Ability to establish communications channels.

  • Ability to secure the communications channels.

  • Ability to interface with Domain Name System (DNS)/DNS Security Extensions (DNSSEC).

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

  • Providing documentation describing how to implement and securely deploy monitoring devices and tools for IoT devices and associated systems.

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.

  • Ability to identify organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Providing documentation describing IoT device behavior indicators that could occur when an attack is being launched.

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.

  • Ability to monitor specific actions based on the IoT device identity.

  • Ability to access information about the IoT device’s cybersecurity state and other necessary data.

  • Ability to monitor for organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor communications traffic.

  • Providing information that describes the types of system monitoring information generated from, or associated with, the IoT device and instructions for obtaining that information.

  • Providing documentation describing the types of monitoring tools with which the IoT device is compatible, and recommendations for how to configure the IoT device to best work with such monitoring tools.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing how to perform monitoring activities.

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

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

45 C.F.R. §§
164.310(a)(2)(ii)
164.310(a)(2)(iii)

DE.CM-4: Malicious code is detected.

N/A

  • Providing education for how to implement malicious code protection in the IoT device and associated systems as well as how to detect and eradicate malicious code.

  • Providing education for how to update the IoT device and related systems malicious code protection mechanisms when new releases are available, in accordance with organizational configuration management policy and procedures.

  • If the IoT device manufacturer provides anti-malware for the associated IoT device, or if the IoT device has built-in anti-malware capabilities, the manufacturer should provide education to IoT device customers describing how to use and/or configure malicious code protection mechanisms in IoT devices, supporting anti-malware tools, and related systems.

  • Providing education that include the details necessary to implement management and operational controls for malicious code detection and eradication.

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.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor changes to the configuration settings.

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to define the characteristics of unapproved content.

  • Ability to scan files for unapproved content.

  • Ability to prevent download of unapproved content.

  • Ability to delete unapproved content.

  • Ability to take organizationally defined actions when unauthorized hardware and software components are detected (e.g., disallow a flash drive to be connected even if a Universal Serial Bus [USB] port is present).

  • Providing appropriate tools, assistance, instructions, or other details describing the capabilities for monitoring the IoT device and/or for the IoT device customer to report actions to the monitoring service of the manufacturer’s supporting entity.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing details necessary to identify unauthorized use of IoT devices and their associated systems.

  • Providing documentation that describes indicators of unauthorized use of the IoT device.

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.

  • Ability to respond to alerts according to predefined responses.

  • Ability to respond following an auditing failure (either by the device or an external auditing process).

  • Providing education describing the options and recommended responses to malicious code identification within the IoT device.

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
  • Ability to detect unauthorized hardware and software components.

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing IoT device customers with the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing IoT device customers with the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

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
  • Ability to differentiate between when a device will likely operate as expected from when it may be in a degraded cybersecurity state.

  • Providing details for performing the tests necessary for IoT device and related system software updates, for effectiveness and to identify potential side effects, before installation.

  • Providing communications describing the types of security and privacy tests necessary for the IoT device and software before installation.

  • Providing training and awareness information to IoT device customers that describe newly identified vulnerabilities and threats (such as zero-day malware) for the associated IoT device.

  • Providing the details necessary for the installation of IoT devices and associated systems security-relevant software updates within an organizationally defined time period from the vendor release of the updates.

  • Providing education describing the operational impacts of the anti-malware activities on mission critical processes in the system where the IoT device is used.

  • Providing education explaining the responsibilities of IoT device customers to perform their own risk assessments, using information provided by the manufacturer, to determine the risks the IoT device will bring into the IoT device customer’s systems.

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
  • Ability to uniquely identify the IoT device logically.

  • Ability to uniquely identify a remote IoT device.

  • Ability for the device to support a unique device ID (e.g., to allow it to be linked to the person or process assigned to use the IoT device).

  • Ability to configure IoT device access control policies using IoT device identity.

    • Ability to hide IoT device identity from non-authorized entities.

    • Ability for the IoT device to differentiate between authorized and unauthorized remote users.

    • Ability for the IoT device to differentiate between authorized and unauthorized physical device users.

  • Ability to verify the identity of an IoT device.

  • Ability to add a unique physical identifier at an external or internal location on the device authorized entities can access.

  • Ability for the IoT device to hide or mask authentication information during authentication process.

  • Ability to set and change authentication configurations, policies and limitations settings for the IoT device.

  • Ability to revoke access to the device.

  • Ability to create unique IoT device user accounts.

  • Ability to identify unique IoT device user accounts.

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Ability to authenticate external users and systems.

  • Ability to securely interact with authorized external, third-party systems.

  • Ability to identify when an external system meets the required security requirements for a connection.

  • Ability to establish secure communications with internal systems when the device is operating on external networks.

  • Ability to establish requirements for remote access to the IoT device and/or IoT device interface, including:

    • usage restrictions

    • configuration requirements

    • connection requirements

    • manufacturer established requirement

  • Ability to enforce the established local and remote access requirements.

  • Ability to prevent external access to the IoT device management interface.

  • Ability to control the IoT device’s logical interface (e.g., locally or remotely).

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to establish access to the IoT device to perform organizationally defined user actions without identification or authentication.

  • Ability to assign roles to IoT device user accounts.

  • Ability to support a hierarchy of logical access privileges for the IoT device based on roles (e.g., admin, emergency, user, local, temporary)

    • Ability to establish user accounts to support role-based logical access privileges.

    • Ability to administer user accounts to support role-based logical access privileges.

    • Ability to use organizationally defined roles to define each user account’s access and permitted device actions.

  • Ability to support multiple levels of user/process account functionality and roles for the IoT device.

  • Ability to apply least privilege to user accounts (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions)

    • Ability to create additional processes, roles (e.g., admin, emergency, temporary) and accounts as necessary to achieve least privilege.

    • Ability to apply least privilege settings within the device (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions).

    • Ability to limit access to privileged device settings that are used to establish and administer authorization requirements.

    • Ability for authorized users to access privileged settings.

  • Ability to implement dynamic access control approaches (e.g., service-oriented architectures) that rely on:

    • run-time access control decisions facilitated by dynamic privilege management.

    • Organizationally defined actions to access/use device

  • Ability to allow information sharing capabilities based upon the type and/or role of user attempting to share the information.

  • Ability to restrict access to IoT device software, hardware, and data based on user account roles, used with proper authentication of the identity of the user to determine type of authorization.

  • Ability to establish pre-defined restrictions for information searches within the device.

  • Ability to establish limits on authorized concurrent device sessions for:

    • user accounts

    • roles

    • groups

    • dates

    • times

    • locations

    • manufacturer-established parameters

  • Ability to restrict updating actions to authorized entities.

  • Ability to restrict access to the cybersecurity state indicator to authorized entities.

  • Ability to enforce the established local and remote access requirements.

  • Ability to update the device’s software through remote (e.g., network download) and/or local (e.g., removable media) means.

  • Ability to store and process session identifiers.

  • Ability to identify and track sessions with identifiers.

  • Ability to enforce access to memory space through the kernel.

  • Ability to prevent a process from accessing memory space of another process.

  • Ability to obtain and validate certificates.

  • Ability to identify unique users interacting with the device (to allow for user session monitoring).

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

  • Providing education explaining how to establish and enforce approved authorizations for logical access to IoT device information and system resources.

  • Providing education explaining how to control access to IoT devices implemented within IoT device customer information systems.

  • Providing education explaining how to enforce authorized access at the system level.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device based upon the determined risk level that the device brings to the IoT customer’s system.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing the tools, assistance, instructions, and other types of information to support establishing a hierarchy of role-based privileges within the IoT device.

  • Providing details about the specific types of manufacturer’s needs to access the IoT device interfaces; such as for specific support, updates, ongoing maintenance, and other purposes.

  • Providing documentation with instructions for how to restrict interface connections that enable specific activities.

  • Providing descriptions of the types of access to the IoT device that the manufacturer will require on an ongoing or regular basis.

  • Providing detailed instructions for how to implement management and operational controls based on the role of the IoT device user, and not on an individual basis.

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing a detailed description of the other types of devices and systems that will access the IoT device during customer use of the device, and how they will access it.

  • Providing communications and detailed instructions for implementing a hierarchy of privilege levels to use with the IoT device and/or necessary associated information systems.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing education and supporting materials explaining how to establish roles and responsibilities for IoT device data security, using the device capabilities and/or other services that communicate or interface with the device.

  • Providing education and supporting materials describing the IoT device capabilities for role-based controls, and how to establish different roles within the IoT device.

  • Providing education and supporting materials for how to establish roles to support IoT device policies, procedures and associated documentation.

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
  • Ability to uniquely identify the IoT device logically.

  • Ability to uniquely identify a remote IoT device.

  • Ability for the device to support a unique device ID (e.g., to allow it to be linked to the person or process assigned to use the IoT device).

  • Ability to configure IoT device access control policies using IoT device identity.

    • Ability to hide IoT device identity from non-authorized entities.

    • Ability for the IoT device to differentiate between authorized and unauthorized remote users.

    • Ability for the IoT device to differentiate between authorized and unauthorized physical device users.

  • Ability to verify the identity of an IoT device.

  • Ability to add a unique physical identifier at an external or internal location on the device authorized entities can access.

  • Ability for the IoT device to hide or mask authentication information during authentication process.

  • Ability to set and change authentication configurations, policies and limitations settings for the IoT device.

  • Ability to revoke access to the device.

  • Ability to create unique IoT device user accounts.

  • Ability to identify unique IoT device user accounts.

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Ability to authenticate external users and systems.

  • Ability to securely interact with authorized external, third-party systems.

  • Ability to identify when an external system meets the required security requirements for a connection.

  • Ability to establish secure communications with internal systems when the device is operating on external networks.

  • Ability to establish requirements for remote access to the IoT device and/or IoT device interface, including:

    • usage restrictions

    • configuration requirements

    • connection requirements

    • manufacturer established requirement

  • Ability to enforce the established local and remote access requirements.

  • Ability to prevent external access to the IoT device management interface.

  • Ability to control the IoT device’s logical interface (e.g., locally or remotely).

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to establish access to the IoT device to perform organizationally defined user actions without identification or authentication.

  • Ability to assign roles to IoT device user accounts.

  • Ability to support a hierarchy of logical access privileges for the IoT device based on roles (e.g., admin, emergency, user, local, temporary)

    • Ability to establish user accounts to support role-based logical access privileges.

    • Ability to administer user accounts to support role-based logical access privileges.

    • Ability to use organizationally defined roles to define each user account’s access and permitted device actions.

  • Ability to support multiple levels of user/process account functionality and roles for the IoT device.

  • Ability to apply least privilege to user accounts (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions)

    • Ability to create additional processes, roles (e.g., admin, emergency, temporary) and accounts as necessary to achieve least privilege.

    • Ability to apply least privilege settings within the device (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions).

    • Ability to limit access to privileged device settings that are used to establish and administer authorization requirements.

    • Ability for authorized users to access privileged settings.

  • Ability to implement dynamic access control approaches (e.g., service-oriented architectures) that rely on:

    • run-time access control decisions facilitated by dynamic privilege management.

    • Organizationally defined actions to access/use device

  • Ability to allow information sharing capabilities based upon the type and/or role of user attempting to share the information.

  • Ability to restrict access to IoT device software, hardware, and data based on user account roles, used with proper authentication of the identity of the user to determine type of authorization.

  • Ability to establish pre-defined restrictions for information searches within the device.

  • Ability to establish limits on authorized concurrent device sessions for:

    • user accounts

    • roles

    • groups

    • dates

    • times

    • locations

    • manufacturer-established parameters

  • Ability to restrict updating actions to authorized entities.

  • Ability to restrict access to the cybersecurity state indicator to authorized entities.

  • Ability to enforce the established local and remote access requirements.

  • Ability to update the device’s software through remote (e.g., network download) and/or local (e.g., removable media) means.

  • Ability to store and process session identifiers.

  • Ability to identify and track sessions with identifiers.

  • Ability to enforce access to memory space through the kernel.

  • Ability to prevent a process from accessing memory space of another process.

  • Ability to obtain and validate certificates.

  • Ability to identify unique users interacting with the device (to allow for user session monitoring).

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

  • Providing education explaining how to establish and enforce approved authorizations for logical access to IoT device information and system resources.

  • Providing education explaining how to control access to IoT devices implemented within IoT device customer information systems.

  • Providing education explaining how to enforce authorized access at the system level.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device based upon the determined risk level that the device brings to the IoT customer’s system.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing the tools, assistance, instructions, and other types of information to support establishing a hierarchy of role-based privileges within the IoT device.

  • Providing details about the specific types of manufacturer’s needs to access the IoT device interfaces; such as for specific support, updates, ongoing maintenance, and other purposes.

  • Providing documentation with instructions for how to restrict interface connections that enable specific activities.

  • Providing descriptions of the types of access to the IoT device that the manufacturer will require on an ongoing or regular basis.

  • Providing detailed instructions for how to implement management and operational controls based on the role of the IoT device user, and not on an individual basis.

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing a detailed description of the other types of devices and systems that will access the IoT device during customer use of the device, and how they will access it.

  • Providing communications and detailed instructions for implementing a hierarchy of privilege levels to use with the IoT device and/or necessary associated information systems.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing education and supporting materials explaining how to establish roles and responsibilities for IoT device data security, using the device capabilities and/or other services that communicate or interface with the device.

  • Providing education and supporting materials describing the IoT device capabilities for role-based controls, and how to establish different roles within the IoT device.

  • Providing education and supporting materials for how to establish roles to support IoT device policies, procedures and associated documentation.

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
  • Ability to uniquely identify the IoT device logically.

  • Ability to uniquely identify a remote IoT device.

  • Ability for the device to support a unique device ID (e.g., to allow it to be linked to the person or process assigned to use the IoT device).

  • Ability to configure IoT device access control policies using IoT device identity.

    • Ability to hide IoT device identity from non-authorized entities.

    • Ability for the IoT device to differentiate between authorized and unauthorized remote users.

    • Ability for the IoT device to differentiate between authorized and unauthorized physical device users.

  • Ability to verify the identity of an IoT device.

  • Ability to add a unique physical identifier at an external or internal location on the device authorized entities can access.

  • Ability for the IoT device to hide or mask authentication information during authentication process.

  • Ability to set and change authentication configurations, policies and limitations settings for the IoT device.

  • Ability to revoke access to the device.

  • Ability to create unique IoT device user accounts.

  • Ability to identify unique IoT device user accounts.

  • Ability to create organizationally defined accounts that support privileged roles with automated expiration conditions.

  • Ability to establish organizationally defined user actions for accessing the IoT device and/or device interface.

  • Ability to enable automation and reporting of account management activities.

    • Ability to assign access to IoT device audit controls to specific roles or organizationally defined personnel.

    • Ability to control access to IoT device audit data.

    • Ability to identify the user, process or device requesting access to the audit/accountability information (i.e., to ensure only authorized users and/or devices have access).

  • Ability to establish conditions for shared/group accounts on the IoT device.

  • Ability to administer conditions for shared/group accounts on the IoT device.

  • Ability to restrict the use of shared/group accounts on the IoT device according to organizationally defined conditions.

  • Ability to authenticate external users and systems.

  • Ability to securely interact with authorized external, third-party systems.

  • Ability to identify when an external system meets the required security requirements for a connection.

  • Ability to establish secure communications with internal systems when the device is operating on external networks.

  • Ability to establish requirements for remote access to the IoT device and/or IoT device interface, including:

    • usage restrictions

    • configuration requirements

    • connection requirements

    • manufacturer established requirement

  • Ability to enforce the established local and remote access requirements.

  • Ability to prevent external access to the IoT device management interface.

  • Ability to control the IoT device’s logical interface (e.g., locally or remotely).

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to establish access to the IoT device to perform organizationally defined user actions without identification or authentication.

  • Ability to assign roles to IoT device user accounts.

  • Ability to support a hierarchy of logical access privileges for the IoT device based on roles (e.g., admin, emergency, user, local, temporary)

    • Ability to establish user accounts to support role-based logical access privileges.

    • Ability to administer user accounts to support role-based logical access privileges.

    • Ability to use organizationally defined roles to define each user account’s access and permitted device actions.

  • Ability to support multiple levels of user/process account functionality and roles for the IoT device.

  • Ability to apply least privilege to user accounts (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions)

    • Ability to create additional processes, roles (e.g., admin, emergency, temporary) and accounts as necessary to achieve least privilege.

    • Ability to apply least privilege settings within the device (i.e., to ensure that the processes operate at privilege levels no higher than necessary to accomplish required functions).

    • Ability to limit access to privileged device settings that are used to establish and administer authorization requirements.

    • Ability for authorized users to access privileged settings.

  • Ability to implement dynamic access control approaches (e.g., service-oriented architectures) that rely on:

    • run-time access control decisions facilitated by dynamic privilege management.

    • Organizationally defined actions to access/use device

  • Ability to allow information sharing capabilities based upon the type and/or role of user attempting to share the information.

  • Ability to restrict access to IoT device software, hardware, and data based on user account roles, used with proper authentication of the identity of the user to determine type of authorization.

  • Ability to establish pre-defined restrictions for information searches within the device.

  • Ability to establish limits on authorized concurrent device sessions for:

    • user accounts

    • roles

    • groups

    • dates

    • times

    • locations

    • manufacturer-established parameters

  • Ability to restrict updating actions to authorized entities.

  • Ability to restrict access to the cybersecurity state indicator to authorized entities.

  • Ability to enforce the established local and remote access requirements.

  • Ability to update the device’s software through remote (e.g., network download) and/or local (e.g., removable media) means.

  • Ability to store and process session identifiers.

  • Ability to identify and track sessions with identifiers.

  • Ability to enforce access to memory space through the kernel.

  • Ability to prevent a process from accessing memory space of another process.

  • Ability to obtain and validate certificates.

  • Ability to identify unique users interacting with the device (to allow for user session monitoring).

  • Providing details for how to establish unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing the details necessary to establish and implement unique identification for each IoT device associated with the system and critical system components within which it is used.

  • Providing the details necessary to require unique identifiers for each IoT device associated with the system and critical system components within which it is used.

  • Providing education explaining how to establish and enforce approved authorizations for logical access to IoT device information and system resources.

  • Providing education explaining how to control access to IoT devices implemented within IoT device customer information systems.

  • Providing education explaining how to enforce authorized access at the system level.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device based upon the determined risk level that the device brings to the IoT customer’s system.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing the tools, assistance, instructions, and other types of information to support establishing a hierarchy of role-based privileges within the IoT device.

  • Providing details about the specific types of manufacturer’s needs to access the IoT device interfaces; such as for specific support, updates, ongoing maintenance, and other purposes.

  • Providing documentation with instructions for how to restrict interface connections that enable specific activities.

  • Providing descriptions of the types of access to the IoT device that the manufacturer will require on an ongoing or regular basis.

  • Providing detailed instructions for how to implement management and operational controls based on the role of the IoT device user, and not on an individual basis.

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing a detailed description of the other types of devices and systems that will access the IoT device during customer use of the device, and how they will access it.

  • Providing communications and detailed instructions for implementing a hierarchy of privilege levels to use with the IoT device and/or necessary associated information systems.

  • Providing communications and documentation detailing how to perform account management activities, using the technical IoT device capabilities, or through supporting systems and/or tools.

  • Providing education and supporting materials explaining how to establish roles and responsibilities for IoT device data security, using the device capabilities and/or other services that communicate or interface with the device.

  • Providing education and supporting materials describing the IoT device capabilities for role-based controls, and how to establish different roles within the IoT device.

  • Providing education and supporting materials for how to establish roles to support IoT device policies, procedures and associated documentation.

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
  • Ability to monitor specific actions based on the IoT device identity.

  • Ability to access information about the IoT device’s cybersecurity state and other necessary data.

  • Ability to monitor for organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor communications traffic.

  • Ability to monitor changes to the configuration settings.

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to define the characteristics of unapproved content.

  • Ability to scan files for unapproved content.

  • Ability to prevent download of unapproved content.

  • Ability to delete unapproved content.

  • Ability to take organizationally defined actions when unauthorized hardware and software components are detected (e.g., disallow a flash drive to be connected even if a Universal Serial Bus [USB] port is present).

  • Providing information that describes the types of system monitoring information generated from, or associated with, the IoT device and instructions for obtaining that information.

  • Providing documentation describing the types of monitoring tools with which the IoT device is compatible, and recommendations for how to configure the IoT device to best work with such monitoring tools.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing how to perform monitoring activities.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing education for how to implement malicious code protection in the IoT device and associated systems as well as how to detect and eradicate malicious code.

  • Providing education for how to update the IoT device and related systems malicious code protection mechanisms when new releases are available, in accordance with organizational configuration management policy and procedures.

  • If the IoT device manufacturer provides anti-malware for the associated IoT device, or if the IoT device has built-in anti-malware capabilities, the manufacturer should provide education to IoT device customers describing how to use and/or configure malicious code protection mechanisms in IoT devices, supporting anti-malware tools, and related systems.

  • Providing education that include the details necessary to implement management and operational controls for malicious code detection and eradication.

  • Providing appropriate tools, assistance, instructions, or other details describing the capabilities for monitoring the IoT device and/or for the IoT device customer to report actions to the monitoring service of the manufacturer’s supporting entity.

  • Providing documentation describing details necessary to identify unauthorized use of IoT devices and their associated systems.

  • Providing documentation that describes indicators of unauthorized use of the IoT device.

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
  • Ability to monitor specific actions based on the IoT device identity.

  • Ability to access information about the IoT device’s cybersecurity state and other necessary data.

  • Ability to monitor for organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor communications traffic.

  • Ability to monitor changes to the configuration settings.

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to define the characteristics of unapproved content.

  • Ability to scan files for unapproved content.

  • Ability to prevent download of unapproved content.

  • Ability to delete unapproved content.

  • Ability to take organizationally defined actions when unauthorized hardware and software components are detected (e.g., disallow a flash drive to be connected even if a Universal Serial Bus [USB] port is present).

  • Providing information that describes the types of system monitoring information generated from, or associated with, the IoT device and instructions for obtaining that information.

  • Providing documentation describing the types of monitoring tools with which the IoT device is compatible, and recommendations for how to configure the IoT device to best work with such monitoring tools.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing how to perform monitoring activities.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing education for how to implement malicious code protection in the IoT device and associated systems as well as how to detect and eradicate malicious code.

  • Providing education for how to update the IoT device and related systems malicious code protection mechanisms when new releases are available, in accordance with organizational configuration management policy and procedures.

  • If the IoT device manufacturer provides anti-malware for the associated IoT device, or if the IoT device has built-in anti-malware capabilities, the manufacturer should provide education to IoT device customers describing how to use and/or configure malicious code protection mechanisms in IoT devices, supporting anti-malware tools, and related systems.

  • Providing education that include the details necessary to implement management and operational controls for malicious code detection and eradication.

  • Providing appropriate tools, assistance, instructions, or other details describing the capabilities for monitoring the IoT device and/or for the IoT device customer to report actions to the monitoring service of the manufacturer’s supporting entity.

  • Providing documentation describing details necessary to identify unauthorized use of IoT devices and their associated systems.

  • Providing documentation that describes indicators of unauthorized use of the IoT device.

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
  • Ability to monitor specific actions based on the IoT device identity.

  • Ability to access information about the IoT device’s cybersecurity state and other necessary data.

  • Ability to monitor for organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor communications traffic.

  • Ability to monitor changes to the configuration settings.

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to define the characteristics of unapproved content.

  • Ability to scan files for unapproved content.

  • Ability to prevent download of unapproved content.

  • Ability to delete unapproved content.

  • Ability to take organizationally defined actions when unauthorized hardware and software components are detected (e.g., disallow a flash drive to be connected even if a Universal Serial Bus [USB] port is present).

  • Providing information that describes the types of system monitoring information generated from, or associated with, the IoT device and instructions for obtaining that information.

  • Providing documentation describing the types of monitoring tools with which the IoT device is compatible, and recommendations for how to configure the IoT device to best work with such monitoring tools.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing how to perform monitoring activities.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing education for how to implement malicious code protection in the IoT device and associated systems as well as how to detect and eradicate malicious code.

  • Providing education for how to update the IoT device and related systems malicious code protection mechanisms when new releases are available, in accordance with organizational configuration management policy and procedures.

  • If the IoT device manufacturer provides anti-malware for the associated IoT device, or if the IoT device has built-in anti-malware capabilities, the manufacturer should provide education to IoT device customers describing how to use and/or configure malicious code protection mechanisms in IoT devices, supporting anti-malware tools, and related systems.

  • Providing education that include the details necessary to implement management and operational controls for malicious code detection and eradication.

  • Providing appropriate tools, assistance, instructions, or other details describing the capabilities for monitoring the IoT device and/or for the IoT device customer to report actions to the monitoring service of the manufacturer’s supporting entity.

  • Providing documentation describing details necessary to identify unauthorized use of IoT devices and their associated systems.

  • Providing documentation that describes indicators of unauthorized use of the IoT device.

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
  • Ability to monitor specific actions based on the IoT device identity.

  • Ability to access information about the IoT device’s cybersecurity state and other necessary data.

  • Ability to monitor for organizationally defined cybersecurity events (e.g., expected state change) that may occur on or involving the IoT device.

  • Ability to support a monitoring process to check for disclosure of organizational information to unauthorized entities. (The device may be able to perform this check itself or provide the information necessary for an external process to check).

  • Ability to monitor communications traffic.

  • Ability to monitor changes to the configuration settings.

  • Ability to detect remote activation attempts.

  • Ability to detect remote activation of a collaborative computing device/component (e.g., microphone, camera).

  • Ability to detect remote activation of sensors.

  • Ability to define the characteristics of unapproved content.

  • Ability to scan files for unapproved content.

  • Ability to prevent download of unapproved content.

  • Ability to delete unapproved content.

  • Ability to take organizationally defined actions when unauthorized hardware and software components are detected (e.g., disallow a flash drive to be connected even if a Universal Serial Bus [USB] port is present).

  • Providing information that describes the types of system monitoring information generated from, or associated with, the IoT device and instructions for obtaining that information.

  • Providing documentation describing the types of monitoring tools with which the IoT device is compatible, and recommendations for how to configure the IoT device to best work with such monitoring tools.

  • Providing the details necessary to monitor IoT devices and associated systems.

  • Providing documentation describing how to perform monitoring activities.

  • Providing descriptions of the types of physical access practices, and manufacturer suggested hardware or other types of devices, that can be used to prevent unauthorized physical access to the IoT device.

  • Providing descriptions of the physical access security procedures the manufacturer recommends for limiting physical access to the device and to associated device controls.

  • Providing details of indications, and recommendations for how to determine, when unauthorized physical access to the IoT device was or is attempted or is occurring.

  • Providing education for how to implement malicious code protection in the IoT device and associated systems as well as how to detect and eradicate malicious code.

  • Providing education for how to update the IoT device and related systems malicious code protection mechanisms when new releases are available, in accordance with organizational configuration management policy and procedures.

  • If the IoT device manufacturer provides anti-malware for the associated IoT device, or if the IoT device has built-in anti-malware capabilities, the manufacturer should provide education to IoT device customers describing how to use and/or configure malicious code protection mechanisms in IoT devices, supporting anti-malware tools, and related systems.

  • Providing education that include the details necessary to implement management and operational controls for malicious code detection and eradication.

  • Providing appropriate tools, assistance, instructions, or other details describing the capabilities for monitoring the IoT device and/or for the IoT device customer to report actions to the monitoring service of the manufacturer’s supporting entity.

  • Providing documentation describing details necessary to identify unauthorized use of IoT devices and their associated systems.

  • Providing documentation that describes indicators of unauthorized use of the IoT device.

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

  • Ability to execute cryptographic mechanisms of appropriate strength and performance.

  • Ability to perform authenticated encryption algorithms.

  • Ability to change keys securely.

  • Ability to store encryption keys securely.

  • Ability to secure data stored in remote storage areas (e.g., cloud, server).

  • Ability to support trusted data exchange with a specified minimum-strength cryptography algorithm.

  • Ability to support data encryption and signing to prevent data from being altered in transit.

  • Ability to utilize one or more capabilities to protect transmitted data from unauthorized access and modification.

  • Ability to use cryptographic means to validate the integrity of data transmitted.

  • Ability to protect the audit information through:

    • encryption

    • digitally signing audit files

    • securely sending audit files to another device

    • other protections created by the device manufacturer

  • Providing documentation and/or other communications describing how to implement management and operational controls to protect data obtained from IoT devices and associated systems from unauthorized access, modification, and deletion.

  • Providing education describing how to securely handle and retain IoT device data, associated systems data, and data output from the IoT device to meet requirements of the IoT device customers’ organizational security policies, contractual requirements, applicable Federal laws, Executive Orders, directives, policies, regulations, standards, and other legal requirements.

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]

../_images/image11.png

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].