Least Privilege
The first step in implementing separation of duties is to remove unnecessary user privileges. Any unnecessary privilege provides an opportunity for a user to violate the AUP and perform unauthorized data access. It makes sense to use access controls to prevent unauthorized data access. The process of allowing only the level of access your users require might be tedious, but it is necessary to secure sensitive data.
The ultimate goal is to define access control where each user has the permissions to carry out assigned tasks and nothing else. This is the principle of least privilege. User permissions beyond what is required to carry out necessary tasks are excessive and potentially unsecure.
Security policies must make clear that individuals must only have the security rights appropriate for their job. The security policies also outline the required processes needed to ensure that when new rights are assigned, the leader approving the new access understands the risks involved. Removing prior access that is no longer needed accomplishes the following:
-
Reduces the overall security risk to the organization
-
Maintains segregation of duties
-
Simplifies investigation of incidents
Putting least privilege into practice can be challenging. Organizations with many users often use roles, or groups, to define access permissions. Administrators define roles that represent small tasks, such as “accounts receivable user” and “accounts receivable manager,” and grant specific permissions to each role. Individual user accounts can belong to one or more roles and inherit the permissions from each of the role definitions.
System Administrators
Applying least privilege to system administrators can be challenging. System administrators often need unlimited rights on specific systems. They are employees, and as such, the same concerns and issues for employees will apply to system administrators. By the nature of their roles, they will need the highest rights to be able to install, configure, and repair systems, such as operating systems and databases. The access right is often referred to as elevated privileges. With this access come enormous responsibilities to protect the information on those systems and to protect their credentials. A systems administrator’s credentials are a prime target for hackers. If they can compromise an administrator’s ID and password, for example, they may have unlimited access to install malware.
If, by the nature of the role, access rights are broad, then controlling or limiting access can be a challenge. One mitigating risk is monitoring and logging the system administrator’s activity. The system administrator should only be using broad access rights in the performance of specific duties. Let’s consider database administrators. They will need access to the database to apply patches, resolve issues, and configure applications. Yet they normally will not need to access customer personal information stored within the database. Logging their activity is a means to verify that they are not abusing their access rights. Logs could record if they granted themselves access beyond the scope of their roles or accessed information that was not part of their duties. While you may not be able to prevent a system administrator from accessing customer information, logs can be used as a detective control. A detective control can only report that a violation may have occurred while a preventative control will both detect and prevent a potential violation
But if system administrators have such broad rights, couldn’t they just turn off the logs? Yes, they typically can. However, the act of turning off or altering logs can be detected. Many systems write an entry when the log service is started and stopped. Additionally, logs can be sent to a log server. A log server is a separate platform used to collect logs from platforms throughout the network. Access to these log servers can be further restricted. Analyzing logs can help you detect gaps in logs, which are an indication the log service was turned off. Analyzing logs can also help detect if they have been altered. Knowing that their activity is being monitored can be a deterrent to system administrators.
There’s also a widely accepted approach that states system administrators’ access rights should be limited to their daily tasks, such as monitoring. This approach would elevate systems administrator rights through a separate process when they need to install, configure, upgrade, or resolve an issue on the system. The approach assumes that tasks associated with the elevated rights occur so infrequently that the additional process is not burdensome. Some system administrators resist this approach. Having unfettered access does make their job easier. This approach to elevate system administrator rights through a separate process has become a leading practice in a number of highly regulatory industries. The financial services industry, for example, has widely accepted this approach. Adopting this approach over granting elevated rights to their normal credentials has some key advantages:
-
It reduces the overall security risk to the organization. In the event the system administrator’s credentials are compromised, access would be limited.
-
It dramatically reduces the volume of logs to review to detect if administrators abuse their access rights.
-
It improves the alignment and understanding between technical tasks and business requirements.
Typically, this approach records the business reason for the elevated rights being granted. This answers the question as to “why” the security administrator would be accessing certain files. This information can also be used to identify patterns of control weaknesses.
The process for capturing business requirements and elevating privilege is well established. The process of granting elevated rights to correct a critical failure is often called a “firecall-ID” or “break glass” process. A firecall-ID process provides emergency access to unprivileged users. The name implies the urgency behind granting access to resolve the problem quickly. During a firecall-ID process, the issue or problem would be defined in what’s called a trouble ticket. The trouble ticket would then be assigned to someone to fix the problem along with the elevated permissions needed. The individual then completes the work and closes the ticket. When the ticket closes, access is removed.