In 2017 I was at Exosite, an IoT platform company in Minneapolis, and I gave a talk on information security for connected devices. It went out as one of the company’s webinars that spring, “IoT Serious: Humans, Machines, and Building a Culture of Security”, a panel of three: Marcia Cole, who ran Exosite’s information security management system, Steve Wright, who managed professional services, and me, with Melissa Cisewski hosting and putting the audience’s questions to us. My outline survives as a note, and a machine transcript of my half of the recording survives with it. What follows is the argument as I laid it out, in its order, with the parts of the delivery that the outline left blank.
Security is a state that has to be maintained
Security is freedom from danger, and in practice the protection of some other state. It does not ensure reality; it has to be maintained, and it has to be validated. Information security is the case where the knowledge itself is sensitive. Imagine a signal: it wants to be free, and its natural state is to emanate or decay, not to hide. What we protect is access and disclosure, in cyberspace or meat space, on an as-needed and need-to-know basis.
That framing carries the hard parts with it. A weakened state is difficult to recognize. Disclosure is one and done; there is no recovering from it. And not all information is created equal. As people put more of themselves online, losing that identity can do more damage than losing an object in their house; I could say so personally, having had my bank account drained more than once and watched the money go with no way to stop it.
How the cloud does it
A datacenter’s security is nested restrictions: who can reach the site, which persons have access, who can reach the rack, and finally the local rack restrictions, console passwords and intrusion detection. Each layer assumes the one outside it held.
What a device keeps
A device in the field keeps only the innermost layer. It relies on nothing but intrusion detection and silicon. Its security features are local to it. It must assume physical access. It is like hosting a web service on the attacker’s own machine, inside a hostile network. In the delivery I put it more bluntly: devices are web applications, and the software on them has to meet the bar a cloud application is held to, because web applications are attacked daily.
Parity means giving the device by other means what the rack had: a way to identify and lock out a compromised device and to keep it from changing identity (the outline’s examples are the Xbox and Atmel); cellular check-in and intrusion detection; a dead man’s switch, the way a phone can be wiped remotely; a decision about whether the device is a server or a client, since a client gets a restricted view and depends on everlasting access; and information that has been identified and classified. One of the questions put to us was whether hardware or software mattered more. Software: it is what keeps attackers out, and even when the physical layer has been breached it can notice the anomaly and tell the network. The hardware that helps most is a chip that holds the private key where not even the device’s own software can read it, so that the key can underwrite the boot chain and give the device an identity that is a genuine engineering feat to clone.
Exceeding parity was the middle of the talk. Ephemeral everywhere. Aggressive timeouts. Understand the shape of your information, how you expect it to move, and where it rests, its canonical source. Provide access in aggressive, time-boxed spats with authorization, authentication, and audit logs, and then ask whether you trust the logs. Secure boot, turtles all the way down: every link and handoff must confirm authenticity, because the weakest link wins, and init=bash is a weak link. Attack vectors and surface area. Containers and minimalism. Follow the signal, down the cable if necessary.
What is new about devices
Devices enter zones that are normally trusted. They are a potential back door into your own cloud infrastructure. They multiply, and on their own they can saturate a user’s local network. Updates cannot be enforced. And the safety of the web itself has to be considered, because these devices are on it. The examples in the delivery were the security cameras then being found broadcasting from people’s homes, bought for peace of mind and compromised for a long time with no way for their owners to know, and the botnets of devices that could take down large parts of the internet, DNS included.
Pragmatic practice
Apply every traditional web-application expectation. Understand the sources, realms, and expiry of authorization and authentication. Session lock; TLS. Keep credentials from leaving in plaintext. Scrub logs outside the application, with prefix and postfix matching, before shipping them. Lock sensitive information to RAM and avoid disk. Biometric access is bad: it is a single-use password that is sensitive in and of itself. Fall back to network lockout.
The technology is rarely where things fail. The examples were the responses to Heartbleed and CRIME: a protocol version and a compression feature switched off across the internet in a matter of weeks and months, with live servers tested and told to turn them off. An attacker looks instead for the implementation failure, the secure technology used wrongly for lack of time or understanding, at the speed the business demanded. And the updates have to reach the devices. Keep security updates on a channel of their own, separate from features, so they never break anything and users learn to apply them the moment they arrive; the recent attacks that had shaken the world were, in the end, a failure to get updates onto machines.
For our own work: take what works from DTLS and imitate it; use gRPC-like frameworks with the boilerplate built in, because code is a liability; look toward new transport protocols with security built in. We could no longer claim naivety or ignorance; security had to be the default. And the bar had to come down, so that security was accessible to users and to developers at the speed of business, the way phone security had become accessible. That was a successful model to borrow from.
Changing ourselves, and our users
The last part was about people. The outline reserves a place for a story about spam, and a sigh. The story, as I told it: at an earlier company, exploring the network, I found a server nobody knew about, a virtual machine in the datacenter that had been forgotten. I could not log in, and it was old enough that I used a kernel exploit to get back in. Inside was a connection set up so that a client could relay mail through us, configured to send as anybody, to anybody. When that client was compromised, the company’s mail server relayed spam to the rest of the world for five or six years, and all of it was collected on the company’s own servers. A second server had been taken over by three separate parties, each with complete control of it, with many client installations on top. I was in something of a frenzy about it, and I still found it hard to convey why it mattered, even though the people exposed were our own clients. That was the sigh.
The contrast with physical analogues needed to be sharper still: doors and locks are understood, and this is not. No more sensationalizing, chastising, or ignoring. Public disclosure and a postmortem, within hours and days respectively; the outline notes Europe beside this, where breach notification was about to become mandatory. We are the stewards, not the user, who is ill-equipped to recognize or mitigate any of it.
For users: recognize that the device is an extension of them. Treat breaches like crimes. Push and control the narrative around active maintenance. Acknowledge the social-engineering aspect and reduce that surface area. Assign reasonable, accessible controls that are unlikely to be circumvented; recovery questions are the counterexample. Permissions on demand and on use.
Privacy is freedom from observation or disturbance, and it correlates almost directly with security: what is private is by nature sensitive. The trusted zones come back here with a challenge of their own, which the outline calls a reprieve from nanny cams.
The takeaways were three lines:
balance sensitivity and convenience
information leaking everywhere, try not being courteous
integrity, awareness, responsiveness will lead to common sense understanding of infosecs strengths and limitations