BeyondTrust
Application Control Unix & Linux


For the last five years, we have been discussing application control on Windows and how regulatory standards like the Australian Signals Directorate have made it a mandate. Whitelisting, blacklisting, and even greylisting have become so common place on Windows that we forget about how important this security control is on Unix and Linux. That’s why we need to discuss it separately.

When we think about application control on Unix and Linux, we need to consider it first from the command line: what commands should be allowed to run and which ones should be explicitly denied. Unfortunately, at this point it can get really complicated really fast. You need to consider:

Risks of Not Controlling applications on Unix and Linux

This makes application control much more difficult than a GUI in Windows. It also makes logging of all the activity essential since a threat actor can easily pipe output to avoid detection; something not necessarily possible from a UI. In addition, just parsing what a user enters from the keyboard is not sufficient either. Piping commands from a file, script, remote collection tool, or other location can bypass tools that just monitor the keyboard alone. A true application control solution on Unix and Linux needs to take all of these into consideration.

The Privilege Play

Now we are left with privileges. What privileges should the command, script, or updates execute with? Typically, these are launched from the command line too, but in order to function correctly they may need you to use sudo or Su as root – both of which are undesirable and have too much exposure; especially if you are implementing an application control solution for everyone.

This is where least privilege comes into play. It is another form of application control that elevates the application, command, or script to the proper privileges without the end user knowing the credentials or a root password. Policies are developed that are context aware. This performs the privileged elevation per action and granularity can be controlled for a specific task but limit exposure due to deviations based on desired behavior. Applications are controlled, privileges monitored and delegated, and users potentially limited and restricted to only the tasks deemed appropriate.

The Role of Logging

Finally, we are left with logging. For a Windows asset, we typically perform some form of screen recording; potentially hours and hours of video spanning a single application to being multi-monitor aware. Linux and Unix are different. We need to log what the user sees on the screen, what they type on the keyboard, and what they execute as commands and what is embedded in scripts. Luckily, this normally is all text. Once this is all gathered, it can be indexed and searched to determine if everything governed under policy and application control settings was appropriate. After all, if something was not, it could be an indicator of compromise.

How PowerBroker for Unix & Linux Helps

Now, back to solution. If all of this seems far-fetched, it is not. This application control capability is built into PowerBroker for Unix & Linux. PowerBroker is the gold-standard solution for application control, privilege management, activity logging, and file integrity monitoring on Unix and Linux. And yes, to be fair – you can do some of this with native operating system tools but not centrally managed, on premise or in the cloud, and not without the high availability and redundancy natively built into the solution.

Application control should not be limited to desktops only. It definitely should not be limited to just Windows either. All platforms can benefit from the principles of whitelisting, blacklisting, and greylisting and securing your most sensitive systems from improper utilization. For Unix and Linux hosts, this just become that much easier with PowerBroker for Unix & Linux. For more information on how we can help, or to schedule a demo of this capability, contact us today.

You May Also Be Interested In: