Modern endpoint security relies on multiple security products and technologies to be effective against the on-going onslaught of malware, malicious code, and social engineering attacks. All of these threats map to fundamental functions that allow administrators to identify, protect, detect, respond and recover. Application whitelisting is not a silver bullet, rather it is only a tool in the toolbox of techniques to help drive down risk. Just like any security product that is deployed into a production environment, its goal should relate back to a core function of the security organization and provide leverage to a security team.

In this post, we are going to take a real-life example of implementing application whitelisting inside of Praetorian and the challenges that were overcome. You’ll learn more about application whitelisting, our process for evaluating a solution, and how we developed a plan for deployment. In part 2, we will provide technical guidance on how you can deploy Google Santa and Upvote in your organization.

What is application whitelisting?

Application whitelisting has been gaining traction over the past couple years; however, the concept is fairly old and there exists a slew of product solutions that offer this capability.

One of the main issues with application whitelisting is the overall user experience. Users tend to be prevented from performing legitimate business activities and their workflow is interrupted; leading to tensions between IT, security, and productivity. This simple negative can outweigh the security benefits of the technology such as creating user awareness, controlling software on endpoints, and stronger monitoring.

At Praetorian, we wanted to control the wild west while still providing tools and resources to our engineering teams to be successful in providing client value. We have engineers that have business cases to be downloading and developing on hacking tools, developing implants, and generally doing sketchy activities across their endpoint, containers, and VM devices.

The solution we chose, and why

We had three main goals, reducing the scope of running programs, increasing user awareness to the software they run day to day, and provide an inventory of all applications being used at Praetorian.

During the initial research, we found that Google utilizes a crowd-based solution for its application whitelisting initiatives internally. This is done via two modules; one is called Santa (application whitelisting) and Upvote (whitelist server) which work in concert to provide application whitelisting, while empowering users to add a binary to the whitelist.

We found that Santa is able to block any binary on a user system, however, scripting files such as python, perl, or bash can be executed along with dylibs. Additionally, there exist binaries signed by Apple such as the installer process (Installer.app) that can execute these scripting languages. This technique exists outside of the problem Santa is solving, however, it is something administrators need to be aware of when building their security stack.

Developing a rollout plan

We found the rollout plan to be a very vital component of deploying services like this because it relies heavily on working out the kinks users might experience before rolling it out to the general population.

We utilized a multi-phased effort where we hyper-focused on user studies with a limited subset of team members to gain feedback in real-time and develop a process that works for our unique needs at Praetorian.

A typical deployment should have the following phases:

• Infrastructure Setup
• Pointed User Study
• Production Deployment
• Training
• Release into GA

After we pushed our instance to production, we took an inventory of a number of related projects we wanted to complete in the future. Our primary focus now is monitoring for well known bypasses that circumvent application whitelisting on the macOS platform. To start, we modeled what normal behavior looked like and tuned our monitoring systems to follow up on events that break that model. Using Carbon Black, we can now focus on the known “bads” while letting it handle the majority of the detections and map to the MITRE ATT&CK framework.

Our approach to endpoint control

At Praetorian, we are managing our endpoint systems without having to use traditional technologies such as Active Directory, SCCM, imaging, or traditional asset management. We rely heavily on cloud technologies such as Okta, SimpleMDM, and Google App Engine to run the majority of our core infrastructure services. Following the mentality of one user per device, we are able to optimize and simplify our requirements with various tool stacks. This allows us to roll out network design patterns such as Zero Trust, Identity aware proxies, and layering device identity on services that traditionally did not support these features.

One of those controls is Application whitelisting utilizing Google Santa and Upvote. During our review of various solutions, we found some great features, bad points, and ugly issues that we had to account for during the deployment of the technology.

The good

Upvote provides a workflow to empower users to take part in the whitelisting process. We wanted to ensure that users felt they had overall control on their endpoint but making sure we were doing sanity checks with their peers when running unknown software on their system. We found out after the rollout, users discovered a lot of software they had installed which they were not using actively. This has encouraged users to utilize single-use VMs for 1-off tool usage that does not provide a direct day-to-day contribution to their workflow. This has benefited with a hyperaware security culture where peers question and provide feedback to each other in real time and continue keeping a constant understanding of the risk tolerance across the team. Finally, rolling this technology out improved our CIS CSC 2 (Inventory of Authorized and Unauthorized Software) and NIST CSF Subcategories of ID.AM-2 (Software platforms and applications within the organization are inventoried). This gave us an opportunity to strengthen one of the harder CSC and CSF subcategories that many organizations struggle with.

The bad

Santa which is the module that enforces the actual whitelist control can become a workflow interrupter during the initial rollout. During our initial user study we found that a user may get prompted to whitelist twenty or thirty applications. However, as we continued to onboard more users this number dropped down to less than five and in many cases non-technical users saw zero prompts. An additional concern was introducing too much overhead, causing users to just run workloads on personal devices rather than using their company-issued device. Finally, there is an associated cost that the organization incurred due to productivity loss during the first couple of days, which required management approval. We utilized the NIST CSF framework as a means of justifying this additional expense.

The ugly

There are well-known ways to bypass the Santa whitelist control because of macOS and how it handles scripting languages. Additionally, if an attacker is able to trick a user in running a script such as Python, Perl, and even Bash they could take remote control of an endpoint. Security should always be implemented using layers and where additional controls, such as an EDR solution, can be used to complement weaknesses or gaps in other protections. An important thing to note is that Santa is not designed to mitigate other vectors, such as script-based attacks.

How to deploy Google Santa and Upvote

In part two of this post we will provide technical guidance on how you can deploy Google Santa and Upvote in your organization. This includes deployment of the Upvote application running on Google App Engine, the Santa component that enforces application whitelisting on endpoints, and configuring an MDM solution to manage both device identity and deployment of the Santa application.

Read: Implementing Application Whitelisting with Google Santa and Upvote (Part 2 of 2)