 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. Concept 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. Subjects, Objects, Access, and Contexts 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: Subject The person, place, or thing gaining access Object The person, place, or thing the subject is gaining access to Access The level or degree of access given to the subject Context The situation or circumstances surrounding the access
Table 4.1 shows some examples: Table 4.1. Sample Components of Access ControlSubject | 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. Natural Tendencies 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 System administrators are allowed to access Application X to add, delete, and modify accounts from within the LAN between the hours of 8 a.m. and 6 p.m. End-users are allowed to access their own account information for reading. This can occur anytime and from any external location. No other access is allowed into this application until formal amendments are made to this rule set.
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! |
How Far Is too Far? 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. |
Practicing This Rule 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
Five Steps for Applying the Rule of Least Privilege in Any Situation 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: Start by writing, programming, placing, or configuring controls to allow NO ACCESS. Classify the objects (the items to which we are gaining access), the subjects (the people or things gaining access to them), the access in consideration, and the context for access (over a network, from a secure system, etc.). Remember that a subject can be a person, a group of people, an application, or any other thing that needs access to the object. Determine if the subject really needs access to the object, under what circumstances, through which means, and how important it is that it gains such access. Consider whether or not the subject has a strong need and a high enough level of responsibility to access the object. Focus attention on the following details: Required access (Does the subject need it?) What level of access is required in the subject's role? Only this level of access should be assigned. Access responsibility (Can the subject handle it?) Is the subject trusted enough to handle the access? Does the subject have enough security itself? If the subject is a person, has he or she been trained and screened, and has he or she signed the proper legal agreements?
Access context (Is the context safe?) Under what context is this access safe to take place? Can we trust the location, the system, and the time frame for the access?
Using the information gained through this process, we are now better armed to make a sound security decision. Even if the decision is to allow for unlimited access to a critical resource, we have at least gone through a formal consideration process and weighed the factors, and we are not naive to the potential issues. Document the level of access that is to be granted so that a record exists and so that similar situations can be addressed without having to go though this process again.
|
