IoT security and the infinite game

A finite game, like a football game or a single game of chess, has a termination or metaphorical finish line where we can declare a winner or loser. An infinite game, however, is one where there is no real finish line but continues indefinitely without a set point to celebrate ultimate victory. Simon Sinek address this in some popular videos (like this one) and in a book The Infinite Game with partners Peter Docker and David Mead for those that want to explore this more deeply, but specifically this has immediate application to security in the Internet of Things (IoT).

Most startups in the IoT space are playing the finite, high-risk game of entrepreneurs looking for an exit strategy in a two to five-year window, but their devices will live on for decades. Not only does this present challenges in the short term as they both ship and have to consider a rapidly shifting world of threat actors, vulnerabilities, and exploits, it begs the necessity of a long-term view from those who are typically in the short game. In other words, the players of finite games have to have strategies for and be held accountable to infinite game responsibilities.

In 2019, I wrote two articles on how to get IoT right, titled Winter is Coming: IoT Done Wrong and IoT and the New Age of Digital Pollution. I hope the first can be forgiven the Game of Thrones reference, but both sought to provide a prescription for how to get IoT right upfront. Sadly, most of my suggestions have not happened; but given that this is an infinite game, it’s not too late to take steps. It might be more onerous or more expensive than it would have been four years ago, but the steps we take now matter and can fix issues today and help us fight adversaries more effectively in future iterations of the infinite cyber game.

Before continuing to the advice, let’s look at the adversary and changes in technology since 2019. The most obvious of these is the appearance of real, substantive advances in AI. As an industry, we have always talked about the “ever-evolving” adversary, but the key point here isn’t that they are changing and so should we. No, the key point is that they are evolving at a faster rate than defenders, and this demands changes in strategy to accelerate how we defend. This includes strategies like least privilege access or zero trust, advances in behavioral analyses (like indicators of behavior), better data crunching, and more; but specifically, we need to have better default positions. Systems need to have better hardware-based security, ship with fewer vulnerabilities and address security issues much more quickly. Ideally, we do even more because the adversary is accelerating their rate of adaptation.

Let’s dive into what the formula is for the IoT ecosystem, by which I mean all the players from manufacturers and service providers to governments and practitioners. This isn’t a “these people here have to fix X” insight; it’s more “here’s what we collectively have to do:”

1. Identity: Get identity right at the start. We need to establish a schema for unique device identities. Whether or not they are universally unique doesn’t matter; nice to have, but not essential. Furthermore, there should be no default identities for use of devices on ship or for later access. Setup and provisioning at scale options should introduce associated machine and human identities for the use of the device. 
2. Zero trust: There should be a design of least trust and least privilege by default. Consider minimal stack exposure and rate-limiting communications options. Use the old notion of a “personal firewall” for explicit control of communications low in the stack by policy.
3. Cryptography: Can we try to get the cryptography right? I know that’s a big ask, but we can at least get it right for the world we have and think about the future. Let’s start with random number generation, trusted execution, hardware roots of trust, and entropy generation. Get those elements right. We also should be thinking about how to be forward compatible on the presumption of quantum computing enabling decryption, so shipping with support for something like CRYSTALS-Khyber and most importantly the ability to change the crypto in use is a big deal. Better yet, chaining trust and ultimately leveraging external cryptographic services is also a good idea!
4. Resilience readiness: Let’s make sure that devices are updatable. Let’s make sure that the state of the device, compute, storage, and peripherals are verifiable for integrity and tampering, leveraging the hardware root of trust from the previous group of qualities. Is the device alive? That’s needs to be known. Can it be recovered if bricked or should it be brickable on command? Should it be discoverable and, if so, how and by whom? All important, but here’s the most important part: all software and firmware should be upgradeable, re-imagable, and potentially recoverable (or brickable if that’s preferable, but make sure the licensing reflects all of this, too). We can’t afford more heartbleed vulnerabilities with devices forever exposed.  
5. Survivability: Make sure the technology can be serviced after the vendors are long dead and gone. How does that work? Well, business agreements, open source community, escrow. Vendors should be put on the spot to find solutions here because if the vendor of, say, an internet camera or a coffee pot goes out of business in two years, how is that vulnerability going to be patched in five or 10 years?
6. Logging and monitoring: We need standardized telemetry for third-party consumption, but even absent that, APIs and forwarding of logs is important. It’s fine for a vendor to provide a toolset, reports, and the like, but third-party capabilities matter a lot. The default assumption should be third-party consumption.
7. Service catalog readiness: We can’t think of everything up front, nor can we supply everything from a single vendor. A best practice would and should include support for a catalog of off-device services, and ideally a standardized form of doing so. What sort of services? To start, the obvious ones are identity management, device management, provisioning and management of applications, data security, backup, restore, failover, authorization, fleet management, health checks, secure remote management, and many, many more, especially with the specialized nature of many of these devices.
8. Innovation welcoming: New ideas are coming! I promise this will happen. So let’s make it easier. Let’s consider the potential for new uses of deception technology, virtual patching, shielding, and things we haven’t yet thought of going forward. Encourage an ecosystem of aftermarket security and privacy products in design and either license it or, better yet, open source it.

To be clear, this is a start. It’s not exhaustive, but it’s a list to start the dialog and build on. The best approach of all is to build informal advisory groups. Most customers and many of the really great people in cybersecurity and privacy will spend the time to talk to members of this ecosystem and answer questions because it’s in our collective best interests to do so. It can even be a competitive advantage to advertise these things, for even small companies to publish discussions on this subject. It does not have to be expensive to have an open dialog about leaning into security, but make sure while you’re at it that security is a priority internally with your security program, your stance on reporting vulnerabilities and bug bounties, and so on. 

If we don’t take this approach collectively to security as an infinite game, starting with IoT security, but really across all domains of cyber security, we will find that the capabilities of the adversary are inhibiting innovation and adoption and slowing down an important economic engine and industry. Play the short game, by all means, but plan for the long game. Plan for the infinite game.

What to read next 

Edge computing and IoT: Security through zero trust

IoT devices: An unfortified attack vector

IT, IoT, IIoT, OT: zero trust for every...thing [podcast]