Two Cases for Least Privilege Control on Unix & Linux Systems

Server Privilege Management

Think about the methods behind most data breaches. The goal of an external attacker is to obtain the valid credentials of an internal user with elevated privileges. With the credentials of a privileged insider the external attacker can move laterally and remain unnoticed just as a normal user would.

The 2016 Verizon Data Breach Investigation Report confirmed two alarming facts regarding insider risks such as these:

1) “When we looked at the overall DBIR dataset, we found that the incidents that take the longest to discover were these inside jobs.” VDBIR 2016, 37

2) “When their roles were classified in the incident, almost one-third were found to be end users who have access to sensitive data as a requirement to do their jobs.”

Implementing a least privilege model not only prevents insider abuse, but it also slows down anyone from the outside who could compromise valid credentials. The trick is balancing security with access.

When implementing a server privilege management model there is a balancing act between the security initiative, end user requirements, and access that could permit users to bypass a system. The goal of a least privilege model is to enable a user to perform the tasks they need to fulfil their job, without providing the user any unnecessary privileges. At the same time, a user’s ability to perform tasks should not be impeded.

In this blog we’ll review two pretty unique use cases where this balancing act is so important: Contractor/Third-party access, and secure script execution.

Dealing with contractor access

Let’s say, for example, you have a contractor that comes in to troubleshoot and resolve hardware issues on several systems. The contractor requires root shell, however, this system has sensitive customer data on it. Beyond having one of your engineers oversee all of the contractor’s actions, how can you ensure the contractor can do his job without being able to see any of the sensitive data?

The answer: Advanced Control and Audit capability available in PowerBroker for Unix & Linux. Advanced Control and Audit (or ACA) provides a secure container for all applications at the very lowest system level, providing fine-grained control over interactions between the operating system and the user. This results in a faster and more secure way of providing root access for individual controlled applications or administrative tasks.

For a specific demonstration of this capability, check out this demo:

Managing secure script execution

Software installers and automation are common reasons sysadmins need the ability to run scripts with elevated rights. If this permission is granted with no checks in place admins could potentially modify scripts to perform whatever actions they desire. A common flaw is to permit the script to elevate vs. what is contained inside the script. All of this needs to be done without modifying existing scripts and should be future proof for new scripts that are built.

As above, PowerBroker for Unix & Linux helps overcome this challenge by providing enhanced system level control and audit capabilities over any application – regardless of how the application is initiated. This helps organizations control actual commands being processed and the actions at the system level removing the ability of command spoofing or altered key sequencing.

For a specific demonstration of this capability, check out this demo:

For more on how PowerBroker for Unix & Linux can help your IT organization achieve control over Unix and Linux root account privileges with centralized analytics and reporting, and keystroke logging, contact us today.

Source link