I remember an interesting movie about an elaborate bank heist over a 24 hour period on Wall Street. Asides from the clever orchestration of the robbery by the thieves, the thieves used the same name or a version of the same name; they all called each other Steve, Stevie, or Stevo. When the detectives tried questioning the witnesses it was hard to know who was who, the thieves were all nameless. Names give identity to things just like in an organization, assets are named to help in their identification, prioritization, and protection. Also with names come access and restriction of access. Just imagine an organization where access to every resource is open to everyone? I mean ownership and access to all your assets have no restrictions by names. Imagine if everyone in your organization has access to all IT resources or has the same level of access to all IT resources. A janitor has the same access to your firewalls just as a network administrator so he could configure the firewall rules to allow some insecure ports and protocols. The CEO has the same kind of access to your financial applications with permissions for overrides and even the same rights as the Director of internal audit. Aside from the chaos and confusion that would result from such situations, it would be very difficult to know who did what. Think of a situation where the CEO decides to overstate revenues or misclassify expenses to favor the company’s financial position; he could do that without anyone knowing he did it, thereby facilitating a financial misstatement due to fraud.
You could also think of a system administrator having access to payroll applications as well as payroll files; he might decide to create a fictitious user account on the application or provision access to another employee to facilitate an embezzlement scheme. There could be a lot more damage caused when access to resources is not restricted based on the need. Unrestricted access is like having a house without doors or windows. While this kind of house would permit the occupants to move in and out of the building with so much ease and speed, it opens opportunities for theft and maybe worse things.
While it seems highly unlikely for everyone in an organization to have the same kind of access to resources; it is possible that some employees still possess some unnecessary access to systems and data in an organization. This could be seen in situations where employees move from one role to another: either through promotion or job rotation. Some organizations also have a structure that permits employees with higher roles to have higher privileges and rights; even though some of these rights and permissions might not be related to their current roles. For instance, a manager might retain access to a database associated with an application based on his past roles but in his current role; he does not directly utilize these data anymore. I have seen a situation like this, where the human resource department did not inform the system administrator about such role changes and therefore the unneeded access was not removed.
The principle of least privilege specifies that individuals or processes are granted only the privileges they need to perform their assigned tasks or functions, and nothing more. These privileges are a combination of rights and permissions which are assigned to users and this principle applies to regular users and administrators as well. A system administrator needs access to the systems in his domain but not to a domain he is not responsible for. He certainly does not need access to all the systems in the network. Imagine a situation where one of the system administrators has access to all domains. This might be because the organization would like an administrator to be able to replace another administrator should the need arise. While this kind of structure might be very useful and provide an opportunity for an administrator to observe the work of another administrator and learn from him, this could also create a vulnerability to IT resources. If an attacker obtains the credentials of such a system administrator, the impact of such an attack would be more since it could allow the attacker the opportunity to gain access to these other systems as well. It is best practice to ensure that system administrators have two accounts, one with a user account rights and permissions that are used for their daily tasks, and another with privileged rights which would only be used for system administrative work. This seems to be another way of applying the least privilege principle.
While certain services and applications require more rights and permissions beyond those of regular user accounts, it is highly important to ensure that services and applications run under the context of a user account; that these accounts are only granted the privileges needed by the service or the application. If an administrator configures all services and application accounts with full administrative privileges, an attack that compromises such services or application accounts would have a larger surface area or impact on more systems and data due to the administrative privileges of these accounts.
Last of all the principle of least privilege could help in securing databases. Although implementing input validation controls, adopting stored procedures, and utilizing Web Application Firewall in applications that have access to databases is really important for the prevention of SQL injection attacks, the principle of least privilege helps in minimizing the impact of SQL injections in relation to databases. For example, the principle of least privileged is being enforced when a database administrator grants a user access only to the tables, he or she needs in a database. This would drastically reduce the damage potential should there be an SQL injection attack; preventing bigger damages that could have occurred if such a user had access to the whole database. The principle of least privilege reduces risks in all IT environments.