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. Allow listing, block listing, 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:
- Which switches and parameters can be added to the command line?
- Can the commands be in a script, and what scripts will you allow to run?
- How do you block the editing of files – including scripts?
- What privileges should the commands and scripts execute with?
- … and so on…
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 allow listing, block listing, 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.
Morey J. Haber, Chief Technology Officer and Chief Information Security Officer at BeyondTrust
Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.