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 Security Officer, BeyondTrust
Morey J. Haber is the Chief Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored three books: Privileged Attack Vectors, Asset Attack Vectors, and Identity Attack Vectors. He is a founding member of the industry group Transparency in Cyber, and in 2020 was elected to the Identity Defined Security Alliance (IDSA) Executive Advisory Board. Morey currently oversees BeyondTrust security and governance for corporate and cloud based solutions and regularly consults for global periodicals and media. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition where he served as a Product Owner and Solutions Engineer since 2004. Prior to eEye, he was Beta Development Manager for Computer Associates, Inc. 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.