Tala Blog

IoT Minimum Viable Security for a Minimum Viable Product

Rajesh Kanungo - Nov 28, 2017 9:53:00 AM

(c) Rajesh Kanungo

Minimal Viable Security (MVS) is a trademark of Talasecure Inc.

Acknowledgment: Michael Garrison Stuber for pointing me at FAIR.

Introduction

This article explores security issues with Minimal Viable Products in the IoT space and recommends methodologies for solving them.

What Do You mean by Security

The conversation nowadays has moved from "Is security necessary?" to "How can we make something secure?" . Which begs the question, "What does secure mean and how much security is good enough?" Would you protect your refrigerator IoT device to the same degree as your smart phone?

A Short Definition of Security

Security is about RISK: The probability of something happening multiplied by the resulting cost or benefit if it does. Securing products should protect the essential assets and not harm others.

The Bald Tire Question

How much risk is associated with a bald tire? It depends... Is it mounted on your car? If you had a flat and had to get to the closest repair shop? Is it hanging from a rope under a tree? Is it hanging from a rope over a cliff? Is the rope frayed?

As you can see, it depends ...

History of Minimum Viable Product (MVP) and Security

The industry, especially the tech industry, has moved towards the MVP model. In general, 99% of the MVP plans I have looked at explicitly exclude security. In the early days, most devices were not connected to the Internet. Things started getting bad when devices and services started getting local network access and, hence, sometimes got connected to the Internet indirectly. Dangerous but it could be controlled. With IoT devices, things are really bad as they are accessed through the Internet. Any hacker can take over your device, intercept your communication, etc. if it is not properly secured.

Customers are now demanding security be made available earlier rather than later. Many customers, especially IT departments, are not accepting products that do not meet minimum security levels.

Some Security Questions to Ask For an MVP

There is no absolute security. So the builders of a product have to understand the RISKS associated with the product.

  1. What is the asset that security should be protecting? Some possible questions to ask are:
  • Fundamental product value: Could be the video from your webcam, could be ability to lock or unlock your from door, Your private photographs, Intellectual Property, etc.
  • Access and control: One must be able to control the device
  • What are the privacy implications? Can a hacker steal/watch your video? Can they find out if you are home or not? Can they get personal information about your life. Remember, even a FitBit can give out information about your activities.

2. What is the security impact of your product in a customer site? The customers are getting very anxious about the security impact on their infrastructure and personnel. Some questions to ask:

  • Does the compromise of your device impact the customer in any fashion? For example, DDoS attacks, your device being used to launch other attacks, shared authentication mechanisms being used to perform attacks using an employee's identity, etc.
  • What is the cost to a customer if your device is breached?
  • What security training is required for the customers? The less the better.
  • How easy is it to have full security? If setting up of full security is hard, customers may disable it.
  • What does the customer have to do to make sure that the security is up to date? Most customers do not want to deal with patches.
  • How will you inform the customer of any security incidents?

Minimal Viable Security (MVS) Guidelines for MVP

MVPs, especially for startups, are extremely important for understanding customer needs early. In the initial phases, one may also want to understand what customers have and need. There are differences between Large Enterprises, SMB, and consumer customers. Some basic steps one can take:

  1. Your product security hardening by itself: These are the steps one can take to harden your products irrespective of who is going to access them.
  • Make security a part of your Executive, Sales, Marketing, Manufacturing, and Engineering deliverables. Make sure that all the groups are aligned and made aware of security requirements. They should also be made aware of the cost of a mass recall of compromised devices.
  • Budgeting and Resourcing: Make sure that management has budgeted and resourced for MVS.
  • Identify your devices critical assets and protect them using Authentication, Encryption, Authorization principles. This is a large subject by itself and you can email me for more discussions.
  • Ensure all network access is secure. Using HTTPS is not that hard ...
  • Make data at rest secure: Make sure that any critical data stored on the device is secure. If physical security is important, use, at a minimum, secure boot.
  • Use existing security packages; please do not develop your own crypto, login mechanisms, etc. It is wasteful and probably not secure enough.
  • Scan your code using static code analyzers, and, if possible, dynamic code analyzers. These analyzers should be run as part of your continuous build-integration-test cycles.
  • Use penetration test programs to find and fix your problems early: You can use for free tools like OpenVAS, Metasploit, NMAP, etc. There are also commercial products available.
  • Keys, Passwords, and other security mechanisms: Avoid the use of passwords, force the use of non-default passwords, use public-key cryptography where one can instead of passwords.
  • Server/Cloud security: The customer's data will most probably be stored in the cloud or on a server. Make sure that the data is secure.
  • Remove all back doors: Hackers will find any backdoors and exploit your system.
  • Make Security Easy to Use: Most of the technology is already available. Your job should be to make it easy to install and use with high-level security without causing immense grief.
  • Make Security Updates Easy: IoT devices, most likely, will not have a PC kind of interface. Updates have to be easy and scalable across millions of devices.

2. Customer Initiated Security: Some customers have an idea about what security they need. Quizzing them about their installation and use requirements will help you plug your device into their systems more easily.

  • Understand the customer's security expertise and language and explain security to them in their terms.
  • Authentication, Authorization, Accounting systems: Ask customers how they connect their devices to the rest of their infrastructure. Most systems already have open source support.
  • Their Patching policies and Abilities: Find out if they are capable of patching systems themselves or they will need help. At this point you will have to decide if the devices need to be manually patched or there is a way to automate patching.
  • Remote Device Support: Find out what access an enterprise can/will allow for remote troubleshooting. Most device manufacturers like to login directly into the IoT devices. Most IT departments don't allow it.

3. Summarize your findings and create an MVS compliant product. Most of your MVS compliant devices will do the following:

  • Pass penetration test tool checks. Easy and cheap. Use OpenVAS, NMAP, Metasploit or commercial tools.
  • Pass static and dynamic code scanning. There are many tools available. I have personally used Coverity and Fortify but I think they are all very good.
  • Use standard packages for authentication, encryption, and authorization. For example, PAM and WinBind are useful for Linux integration into an enterprise.
  • Use standard packages for integrating into an enterprise or consumer's system. Don't use your own proprietary crypto. Use SSL, HTTPS, SSH (with caveats), etc.
  • Ensure that data at rest and data in motion are secured. You might want to look at using linux user permissions or SELinux.
  • Software updates are secure. For example, linux has an excellent patching mechanism which is also secure.
  • Installation of a secure system is easy: This is where you have to do some work.

Conclusion

Minimal Viable Security is achievable if one decides to use existing technology and the management is on board.

Please share if you find this article interesting. Feedback and comments are appreciated.

Acknowledgements

Michael Garrison Stuber, Ben Loomis, Hemant Thakkar, Ryan Wilson, Ido Dubrawsky, Ishtiaq Rouf, Geoff Kemp, Kyle Haugsness, Mark Templeman, Evan Anderson, Jerry Hicks, and many others I have forgotten to mention.

Previous Post

Secure Code: Why and How to get your teams to write secure code

Next Post

A Better Way to Approach IoT Security

0 Comments