Secure your IoT products like your business depends on it
The early days of IoT, which are just barely behind us, were basically the wild west in terms of security. If implemented at all, security controls were either poorly configured or a homebrew system that created more problems than it fixed. Standards simply did not exist. I’m happy to say the industry is at least 10% better at security now, though that may be generous.
Who’s fault is this? It’s a complicated question, but one that needs addressing. I’m not an IoT guru, but I’ll take a crack at answering based on my own industry experience. I think it comes down to a couple of things; the pace of the market and price competition.
One could argue that these pain points are not specific to IoT, but they present a unique set of security obstacles for companies in this space.
Keeping up the pace
Nothing causes an engineer to disregard their convictions more easily than a tight deadline. For companies that are competitive in this space, engineers are working long hours to cram cycles into time frames that just aren’t big enough to do perfect work. I’ve spoken to firmware, software, and mobile developers in companies that have IoT products and it’s the same story across the board: they don’t feel like they have enough time to think about security first.
Despite my security-guy knee jerk, I don’t fault them. Aside from the odd case of ineffective management or “bad” developers, the lack of development time more often comes down to poor processes and communication between teams. You may not think that your hardware team needs constant contact with the software or mobile team, but getting everyone on the same page should be prioritized on the first day of the development cycle.
Do you know who else should be involved in the entire development process? SECURITY. I’ll loop back to this later.
Sometimes cheaper isn’t cheaper
There are a couple of things to unpack with this point, but it comes down to product and personnel. Hardware decisions that are made solely by finance teams, or anyone else not directly working with the product, can be dangerous. You choose a cheaper MCU, maybe there are flaws you’ve introduced that aren’t present in the more expensive cousin. Cutting down the memory to save money could lead to unpredictable behavior on your devices.
Ideally, cost-saving decisions should be predicated on a thoroughly tested prototype with the new hardware and a review with the engineering teams. If this isn’t a time and labor cost your business is willing to absorb, the alternative is assuming the risk it presents. Plain and simple.
Hardware isn’t the only thing companies tend to skimp on, there’s also the issue of personnel (or lack thereof). I could talk about the woes of preserving talent at an organization via salary and such, but what I really want to touch on is the hesitancy to hire the right people. If your organization has no department overseeing the security of your products, you’re asking for trouble.
Not every organization needs a dozen security analysts and engineers. However, if your small security team is balancing the posture of the organization and the security of your products, you may want to look at a dedicated DevSecOps engineer for your development teams.
I know, the security jargon is getting ridiculous. A developer security operations (DevSecOps) engineer is someone who oversees security specifically for the development process. They will implement SAST and other testing solutions, get implanted in the SDLC process to secure it and act as the first line of defense against security holes poked by poor engineering practices. DevSecOps is indispensable to a secure IoT product.
The path forward
If there were only one thing I could impress upon you to implement at your organization, I would choose to test against a strong IoT guideline. GSMA has an excellent set of documents you can use to create a solid test plan based on guidelines that have been assembled by the IoT security community. It’s a wonderful jumping-off point.
That set of guidelines should be used in conjunction with securing SDLC, creating a hardware change review board/team (with leadership, security, and engineers), and maintaining an adequate security team. There’s no substitute for any of these pieces. Truly, I would consider this the minimum viable setup to achieve decent security for your products.
If you’d like to take things a step further, consider the following enhancements:
- Quarterly pentesting of your IoT devices
- Regular security training for your development teams; preach the OWASP IoT Top 10
- Create a bug bounty or vulnerability disclosure program that is easy for security researchers to interact with (and take it seriously)
Lastly, a great security posture doesn’t come overnight and doesn’t last without maintenance. Make a plan, inch toward that goal every day, and work to keep your standards high. A single, preventable, vulnerability can be the doorway to your (or your consumers’) critical systems.
