In two recent blogs, we have discussed how the Internet of Things (“IoT”) has become the mIoT—that is, the medical Internet of Things―and what this development means for HIPAA compliance. The most recent post discussed risks inherent in the IoT. To help you in your efforts at reducing mIoT risks, this post will discuss some of the security measures that you may want to consider in the final part of your risk analysis, selecting reasonable and appropriate, cost-effective security measures for IoT devices and data after you have inventoried them and identified risks to them.

By way of review, the draft National Institute of Standards and Technology (“NIST”) Special Publication (SP) 800-37 Revision 2 defines risk as “a measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of: (i) the adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence.” For cybersecurity, risk is about exploitation of vulnerabilities to compromise the device or data confidentiality, integrity, or availability. For privacy, risk is about problematic data actions—operations that process personally identifiable information (“PII”) through the information lifecycle and as a side effect cause individuals to experience some type of problem(s).

IoT devices generally face the same types of cybersecurity and privacy risks as conventional IT devices, though the prevalence and severity of such risks often differ. NIST explores considerations that may affect the management of cybersecurity and privacy risks for IoT devices, in most cases because mitigating the risks using conventional IT controls may not be feasible or effective. Although each IoT device in its particular environment will have its own set of risk considerations, common risk considerations can be stated at a more general level to help guide risk management.

The Internet of Things Security Foundation sets forth principles for IoT security at https://iotsecurityfoundation.org/wp-content/uploads/2015/09/IoTSF-Establishing-Principles-for-IoT-Security-Download.pdf. These principles fall into the following categories, with the correlation to relevant HIPAA requirements following:

• Does the data need to be private? The entire Privacy Rule requires data to be private.
• Does the data need to be trusted? The Data Backup Plan § 164.308(a)(7)(ii)(A), the Integrity Standard 164.312(c)(2), and controls implementation specification § 164.312(e)(2)(i) relate to this principle.
• Is the safe and/or timely arrival of data important? The Emergency Access Procedure 164.312(a)(2)(ii), the Device and Media Controls § 164.310(d)(1), and the Contingency Operations § 164.310(a)(2)(i) speak to this principle.
• Is it necessary to restrict access to or control of the device? The Workforce Security Standard 164.308(a)(3)(i) and its three implementation specifications, Authorization and/or Supervision, Workforce Clearance Procedure, and Termination Procedures, relate to this principle, as do the Information Access Management Standard § 164.308(a)(4)(i) and the Access Authorization and Access Establishment and Modification implementation specifications of § 164.308(a)(4)(ii)(B) and (c), the Facility Access Standard § 164.308(a)(4)(ii)(B), the Access Control and Validation Procedures implementation specification § 164.310(a)(2)(iii), the Workstation Security Standard § 164.310(c), the technical security’s Access Control Standard § 164.312(a)(1) with its Unique User Identification § 164.312(a)(2)(i), Emergency Access Procedure § 164.312(a)(2)(ii), Automatic Logoff § 164.312(a)(2)(iii), and Encryption and Decryption § 164.312(a)(2)(iv) implementation specifications.
• Is it necessary to update the software on the device? The Evaluation Standard 164.308(a)(8) would seem to address this principle.
• Will ownership of the device need to be managed or transferred in a secure manner? The Termination Procedures 164.308(a)(3)(ii)(C) and the Device and Media Controls § 164.310(d)(1) requirements address this principle.
• Does the data need to be audited? The Information Systems Activity Review 164.308(a)(1)(ii)(D) and Audit Controls § 164.312(b) relate to this principle.

Turning to the first principle, it would seem to be a no-brainer for health information as defined by HIPAA to include financial, demographic, and lifestyle information, as well as clinical data. The IoT Security Foundation specifies that this principle requires that the relevant information be designed with security, appropriate to the threat and device capability, in mind from the outset. This requirement means that the security measures should be designed at the outset and not retrofitted later and that consideration should be given to the intended use of the data and what security is appropriate―that is,  reasonable and appropriate to use HIPAA’s language. Also, the IoT system must offer appropriate protection for all potential attack surfaces, such as, for example, device, network, server, cloud, and so forth. This requirement simply means to ensure that the security of the data will be maintained throughout the whole network.

The Foundation also believes that you must inform users what private data is required in order for the device to function. Users want to take advantage of the opportunities offered by IoT, but also want to ensure that their privacy is protected. You should be clear about what private data you are handling and what the impact of denying this capability will be.

Again, it goes without saying that the data must be trusted. Data may need to be protected from tampering and modification in transit. This threat may be a malicious attacker or simply poorly configured devices mishandling data. Security appropriate to this concern is that the integrity of software must be ensured, that authentication and integrity protections are applied, and that compromised or malfunctioning devices are identified and revoked.

Safe and timely arrival is obviously important, particularly in the emergency department. Among the Foundation’s suggestions in this area are time-stamping the data so that users can be assured that it is current and providing both status monitoring and failure handling to identify and remedy unavailability when it occurs.

Prevention of unauthorized access or control is crucial to preserve data integrity, availability, and confidentiality and to prevent misuse. Security measures for this area include designing defenses against hacking from the outset, considering potential attacks during the design stage to ensure that the device’s security functionality is built on a solid foundation and to reduce the risk of serious security architecture issues emerging later in development, and incorporating secure coding standards, penetration testing, and so forth.

Updating software, if nothing more than the security software, is also important. New threats probably occur more in IoT threats than in other software. IT personnel should apply security patches/updates in a timely fashion without impacting the functionality of the device. They should use only authenticated sources to provide security updates or patches.

If the IoT device or media will be transferred to another user, you don’t want it to contain your electronic protected health information (“EPHI”). Thus, consistent with the HIPAA requirement for a destruction plan, the original owner must provide a secure method to transfer ownership of the device to another user.

Finally, consistent with the audit principle, IoT services may be required to meet a user audit, an enterprise―that is, across the entire organization―audit, or a regulatory audit requirement and, consistent with the HIPAA audit rules, may be required to be prepared to meet all three.

The foregoing are certainly not a complete recital of all of the security measures necessary to comply with these principles but should alert security personnel to critical IoT security principles as envisioned by the Internet of Things Security Foundation, especially in regard to reducing risks in the medical IoT.

Alice here: Yes, once again, I am here to try to sell things to keep you and us in business. If you need help with your risk analysis, either initially or for an update, Jon Tomes has written a Risk Analysis ToolKit to provide the structure and tools to help you complete the requirement under HIPAA. You and your risk analysis team can fill it out and document your decisions as to what is reasonable and appropriate for you to adopt in the way of policies and procedures and be done with it. Or you could send your completed risk analysis to Jon to review and render his professional opinion as the country’s leading HIPAA expert (IMO) as to whether it is sufficient to keep you from getting that free trip to Leavenworth or that very expensive trip to the bank. If you have Jon’s Compliance Guide to HIPAA and the DHHS Regulations, 6^th edition, with the accompanying HIPAA Documents Resources Center CD, also 6^th edition, you can find the Risk Analysis ToolKit on the CD. It is also available with a review by Jon at https://www.veteranspress.com/product/hipaa-risk-analysis-toolkit. Also, Jon Tomes presented a webinar earlier this month on “How to Do a HIPAA and HITECH Risk Analysis.” You can buy a recording of it at https://www.complianceiq.com/trainings/LiveWebinar/2255/how-to-do-a-hipaa-and-hitech-risk-analysis. Jon is also writing a Risk Analysis Update ToolKit, which will be available for you in the near future on our Premium Member section of our website. Please stay tuned for our announcement when it is up and running for you there. It will include the mIoT.

If you need guidance on how to draft the policies and procedures that your risk analysis or your newly updated risk analysis has shown are reasonable and appropriate for your organization, Jon has also written The Complete HIPAA Policies and Procedures Guide, with the accompanying CD of several dozen HIPAA policies and procedures templates for you to adapt to your situation.

Make sure that you train your entire workforce on HIPAA in general and on the HIPAA policies and procedures according to who needs to know what to perform their duties for you. If you need handy HIPAA training in general, consider Jon’s training video and training manual in either of two forms available here: https://www.veteranspress.com/product/basic-hipaa-training-video-dvd-workbook or https://www.veteranspress.com/product/online-hipaa-training-video-certification. Or you could hire Jon to present HIPAA training onsite to your workforce. Just contact him at jon@veteranspress.com or 816-527-3858.

Keep your written documentation of all of these HIPAA compliance efforts where you can find them easily and quickly if HHS shows up demanding your HIPAA compliance documentation. We recommend keeping all of it in Your Happy HIPAA Book. Jon included tabs in the three-ring binder for everything that you need to document and a checklist for each tab. I recommend adding the date that you check off each item in each checklist.

If you have had a security incident that you were unsure as to what exactly to do about, or if you are concerned that you may have one, consider reading Jon’s book How to Handle HIPAA and HITECH Act Breaches, Complaints, and Investigations: Everything You Need to Know.

As always, thanks for reading Jon’s blog, buying his books and other HIPAA compliance tools, attending our seminars and webinars, and hiring Jon for HIPAA consulting and training. We wish you every success with your HIPAA compliance efforts.

Check this blog for more on this area—that is, the risks inherent in the mIoT and possible security measures. We plan to keep you up to date as issues develop.