I want to talk to anyone who is building, deploying, managing, or deciding on what products to buy in the Internet of Things era. Yes, this includes those of you in the AV space (read on). Our Generation 3 platform just passed its third-party penetration testing cycle with flying colors. We’re sharing those results with our customers in finance, pharma, energy, and tech and they are happy. A third-party pen test is a long and arduous process but crucial to instilling consumer trust and confidence in your product. One customer commented to me recently “I wish other companies in your space would do the same.”

Hence this blog post.

Security demands a scientifically rigorous, intellectually honest, and precise approach when building and deploying products. While there can be subjective debate when it comes to other areas of product design (i.e., easy to use, full-featured, productive, and enjoyable), how you think about building products in the IoT/Connected world must be very different – especially when those products will be deployed pervasively on the network.

If you think there are areas of product development where security isn’t as important –think again. Take, for example, the entire AV industry. As recently as ten years ago, the majority of AV products were developed within closed, dedicated pipes. Video delivery and switching took place along dedicated DVI cables through closed systems. Hacking into those systems would involve a physical tap to the wire. This approach is similar to the early days of the telegraph. If I wanted to listen in on a telegraph conversation, I’d pretty much have to climb a telegraph pole physically. Obviously, that’s changed with the advent of packetized voice, and the deep integration of voice with our global networks. The same was true (until recently) for the world of AV. Video is now routed over the existing network, and AV products are intelligent, connected IoT devices. It’s a fantastic transition for users, but those of us building these products must be focused on security issues. My point here is that the same type of design, engineering, and even marketing that works for some product features simply isn’t what’s needed when it comes to security.

Why does this matter so much? When securing a device that sits on the network (and what device doesn’t these days?) not only should your device be secure for its own data integrity, privacy, and robustness reasons but it also shouldn’t become an attack vector on the network. “Hey, I’m building a consumer camera that attaches to the home network – at worst someone’s photos can be stolen.” is not the way to think about IoT security. That same camera, when hacked, can be combined with all the other hacked cameras to become part of a denial of service attack to our banking system. It’s essential – and something we need to be intellectually honest about with ourselves and our customers. 

This is why I was dismayed by a recent announcement from a wireless IoT company that involved ISO 27001 certification. Company certification is not product security – and it’s misleading to your customers. ISO 27001 does speak to some important areas including policies in your procedures in the workplace that should be followed, but it does not mean your product is ready to be securely deployed on the corporate network of your customers.

 Claiming a product is secure because it was built by an ISO 27001 company is insincere at best.

So, what does ensure product security? I approach security using three internal initiatives:

1) Build with security in mind at the outset. This means any new feature must be reviewed from a security and privacy perspective before it is deemed ready for engineering and architecture to take over. Does the feature expose a new attack vector? If it does, can it be disabled for the most secure environments? Does the feature require privileged access? If it does, how is that access granted and then revoked? When building our product, we engineered everything from the OS kernel to the application layer (and how it can or cannot talk to the OS) with security in mind. To be fair, we were lucky to have early sponsorship from the US government who made sure security was one of our top concerns from the beginning.

2) Employ independent, scientific verification. We run multiple third-party security penetration tests each year, and those tests feed into our roadmap by giving us some great ideas around security features, hardening, and potential improvements. This means the product is always improving from a security perspective, and that we’re not relying on your judgment about what is and is not secure. It’s also important to share those results with customers who will rely on your ability to provide a stable, secure, network-attached appliance. It’s not enough to do a “security scan” – a penetration test can take weeks, cost as much as $100k and will cost your engineering team time – but it’s not an option – it’s a must. 

3) Establish critical response plan. Finally, you need to think past the product to response processes that need to be in place in case there is an incident. We call this our “24-hour Response Policy” that clearly outlines what happens if we (or someone else) discovers an issue, how we communicate the urgency of the issue to our customers, and what we’ll do to respond. Luckily, we’ve never needed to deploy the policy but having them in place in advance will be a powerful way to mitigate problems if and when they occur.

So, no surprise, security is important. However, it’s not enough to get a certificate and hand that to your marketing team. It has to be embedded in your product development culture deeply. The Generation 3 Pod security results passed with a comment from one of the hackers on the penetration team, “This is the most secure IoT device I’ve ever tested.” That’s pretty incredible, but Gen3 is the result of a constant ongoing process to secure the Pod. It’s not as sexy as adding new cool features and most of the security features we’ve built over the past four years can’t even be shared with the market-at-large. But if you treat security with the rigor it needs – your customers will reward you with partnerships that stand the test of time.

About Christopher Jaynes

Jaynes received his doctoral degree at the University of Massachusetts, Amherst where he worked on camera calibration and aerial image interpretation technologies now in use by the federal government. Jaynes received his BS degree with honors from the School of Computer Science at the University of Utah. In 2004, he founded Mersive and today serves as the company's Chief Technology Officer. Prior to Mersive, Jaynes founded the Metaverse Lab at the University of Kentucky, recognized as one of the leading laboratories for computer vision and interactive media and dedicated to research related to video surveillance, human-computer interaction, and display technologies.

Submit Comment