IoT in a Zero-Trust World
My name is Yolonda. I’m a Product Manager for a cybersecurity startup, but I promise this article isn’t me trying to sell you something. This is more of a Jerry Maguire-style declarative statement.
I spend an inordinate amount of my time talking to people about devices, specifically the security of their devices. What are they? How many are there? Are they supposed to be there? What are they connected to? Are they supposed to be connected to that? What are their capabilities? Is everyone cool with this webcam running FTP? Does the factory manager know that the lack of encryption on the Production WAPs leaves the business open to an expensive, and probably job-ending, data breach?
This isn’t just idle chatter. I see this stuff everyday with business systems, but people are quick to write off the issue. It’s always some 20-year dude, convinced that he’s got a solid grip on reality, that huffs smugly in my face: “I wouldn’t allow it”. Ok, bro. Oh, you have NAC? Oh, you have VPN? Oh, you have AV? Oh, you have firewalls? Cool — so then it’s totally legit for that Chromecast to be running DNS, right? Good thing it’s on the same network as the domain controller…but it sounds like you got this.
The common advice I’ve seen (and also given) is that we should segment. Segment in the morning, segment in the evening, segment at supper time. I was giving a talk at a local security meetup couple of weeks ago and someone asked if I would recommend still using a VPN even if you’d taken the steps to segment. Can you just add more firewall rules to not allow that polycom to have inbound traffic to FTP (let’s ignore, for a second, that there’s no reason in the world for anonymous FTP on a polycom)? Yes! was my emphatic answer, after all more security things are better than less security things, but then someone asked a follow up question: “does this strategy survive in a world where the device strictly requires connectivity to perform its core function?”
The more I think about it, the more I believe it really doesn’t, at least not fully. That may be fine for, say a refrigerator — afterall, all we really need for it to do is to keep the milk cold and the ice cream frozen. That’s much less okay for a pacemaker which may need to report results out continuously over a wireless connection .
Let’s be honest here — one of the major issues with “IoT”, as we’ve come to describe it, is the fact that there’s more incentive to get it (the service, the sensor, the analysis) out to market as quickly as possible, meaning things like a clear, reliable and secure upgrade path tends to fall by the wayside. Since many of these systems do not offer enough memory to support the installation of agents or on-board monitoring solutions, the most common approach to upgrades tends to be over the air or OTA. The fundamental premise there, however, is that there’s a way for the device to call back to the mothership, so to speak, and upgrade on its own with minimal user intervention (see the Internet of Shit account on Twitter for the many examples of how this can go sideways). If that path doesn’t exist, then the device sits in a state of continuous disrepair. This may be fine for a system that isn’t related to life/safety, privacy or revenue generation, but often these systems go unaccounted for during periodic threat modeling, making them prime targets for attack, exploitation and lateral movement.
The rise of zero trust
Zero-trust has been growing in popularity in the last few years. Essentially, the “zero-trust” concept assumes guilt before innocence on everything. Every device, application and identity is fully segmented and when users need to gain access to specific information the entirety of the transaction (device, application, identity, relationship) is interrogated to determine its validity. Furthermore, the entire ecosystem is continuously audited to validate its authenticity. In a perfect world, zero-trust should make it really, really hard to abuse a system.
More and more companies are moving in this direction. It makes sense: Millennial workers show up to the office with an average of 3 computing devices in their possession, with 43% of them being mobile-dominant and 50% of them stating that they needed to have constant Internet access. The traditional approach has been to either flat out deny this access or to push VPNs and agents to the devices to facilitate secure access. I talked to one CISO that said his organization was having a tough time retaining some of their Millennial talent when they prohibited workers from bringing in their own devices. Another CIO expressed that the Millennial workers in her organization were concerned that any agent-based approach would infringe on their personal privacy. Don’t get me started on VPNs…anyone that has travelled overseas and then tried to access their corporate network through a VPN knows what a frustrating experience that can be.
Zero-trust really excels in promoting the idea of a network as a series of concentric circles (as opposed to a hierarchical model) with the most critical, most sensitive transactions taking place in the center and less sensitive transactions occurring in outer circles. The outermost circle would encompass those transactions — devices, applications, identities, relationships — that are either transient or should have no privilege to access sensitive information. Those systems are simply afforded Internet-only access. The key is then monitoring & validating how and when these transactions occur across circles.
Where zero-trust falls down, in my opinion, is in providing truly complete context of a system. Let’s imagine a case involving a smart lightbulb. In our zero-trust world, the lightbulb should be segmented off to a level of some privilege — i.e. we want it to have slightly more privilege than our guest network, but way, way less than the segment that houses the database containing pharmaceutical research, experiments & results, let’s say. What about the other components of the lightbulb that aren’t actually providing light?
Not only do you need to consider the light itself, but also who can interact with it (by application), how to interact with it (Wi-fi, Bluetooth, Zigbee, etc), whether the interaction is secure (encrypted), the ports & services which should be open (for upgrading) and the devices allowed to interact with it as well. Did I also mention that the light bulb also comes with an embedded speaker and microphone, so you can hum along to smooth jazz while you turn your lights on?
IoT is already here (yes, also in your environment) and we already rely on IoT systems for some pretty important things. IoT can thrive in a zero-trust environment if you can accomplish the following things:
- A clear, unequivocal understanding of the device, all of its capabilities and all means of communication. This includes having a clear understanding of whether or not the device is transient or permanent.
- Provide a secure means to allow the upgrade path to execute, even if it means dropping the device to a ‘limited-trust’ zone.
- Continuously monitor both the device’s configuration as well as its associated relationships
- Automate monitoring across trust zones — static devices which have been given some level of trust shouldn’t suddenly show up in lower-trust zones.
Though my remarks have been focused on the tech, this whole thing hinges on our ability to articulate what’s at stake as part of continuous threat modeling. Devices — what they are, how they communicate, capabilities, and their associated behavior & relationships are one part of what should be considered during threat modeling. Zero-trust networking should serve as an enabler of IoT systems to function both securely and reliably, allowing companies to realize the benefits of IoT while minimizing the risk.
