(“In Case You Missed It Monday” is my chance to showcase something that I wrote and published in another venue, but is still relevant. This week’s post was co-written with my fellow Head-Geek Thomas LaRock, and originally appeared on Mission Critical)
Not too long ago, an article on BitDefender caught my eye. Titled “California’s ban on weak default passwords isn’t going to fix IoT security,” it explained how default passwords are a problem with the Internet of Things (IoT), but they’re not the problem. In fact, author Graham Cluley went so far as to say, “It also won’t address other problems such as IoT devices with weak or non-existent encryption, or internet-enabled technology which has no updating infrastructure if a vulnerability is found in the future.”
Cluley mentioned the Mirai botnet attack on Dyn’s DNS service and how default passwords are at least partly to blame for the ease with which the Mirai code took control of an army of IoT devices.
Now it’s well known (but not talked about enough) that DNS has its own problems to solve (https://bit.ly/2Q8lt9I). But that’s a different problem to solve and therefore a discussion for another day. The Mirai attack wasn’t about DNS’s weaknesses, it was about IoT’s utter lack of security.
My colleague, Thomas LaRock, had a slightly different take on California’s ban. Commenting on the BitDefender article, he said, “It’s a start, but not enough. We need oversight on how these devices are made, specifically how they can be patched as needed.”
So, this is where I throw my internet-connected hat into the ring and tell you exactly how this is going to get fixed.
In a nutshell, it’s on you, the IoT owner.
IoT security is not going to be solved by IoT vendors (or at least, not spontaneously out of the goodness of their heart). The fact is, those vendors are changing far too rapidly — winking in and out of business like fireflies on a hot summer night. They use bargain basement components that change from revision to revision (and sometimes in between). They use open-source code with minimal customization, but also minimal review to ensure that it does what they need in a way which is secure given the result.
Given their complete lack of motivation to change this behavior, what’s a typical enterprise supposed to do?
In a past contributed post, I described what I saw, and shared my thoughts on how to fix the situation.
At that time, I wrote, “…it’s up to us IT professionals, the gatekeepers of security — if not sanity — in our organizations, to more often and more explicitly raise the security umbrella and point out that implementing secure internet-connected gadgets requires both strategic and tactical actions. Strategic because if our organizations have even an inkling they might consider the technology, then policies and procedures need to be hammered out now, before the first device even enters the doors…”
But this was back in 2016. Now, three years later, the IoT horse is out of the barn, long gone, and the barn has burned down. But that doesn’t make my advice any more relevant because, based on what I see at client sites, nothing much has changed. So here are my suggestions once again.
In my not-so-humble opinion, your corporate policy regarding internet-connected devices — defined as anything beyond smartphones, tablets, laptops, and watches that connect to networks, be they the internet, corporate, personal, Bluetooth, or otherwise — should start with a framework.
To be considered for purchase, vendors must commit to:
- Certifying the security of their device
- Publishing changes in advance of each new version of the device’s operating system
- Informing customers when they are changing the choice of hardware components and subcomponents for future production runs of the device
- Provide a manual or internal update process as an alternative to an internet-wide push
Meanwhile, corporate adopters — departments or the management sponsors of the project — must agree to budget for both funds and staff, which allow for a security umbrella that includes the following:
- Security review and testing, including penetration testing, as part of the adoption cycle
- Ongoing reviews and testing of the vendor’s hardware and software updates prior to rolling to production
Lest you think I’m naive, I admit what I’m suggesting is a complete pain. This would increase the cost of ownership of internet-connected devices significantly. It would create friction and frustration among management, who want the benefits, and IT professionals, who don’t want the added hassle.
But what I’m suggesting is also the only logical way forward, given what we now know is fact: devices that don’t meet these criteria will be compromised in ways that will cost businesses far more than what they would spend to secure things in the first place.
For us to believe doing it any other way will lead to anything except sadness and pain borders on gross negligence.