Rule of Least Privilege |
The Rule of Least Privilege is the most fundamental and well known of the security rules. If this rule is not practiced, the peasants will soon be using the throne room as the privy and the treasure room as their own personal piggy bank. The Rule of Least Privilege is that simple. So, whether someone is new to information security or is spending their days contemplating the Clark-Wilson and Bell-LaPadula access control models, this essential rule is what it all comes down to.
Allow only as much access as is required to do the job, nothing more. In addition, allow only as much access as an individual, group, or subject is capable of being securely responsible for. In any and all situations, it is best to start with the idea that nothing is allowed and work from there. This is the one and only way in which we can be sure we know who has access to what, and why.
To work with the Rule of Least Privilege, we must first understand the components involved. There are numerous access control models that deal with privilege in different ways, but they all use similar components. The following list covers some standard terms when dealing with access control:
Object— The person, place, or thing the subject is gaining access to
Context— The situation or circumstances surrounding the access
Table 4.1 shows some examples:
Subject | Object | Access | Context |
---|---|---|---|
Regular employees
John the janitor Systems across the Internet Unsecured networks Locations outside the country | A physical system
A network address Normal data Sensitive data An application | Read
Modify Execute Physically touch Physically see | During off-peak hours
From the local computer without supervision Via an Internet-based VPN Through a secured relay |
Whether installing a firewall, building a new network connection, or developing an application, we must always reflect on this primary rule. Given a situation, we deny all possible access, and then, as required, we define exactly who needs access to what, and how.
Unfortunately for security, the natural human tendency is to simply put objects “out there,” without any restrictions, and then try to secure them. Thus, our most common methods of security are derived from a long series of post-implementation controls such as, “Let's block this… and that…. oh, and this as well.” However, taking into consideration the billions of “thises” and “thats” possible in the information arena ultimately leads to an insane level of complexity that quickly becomes unmanageable.
Example of Security Considerations Based on Subject, Object, Action, and Context Using the Rule of Least Privilege
Ever notice that when account administration is performed, the administrator is not allowed to see the end-user's password? One may wonder what the point of this is when the administrator has full access to that account, or could simply change the password to gain access. The truth is that the administrator never needs to know the end-user's password to perform his or her duties, and by denying all such unnecessary privileges, we enhance the security of the environment. In this case, the Rule of Least Privilege can protect the end-user's password in case it is shared among other systems, and it also forces the administrator to take extended actions (which will be logged) when gaining access to an end-user's account. There are actually numerous reasons for denying such actions that may not be immediately obvious. By following the Rule of Least Privilege, however, we solve the problem without having to account for all of these details. |
Consider this scenario: We just put a new Payroll server online in our financial network. After getting it running and tested, we then take a look at security and begin to decide how we will protect it. Here, we attempt to ponder all the things we don't want to happen to this server:
No one should have access to administer the system over the Internet since the Internet is impossible to secure.
New employees should not have access to modify sensitive data since they may destroy valuable information.
Accessing the system via Telnet is really not secure, so we should remove that capability.
The janitor who comes in at night should not have access to play video games on the system.
If we take even a simple situation with five employees, five systems, five networks, and five physical locations, we will come up with a list of a few thousand circumstances, and we will still be missing vital security holes. This problem can only be remedied through the Rule of Least Privilege, defaulting to no access and then specifying what is allowed. Lawyers follow this practice, as do casinos, the military, and now information security personnel.
Have you ever been to a casino? If you ever wanted to learn about the Rule of Least Privilege, Las Vegas is the place to go. Casinos are built from an initial foundation that “nothing is allowed,” which is later eased to allow only the most controlled of actions. A casino will allow its customers to walk all over its front end. The moment, however, a customer attempts to step over the line, the Rule of Least Privilege steps in, and there are no excuses and no exceptions that will allow someone beyond that access control point! |
Most successful attacks are based on exploits that take advantage of seemingly innocent access. No one could ever possibly predetermine all the ways someone could hack into an object. Thus, the Rule of Least Privilege can be taken to far extremes before ever being considered obsessive or overprotective. For instance, do employees really need to ping systems on the Internet? We may not consider this a risk, but in reality, some hacker tunneling protocols can be established using the protocol Ping belongs to. By simply allowing outbound pings from our internal systems, we are taking on an unnecessary risk that could lead to an exposure. Following our Rule of Least Privilege, the relevant access restrictions regarding ping should be as follows:
Our firewall blocks all pings to anyone.
Administrators of our network will need to be able to ping the outside for testing, and we would incur a high cost in productivity if they could not, so ping is allowed from administrators to the outside.
No one else has a real need for ping, and thus it will not be enabled for anyone else until there is a practical business need.
By the nature of the rule, restrictions can never be taken too far. If the rule ever causes a conflict, then the rule is not being used correctly. For example, if so many restrictions are placed on an employee that he or she can no longer be productive, then we are obviously not following the Rule of Least Privilege. If an employee cannot perform his/her job without access, then the Rule of Least Privilege will say that such access should be granted. Just keep in mind that those things that are required to keep employees productive, customers happy, and business flowing are the very things that are considered “essential” and should be allowed to take place. Everything else should be blocked until such a time as they become required.
While writing this book, I often sent encrypted backup copies to a partner of mine in California. I never, however, told him the key that could unlock the encrypted files. This was not a matter of trust, nor could I imagine that he would do anything to harm the work. There was simply no need for him to know the secret key or access the information, and thus this process was subjected to the Rule of Least Privilege. |
This rule should be applied to everything needing security. The degree to which the rule is enforced should only be moderated as to not create an excessive burden on devices, employees, administrators, and customers. By “excessive,” I mean any measure that causes more harm than good. But be careful with how “excessive” is defined, and always compare it against the idea of being hacked (I will address evaluating risk later in Chapter 8, Practical Security Assessments).
The Rule of Least Privilege should be taken into consideration when any decision is made to introduce a new device, service, application, network, or access point in an environment, or when making any change to the environment. This rule is one of our only defenses against hidden security vulnerabilities that are not normally discovered until exploited. Thus, the more restrictive we can be in allowing access to objects, the less likely we will find ourselves on the receiving end of an attack. Here are some practical tips to help apply this rule:
Create all security policies from a stance of the Rule of Least Privilege— When considering access to different objects, write down exactly what is allowed and finish by stating that all other forms of access not explicitly listed are in violation of the policy.
Always begin by denying everything— Applications, databases (DBs), network devices, and all other object access points should start from the point that nothing is allowed. Once everything is denied, authorized access should then be specified taking into consideration the subject, context of access, and different levels of privilege. Trying to program openly and then blocking out vulnerable actions later can be a very dangerous practice.
Always include the Rule of Least Privilege in all of the following security practices:
Written policies
Rules for firewalls, proxies, router controls, and all other network-based controls
Server implementation, hardening, administration, and all other system-based controls
Local workstation implementation and end-user access privileges
Development or implementation of new applications, services, and DBs
Physical access to sensitive areas and devices
Here is a quick method to use to apply the Rule of Least Privilege in a security decision. Creating a one-page document with all the following information will be extremely helpful for understanding and reflecting back on your decision in the future. As always, the steps below are a guideline; be sure to keep an open view and embrace the concepts behind the steps given:
18.188.241.82