A Blueprint for Creating a Secure IoT Product - Part 1 (Architecting an IoT Solution - Part 2)

Say you have a great idea for an IoT product, with clear user value and ROI. What would be the #1 barrier for users to adopt your product? Yess, the security.

But how to tackle this challenge, and by the way, what's the essence behind this very old buzzword called "security"?

In this blueprint I'm going to outline what IoT security is about, and how official standards are related to it. In Part 2, I'll share concrete best practices used by my company, Softimize, when we develop the cloud side of IoT products.

Is Security Really a Concern?

Definitely. According to a recent KPMG survey over 92% of both the user side and vendor side are concerned about the security of IoT products. More information from the same survey reveals that less than 40% of the vendors have implemented any security measures!

What is this Buzzword – "IoT Security"

I tend to agree with breaking the "IoT Security" buzzword to the following goal.

Breach prevention

Prevent a breach in any level.

• Devices – the actual sensors and gateways out in the field.
• Environment – cloud, network – wired and wireless, physical environment
• Software – cloud, web and mobile apps

Privacy

Meaning, to let your users control their data. For example, control for how long the data is stored, and most importantly who has access to it.

To illustrate I'll share a brilliant IoT product I heard about last week. Its vision is to provide an online ergonomics service for all of us, the white-collar workers, who spend a lot of our time sitting on office chairs that are not perfectly fit for our body.

How is this vision implemented? By connecting sensors to the chair in various locations, thus knowing its angles. Then, a chat bot will aid us to fine-tune the chair's position. Brilliant, isn't it?

Now think about the average employee, for example, myself. While I'd love to have this chair, I also realize that if my boss has access to this information, she might be able to know if and how much I'm actually sitting on it.. So will I adopt this chair or not??

Trust

With security, appearance is almost as important as implementation. So we must prove to our users that we indeed prevent breaches and keep their privacy. Easier said than done. Two tips for that:

• Privacy - Create a clear and short, KISS-like, privacy policy, that users will actually be able to read.
• Breach prevention – adhere to well-known standards, and gain certification from accredited bodies. I'm going to talk about it right below.

Create Trust with Security Standards

So the standards, often viewed as obstacles for vendors, are actually here to help us prove we are truly secure. My personal view is that IoT companies not adhering to any of them will have a very hard time flying.

There are two families of standards. Company-level and product-level standards.

The ISOs

The ISO standards (at least those I focus on) are all company-level standards. Meaning that once a company (or a division within a company) is certified to a standard, all its products can leverage this certification for marketing.

There are 2 main ISO standards relevant to IoT security in general.

• ISO 27001 – The information security standard.
• ISO 9001 – The quality management standard.

And for select industries there are extensions. For example, for the connected medical device industry, the relevant standards are

• ISO 27799 - Information security management in health. Extends ISO 27001.
• ISO 13485 - Quality management systems for medical devices. Extends ISO 9001.
• ISO IEC 62304 - Software development process for medical devices.
• ISO 14971 - Risk management for medical devices.

By the way, at Softimize we see that the connected medical device industry is moving a bit faster than the rest of the IoT industry. Our hypothesis is that it is related to the compliance regulation that enables adoption. The lack of such regulation leaves a vacuum in almost all the rest of the IoT segments, and that's why they fly slower.

So, how one becomes certified? That's less complicated than one may think, at least for an SMB. Using a consulting company that takes most of the overhead of the paperwork, it may take around 4 months to be certified, with 40 hours of overhead along the process. The total cost (consulting + certification) is around $10K (at least in Israel). There's also post-certification overhead in the form of a yearly audit, and around 10 hours/month for paper work.

HIPAA - A Product-level Standard

HIPAA is an American standard for lots of health care products and services, including connected medical devices. It has a European counterpart by the name Data Protection Directive.

While HIPAA is mandatory only for health-related products, its principles may serve as an outline for building any IoT product with security in mind.

HIPAA defines a concept named PHI, Protected Health Information. PHI is any piece of information that may be private to the user. It is divided to 18 families. Some are trivial and include name/ID information. Some are less trivial, such as biometric information, like finger prints.

How to protect the information? HIPAA doesn’t specify exactly how, but mandates that protection is done using the contemporary best practices. By the way, HIPAA is self-declaratory. Anybody can declare they're HIPAA-compliant. The teeth are in the audit process that will/may happen later, and may incur high fines if gaps are found.

Another relevant concept defined in HIPAA that is relevant for any IoT product is the BAA, or Business Associate Agreement. Since we're dealing with complex multi-discipline products it's almost certain we're going to use 3rd parties as part of our product solution. And if we declare HIPAA-compliance then the 3rd party product/service we use should be HIPAA-eligible as well. The Business Associate Agreement, signed by the 3rd party assures us that their part in our product is covered.

HIPAA & Clouds Architecture

At Softimize, as an R&D center focused on cloud-native IoT clouds, one of the 3rd parties we use is the cloud vendor. In their BAA the cloud vendors specify which of their cloud services is HIPAA-eligible, e.g. services that are allowed to process or store PHI. Here is a comparison covering the major cloud vendors.

Our interpretation is that with AWS and Azure one can develop almost "as usual". With Google Cloud Platform, it will usually be OK, though a more careful analysis of the use case is needed. With IBM, one can deliver a HIPAA-compliant service, though it would not truly be cloud-native.

So, What if my IoT product does not require HIPAA compliance?

Still, if I want to process or store information that should be private, then we recommend following the HIPAA guidelines to be sure we're using the cloud in a secure way.

What's Next

That's it for part 1 of our blueprint for creating a secure IoT product. In Part 2 we'll get more technical and share the Softimize way for designing secure IoT products.

Stay tuned until next time,

Guy