At a conference where I spoke on a cybersecurity panel, a university student approached me afterward with some great questions. Several were relatively tactical inquiries about resources for learning various aspects of the discipline, but one broader one stuck with me: “If you had to distill it down to one concept, what would it be?” For such a vast knowledge space as security, (and I’m deliberately leaving off the “cyber” part because my answer applies elsewhere, too) is it even possible—indeed responsible—to articulate a single concept? I guess you could say something pithy or snarky like “lock everything as tight as you can” or “don’t let users touch anything.”
But in fact I do think there is a useful answer to his question, and it is this: apply the Least Privilege principle to absolutely, positively, everything. If you’re not conversant with the term, it essentially says “Grant to any entity the minimum privilege it needs to function.” The entity could be anything from a kernel process to a network device to a user. And it applies to non-cyber things, as well. Do guests in your office have the ability to get into a server room? Can they see whiteboards with sensitive info on them? “Lock everything down” implies running around looking for things that should be more secure, and making them so. Least Privilege turns this on its head, saying that the starting state should be locked, and then access should be granted on an as-needed basis.
I can hear folks protesting, “But that’s what makes everyone hate IT, when they strangle the business by locking everything down.” That objection is reasonable, and in fact if overzealous IT decides unilaterally what is and isn’t necessary for the business, conflict is sure to ensue. Security usually will be diminished, since users will make (sometimes openly hostile) end-runs around the protections.
But strangling the business doesn’t have to be the outcome of applying Least Privilege, and in fact shouldn’t. That’s because, if there is a business need for something, then it falls under the “necessary” part of Least Privilege. If you’re doing a good job of defining security policies, you’re gathering a lot of data about what the business needs not just to function but to thrive, and granting access accordingly.
We’re seeing a lot of violations of Least Privilege in the world these days. Perhaps no technology segment is guiltier, at least right now, than so-called “Internet of Things” devices. As I write this, two significant IoT stories have dropped within the last week:
A researcher discovered that industrial control devices made by Schneider have been shipping with a firmware build that hard-codes a universal password. Not surprisingly, the devices are trivial to compromise.
A nasty malware variant called BrickerBot is in the wild, and it essentially destroys (through memory and file system corruption) IoT devices that it finds. It does this, at least in part, when the victim device has Telnet exposed to the Internet.
The mechanisms at work in both cases are violations of Least Privilege. When a password is hard-coded, that means that as soon as it’s in the wild, pretty much anyone who wants to, has access. While passwords in general have come under scrutiny as a very fallible security mechanism, at least when the user can create their own password, they have a fighting chance to limit the scope of people who possess the password (especially if they use a strong password). In the case of BrickerBot, if *any* digital device is listening on Telnet, it is fairly screaming to be compromised. Other than on honeypots, there’s just no excuse for leaving Telnet exposed.
I spoke to a local TV journalist a while back about ransomware affecting smart TVs. In a well-publicized case, the initial vector to the compromise was a pirate movie streaming app that turned out to be a hidden delivery mechanism for ransomware. In that attack, Least Privilege was violated on two different levels: one, the architecture of the TV’s OS meant that the app could get root access to the TV, rather than existing in a carefully-controlled sandbox. Second, for the vast majority of folks who have smart TVs, the device sits inside the trusted network. Therefore, an attacker who “pops” the TV now can easily move to other machines on the home network—including PCs that may have info like banking credentials, tax documents, and more.
And it applies to humans as well. If we all followed Least Privilege perfectly, social engineering would fail because we’d be on guard for access requests that are not legitimate. Perfection is not possible, but developing a security stance that marries healthy skepticism with healthy paranoia (they emphatically *are* out to get you) can spring-load you to think in a Least Privilege kind of way about any kind of request for information or access.
Looked at from the standpoint of the myriad complexities of deploying robust security policies that preserve an individual’s or organization’s agility and flexibility, “apply Least Privilege” is indeed an oversimplification. But it does provide a sort of North Star to keep in sight as we move toward better embodiments of successful security.
