See What we are Talking About!
The Principle of Least Privilege - Benefits of Securing a Database System
By: Frank Wright, Senior SQL Server Database Administrator
September 11, 2012
Definition & Introduction
Before we can learn about and understand the benefits we must first make sure we understand the concept. "The principle of least privilege (POLP) is the practice of limiting access [of an entity] to the minimal level that will allow normal functioning”[i]. Put another way, only give a person (or program or computer, etc.) the privileges necessary to get the job done. As an illustration, this principle can, and should, be applied to the physical world not just the digital one. In today's world of increased security, a large percentage of businesses implement some form or level of site security. This could involve a security guard in the lobby, or locked entrance ways requiring a PIN, card swipe, or some other form of authentication. Why do they do this? Simple. To reduce the risk of deleterious access to valuable assets such as equipment, money, data and intellectual property. There is no reason for a person not employed by, contracted with, patronizing, or otherwise not desiring a conducive relationship with a business location to be able to gain access to it. Nothing should be lost by restricting access to these unrelated parties.
Benefits are achieved by attempting to prevent attacks, both direct and by proxy, and minimizing the damage from attacks by limiting what the proxy has permissions to perform. i.e. If a virus infects a computer through the user logged in (the proxy) it cannot delete files, install itself, connect to other computers and steal information, if the user logged in doesn't have these privileges.
Primary Benefit: Data Security
As far as databases are concerned, the single greatest benefit of POLP is the protection of data. The risk is significantly reduced for data to be fraudulently manipulated or stolen if the pool of users who have access to this database is limited to only those who need it to perform their jobs. The prime example system that is common to most companies whose data needs protecting is the HR/payroll system because it contains two confidential pieces of information: SSNs & salaries/payrates. Access to this system should be limited to only those in the HR/payroll department. The protection comes from the fact that this small pool of users has been vetted and is trusted implicitly. We wouldn't let just anyone see this information. What if an employee saw that a colleague was making more money? What if a disgruntled employee emailed a list of salaries out to the whole company? What if someone changed their own salary? Chances are they would eventually get caught, but wouldn’t it be better if it wasn’t allowed to happen in the first place?
In current times, or whenever there is a down economy, companies are always looking at operational efficiency. One key way that can be achieved is through self-service. A company can limit replacement or expansion hiring if an application or module of an application can be installed to let employees/users take care of their own information. That small pool just got a lot bigger. Generally, an enterprise application will have protection measures built-in to limit self-service modules from exposing anymore than data for the current employee/user and usually contains an audit trail to track changes that are made. However, these features are usually only built into the application tier and not the database. For this reason we definitely wouldn’t give anyone permission to connect directly to the database. The application was designed to allow everyone to do their jobs so there is no need for additional exposure of direct database access where the potential for untracked changes or unnoticed theft of confidential data is much higher.
Benefit: System Stability
Another benefit from POLP for databases is system stability. Just like IT Support having to fix a PC with problems because a user downloaded and installed a freeware application, the same problems can happen on a database system. We limit who can login to a database server and make changes for very similar reasons. What if someone decided to accept a patch because Microsoft said it was a good idea or they downloaded a utility because it might fix a problem or complete a task without any due diligence? What if that patch/utility causes a change in functionality or causes an error with a particular database command? It could be because an API call changed due to a DLL upgrade or functionality changes that the database was depending on. You now have an application relying on that database which could be completely or partially inoperable depending on the level of use of the affected commands. Limiting access is one of the required components to reduce the risk of this happening. Now that IT functions are covered, what about business functions? A key feature of databases is to give users shared access to data without the data being on their PCs. Therefore, the ability to access data across the network eliminates the need for a user to login to a database server directly.
It was mentioned earlier not to grant direct database access to sensitive systems. However, for non-sensitive systems, granting access to connect to the database over the network might be the only means for looking at the data and is preferred over granting access to the server. POLP is factored in which privileges are granted to each user. We have already discussed not wanting to grant data modification permissions from a security perspective but it also needs mentioning from a stability perspective. Have you ever had to restore data because it was accidentally deleted? Usually concepts like POLP get attention as a reaction to such an event. The data may have been fully recovered but there is a risk it might not have been, and until the data was restored the application was rendered useless. Accidents can be as disastrous as malicious intent.
Let’s circle back and revisit a scenario where we don’t grant access directly to the database in order to illustrate that it’s just as important to also limit the permissions of an application connecting to a database. Don’t fall victim to a false sense of security just because the users can only access the data through the application. Obviously you’ll want to limit membership in the application defined roles but there is different threat. SQL Injection has gained a lot of recent exposure as a threat to application/database systems. “SQL injection is a type of security exploit in which the attacker adds Structured Query Language (SQL) code to a Web [or client application] form input box to gain access to resources or make changes to data”[ii]. Basically, this method takes the knowledge that the data typed into a field on a form is used to build a command to send to the database. With enough ingenuity, and malice, someone could enter data in such a way as to inject additional or alternate instructions thereby changing the command(s) that the database executes on behalf of the application. More often this will be used to cause destruction, but can also be used to create a security breach for the same reason hitting a piñata is easier than pinning the tail on the donkey. Regardless of the end result or intent we still want to prevent this from happening and cannot rely on an application, 3rd party or in-house, to properly cleanse its data inputs[iii]. Let’s say the attack was able to successfully submit (not complete) a malicious command to delete data or objects to the database. It would be irrelevant if the user/login used by the application to connect to the database didn’t have the authority to perform the command. The DELETE or DROP (or other destructive) command would immediately be aborted by the database due to lack of permission. Unfortunately, it is all too common for developers to set the permissions of the applications database login to be able to perform any command in the database either out of ignorance, sloppiness or both.
Although all the benefits and risks were not covered, hopefully you have a better understanding of the Principle of Least Privilege and realize the dangers of not implementing it. Implementing POLP will be discussed next, but in the mean time here are a few key points. Don’t jump off the deep end but don’t wait for an event to transpire to decide to implement POLP; be pragmatic and proactive so your business can continue to operate and doesn’t become the next news headline.