jump to navigation

The principle of least door September 16, 2013

Posted by mtv in Security.

A few years ago, I was walking towards my car and noted an interesting behavior change in the way I remotely unlocked it: instead of pressing unlock two or more times to unlock all doors as I had in the past, I now found myself stopping after a single press, which unlocks just the driver’s door.  Why is this significant?  Because at that moment it dawned on me that this was a direct manifestation of what I had learned, championed, and implemented up to that point in my IT career–the principle of least privilege had begun to permeate my daily, far from technical practices.  Before elaborating further, a moment should be taken to understand the principle of least privilege.

In the following excerpt from “The Protection of Information in Computer Systems,” authors Jerome Saltzer and Michael D. Schroeder describe the principle of least privilege:

Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. [1]

I first learned of this principle when reading “The Administrator Accounts Security Guide,” first published by Microsoft in 1999, which stated:

Most security-related training courses and documentation discuss the implementation of a principle of least privilege, yet organizations rarely follow it. The principle is simple, and the impact of applying it correctly greatly increases your security and reduces your risk. The principle states that all users should log on with a user account that has the absolute minimum permissions necessary to complete the current task and nothing more. Doing so provides protection against malicious code, among other attacks. This principle applies to computers and the users of those computers. [2]

With this newly impressed information I took on my first initiative as a system administrator: revamping and hardening security delegation practices in our Active Directory environment.  In a nutshell, this entailed identifying all existing (or potential) administrative privileges required by users to get their jobs done, and offloading those privileges to be performed under separate administrative accounts.  The course I embarked upon is echoed in Microsoft’s whitepaper:

One reason this principle works so well is that it forces you to do some internal research. For example, you must determine the access privileges that a computer or user really needs, and then implement them. For many organizations, this task might initially seem like a great deal of work; however, it is an essential step to successfully secure your network environment. [2]

Yes, it was a great deal of work, and yes, it was an essential step to securing our environment.  What I didn’t realize was how far back the roots of my pet project stemmed, since in 1975 “The Protection of Information in Computer Systems” clearly addressed this concept, in that

…there are situations in which a one-to-one correspondence of individuals with principals is not adequate. For example, a user may be accountable for some very valuable information and authorized to use it. On the other hand, on some occasion he may wish to use the computer for some purpose unrelated to the valuable information. To prevent accidents, he may wish to identify himself with a different principal, one that does not have access to the valuable information–following the principle of least privilege. In this case there is a need for two different principals corresponding to the same user. [1]

Throughout the decade following the publication of “The Administrator Accounts Security Guide,” Microsoft reports that in assessing Active Directory implementations, they “invariably find excessive numbers of accounts that have been granted rights and permissions far beyond those required to perform day-to-day work” [3].  They add that, with few exceptions, attackers choose the path of least resistance, and in many environments that path has proven to be the “overuse of accounts with broad and deep privilege” [3].

So how does the principle of least privilege relate to a story of how I unlock my car?  A phrase you’ll often come across in descriptions of the principle of least privilege is that it is “quite simple.”  Same goes for the idea of “need-to-know” information: do you need to know it?  No?  Then you can’t have it.  Yes?  Then you can.  It really is quite simple.  Likewise, keyless entry systems are not very complicated, but a layer of complexity was added after its initial implementation.  For those who remember when keyless entry was “the latest-and-greatest thing” you’ll also recall that after a short few years this new, 2-step unlock process became the standard.  This was done for the simple reason that in some situations, the driver needs access to all doors, but in other (arguably most) situations, the driver only needs access to the driver’s door.  So why render the entire car unsecure every time?  On the part of the manufacturer, this principle, once established, was expected to be adhered to going forward–failure to do so would be akin to reverting to the old all-or-nothing keyless entry behavior, raising the question: why?  And yet, still, we find computing environments vulnerable to attacks that could be thwarted by proper implementation of least privilege.  On the part of the user, a much more personal lesson can be gleaned.

The most fascinating aspect of my unlocking epiphany was that the principle of least privilege became more than just a principle, it morphed into a mindset that ultimately served to bolster accuracy in my everyday risk assessments.  Without even realizing it, my behavior changed as a result of an internal interrogation: <press unlock>; driver door unlocked; press again?  Why?  Do I need any other doors open right now?  No.  Will I need any other doors unlocked where I’m going?  No.  Why did I ever unlock all doors before?  Because I wasn’t sure so I just unlocked them all just in case.  Is that sloppy?  Yeah, that’s pretty sloppy.  What do I think about sloppy decisions?  They are pretty hard to defend.  Am I afraid a masked man will intrude into my vehicle to carry out a crime?  Not really.  Is that probable?  Not very.  Is that possible?  Yes–and I’m not going to take part in allowing it to occur, especially for no good reason.

[1] Saltzer, Jerome H., and Michael D. Schroeder. “The Protection of Information in Computer Systems”. Proceedings of the IEEE, Volume 63 Issue 9. 1975.

[2] “The Administrator Accounts Security Planning Guide.” Microsoft Corporation. April 1, 1999. http://go.microsoft.com/fwlink/?LinkId=41315

[3] “Best Practices for Securing Active Directory.” Microsoft Corporation. April, 2013. http://www.microsoft.com/en-us/download/details.aspx?id=38785



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: