Security Best Practices: From IoT to HIPAA

Thomson Comer, Staff Engineer

A couple weeks ago, Kevin Gross posted about the myth of a hacker-proof IoT. His post gave a great high-level overview of ways to make the IoT as secure as possible, and it got me thinking about some more in-depth methods for attempting to attain the security we crave in the IoT industry, especially where regulations like the Health Insurance Portability and Accountability Act (HIPAA) are concerned.

There is a set of best practices that most IoT and software companies and products typically use, and they tend to be enforced via two mechanisms: cryptography and access control. Cryptography governs the state of data in any medium, and access control, in general, exposes access. This can mean access to existing resources, to the public key used for decryption, to account management, and to data at rest.

Consideration for implementing cryptography and access control needs to be taken for every piece of equipment connected to a network. I want to try to break it down a little bit here.

Cryptography

Data in motion should be always-(be)-encrypted (AE). Data at rest does not require constant encryption unless it is predicated by government rules and regulations, for example HIPAA regulations for protecting healthcare information, which we will talk more about later. Let’s start by looking at some ways that data in motion can be ensured to be AE.shutterstock_1228072

Client-Server Communication

Production traffic between clients and servers should always, without fail, contain only encrypted information. The only time that unencrypted HTTP should be used is during development or QA. Any production system should use HTTPS instead of HTTP.

Production systems should always use signed certificates with HTTPS. HTTP should be permissible for local, development, and QA traffic only. Websocket connections should also only be established over HTTPS.

SSH Tunneling

Developers who use a native socket should investigate using SSH tunneling in order to encrypt port traffic. This is one of the easiest ways to get solid and secure socket traffic and protects you from any need to roll your own.

Native Sockets

Public-key cryptography should be used with all native socket connections between network-connected machines. The only time that unencrypted socket traffic should be permissible in development practice is port-to-port on same machine. This is the most difficult hole to enforce, and the most likely area to leak sensitive information against a dedicated attacker. IoT devices in particular are in danger to this kind of security hole.

Email

Email is not encrypted, folks! Sensitive information should never be transmitted via email, unless you and the recipient are practiced in PGP or other kinds of email encryption. Different providers implement different levels of security around email. Gmail now provides HIPAA compliance for email. Even that HIPAA guarantee can only be made for services within Google, exclusively. If you email a patient at random-email-server.com, HIPAA security has been compromised. This is why it is illegal for any electronic patient health information (ePHI) to be transmitted via email.

Access Control

Access Control usually governs how we gain access to the administrative tools that track, deploy, and maintain our various software and hardware systems. Server shells, database instances, logging sites, key management, web hosting, and many more are primarily affected by how we implement secure access control. Any system with production-level access that supports multi-factor authentication should enable it. Any system that supports public-key cryptography for access control should use that method exclusively (SSH, some databases).

IoT devices in particular should try to use public-key cryptography for all access control—don’t rely on usernames and passwords, because eventually a module with root access will get leaked. If your device was designed to be administered via telnet, place the telnet port behind an OS firewall and provide access to it via SSH.

HIPAA Requirements

HIPAA regulations in my experience generally govern cryptography requirements. Access control isn’t nationally standardized, but is always improving. Because we have worked on some healthcare-based applications and products here at Cardinal Peak, we are well-versed on how to maintain HIPAA compliance.

HIPAA compliance means that no user-specific data is visible in our network traffic, logs, or communications (email). User-specific data includes email addresses, names, dates of birth, SSN, address, insurance information, and diagnostic information. These types of information should never appear in clear text in unsecured logs or emails. Communication about specific accounts generally must use a user ID or account ID, which is not considered ePHI.

HIPAA compliance also requires transparency and accountability toward potential errors. It is highly likely that during development, ePHI can be leaked on an insecure channel. Each suspected leak of ePHI, regardless of whether it was accessed by unauthorized parties, must be reported to HIPAA. Failure to report insecure ePHI data can result in hefty fines.

Following these guidelines is imperative for any company or individual working with patient health information, as it is always governed under the HIPAA regulations.

Don’t Roll Your Own

It has been said before, keep saying it. If you can’t use HTTPS, look closely into SSH tunnelling. It offers unprecedented security for any network traffic.

Conclusion

Your IoT business needs to have a security standards document that specifies what technologies should or must be used to secure network-connected devices. This document should detail requirements for both access control and cryptography. New developers should review the security standards document and be expected to adhere to it. Your company’s survival depends on it. The basic requirement for any network programming is that you should not be transmitting production data that is not encrypted, at any time.

Cardinal Peak
Learn more about our Audio & Video capabilities.

Dive deeper into our IoT portfolio

Take a look at the clients we have helped.

We’re always looking for top talent, check out our current openings. 

Contact Us

Please fill out the contact form below and our engineering services team will be in touch soon.

We rely on Cardinal Peak for their ability to bolster our patent licensing efforts with in-depth technical guidance. They have deep expertise and they’re easy to work with.
Diego deGarrido Sr. Manager, LSI
Cardinal Peak has a strong technology portfolio that has complemented our own expertise well. They are communicative, drive toward results quickly, and understand the appropriate level of documentation it takes to effectively convey their work. In…
Jason Damori Director of Engineering, Biamp Systems
We asked Cardinal Peak to take ownership for an important subsystem, and they completed a very high quality deliverable on time.
Matt Cowan Chief Scientific Officer, RealD
Cardinal Peak’s personnel worked side-by-side with our own engineers and engineers from other companies on several of our key projects. The Cardinal Peak staff has consistently provided a level of professionalism and technical expertise that we…
Sherisse Hawkins VP Software Development, Time Warner Cable
Cardinal Peak was a natural choice for us. They were able to develop a high-quality product, based in part on open source, and in part on intellectual property they had already developed, all for a very effective price.
Bruce Webber VP Engineering, VBrick
We completely trust Cardinal Peak to advise us on technology strategy, as well as to implement it. They are a dependable partner that ultimately makes us more competitive in the marketplace.
Brian Brown President and CEO, Decatur Electronics
The Cardinal Peak team started quickly and delivered high-quality results, and they worked really well with our own engineering team.
Charles Corbalis VP Engineering, RGB Networks
We found Cardinal Peak’s team to be very knowledgeable about embedded video delivery systems. Their ability to deliver working solutions on time—combined with excellent project management skills—helped bring success not only to the product…
Ralph Schmitt VP, Product Marketing and Engineering, Kustom Signals
Cardinal Peak has provided deep technical insights, and they’ve allowed us to complete some really hard projects quickly. We are big fans of their team.
Scott Garlington VP Engineering, xG Technology
We’ve used Cardinal Peak on several projects. They have a very capable engineering team. They’re a great resource.
Greg Read Senior Program Manager, Symmetricom
Cardinal Peak has proven to be a trusted and flexible partner who has helped Harmonic to deliver reliably on our commitments to our own customers. The team at Cardinal Peak was responsive to our needs and delivered high quality results.
Alex Derecho VP Professional Services, Harmonic
Yonder Music was an excellent collaboration with Cardinal Peak. Combining our experience with the music industry and target music market, with Cardinal Peak’s technical expertise, the product has made the mobile experience of Yonder as powerful as…
Adam Kidron founder and CEO, Yonder Music
The Cardinal Peak team played an invaluable role in helping us get our first Internet of Things product to market quickly. They were up to speed in no time and provided all of the technical expertise we lacked. They interfaced seamlessly with our i…
Kevin Leadford Vice President of Innovation, Acuity Brands Lighting
We asked Cardinal Peak to help us address a number of open items related to programming our systems in production. Their engineers have a wealth of experience in IoT and embedded fields, and they helped us quickly and diligently. I’d definitely…
Ryan Margoles Founder and CTO, notion