In the first part of this series, we described a real-life example of implementing application whitelisting inside of Praetorian and the challenges that were overcame. Readers learned 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.
Read: Implementing Application Whitelisting with Google Santa and Upvote (Part 1 of 2)
First, we conducted multiple studies in order to understand user workflows so we could proactively whitelist commonly used applications. This allowed us to dramatically decrease the number of applications users had to whitelist in order to get back into their normal workflow.
There are three components to our deployment:
We found deployment fairly easy compared to most products. The deployment guide provided with Upvote will give you just about everything you need. However, if you are unfamiliar with Google App Engine you may run into issues. We found that using a docker container to build the application provided a consistent environment and minimized a number of potential deployment headaches.
These are the steps we took to deploy the application:
-- CODE lang-xml --FROM ubuntu:16.04
#first lets get bazel setup
RUN apt-get update
RUN apt-get install -y openjdk-8-jdk curl git nano
RUN echo "deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8" | tee /etc/apt/sources.list.d/bazel.list
RUN curl https://bazel.build/bazel-release.pub.gpg | apt-key add -
RUN apt-get update && apt-get install -y bazel
#Get gcloud bins
RUN echo "deb http://packages.cloud.google.com/apt cloud-sdk-xenial main" | tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
RUN curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
RUN apt-get update && apt-get install google-cloud-sdk -y
RUN mkdir /app
#get python deps for upvote
RUN apt-get install python-pip python-dev -y
RUN pip install six
WORKDIR /app
RUN git clone https://github.com/google/upvote.git
After that, continue with the following:
In addition, the Upvote application can be placed behind an identity aware proxy (e.g., Google BeyondCorp style proxy) to control access to the application with both user and device authentication.
At Praetorian, we believe all aspects of our IT environment should be code. We use a configuration manager called Chef to manage the deployment of software on endpoint systems. With Chef in our stack, getting the binary service installed was as simple as writing a chef script and deploying that to our internal endpoints.
-- CODE lang-xml --cookbook_file '/opt/praetorian/santa.dmg' do
source 'santa-0.9.31.dmg'
mode '0700'
owner 'root'
group 'wheel'
end
dmg_package 'install santa' do
accept_eula true
file '/opt/praetorian/santa.dmg'
type 'pkg'
not_if {File.exists?('/usr/local/bin/santactl')}
end
Once Santa is installed across the environment, the final piece is to tell Santa where to check-in for whitelisting updates. This leads us to configuration of the MDM.
The MDM provider will supply this component of the toolchain. We use SimpleMDM, however, any macOS MDM provider that accepts .mobileconf files will work. First, we needed to deploy a custom .mobileconf to all our endpoints. This can be done with or without Santa installed.
SimpleMDM has a nice feature called attribute support. You will need to make sure you fill out the MachineOwner key with the users' email address. Without this, Upvote would not be able to customize the whitelist for the endpoints on a per user basis. We will be releasing the cloud functions that allow us to marry Google with SimpleMDM and the device identity in a future blog post, however, this step can be done manually.
-- GIST https://gist.github.com/myover/90a4197b133b6ed616be1dfb37e106d9.js --
Finally, we need to whitelist our Santa kernel extension. This can be achieved by a .mobileconfig or using the native tools built into your MDM provider.
By default, Santa will check in for a new whitelist every 10 minutes. If a user upvotes something, they may want to force a Santa sync using sudo santactl resync. This may work for engineers, but not for business users. We developed a wrapper script using the Hello IT menu to make syncing the whitelist more user-friendly.
A sample MDM profile that provides a button to sync the whitelist.
-- GIST https://gist.github.com/myover/bd1c8d7ee671af3b0d8c8faec17b429b.js --
And the script is as follows:
-- GIST https://gist.github.com/myover/0c7f7e49b37d1312c6f55dffa7d4e5ce.js --
So after we got a deployment going, we started determining the best method of training users and soliciting feedback from people we suspected this change would highly impact and potentially disrupt. During this period we worked one-on-one with users to determine what would negatively impact their workflow the most. Using this information we pre-whitelisted applications that were running on users’ workstations. As part of our deployment, we put all workstations into monitoring mode and would only enforce an endpoint after that user completed training. Monitoring mode made it easier to pre-whitelist applications for users to remove some of the burden of implementing application whitelisting.
From the post-deployment survey, we saw a trend where most users only had to whitelist one or two apps and their normal workflow returned to normal in under 1 hour.
From the user study we determined that user training was required to further minimize negative impact to the end user. Because of this we decided to only enable the control after the user was properly trained and also ensured the training spanned a wide audience, from technical- to business-groups. Our training materials included the following aspects:
We noted several future projects worth exploring, which include:
Whitelisting is not a silver bullet, however, it can provide an additional control to help pigeonhole attackers into predictable patterns of behavior in order to increase the chances that a potential attack will be blocked, or if an attacker is able to execute a payload, they will be restricted to a set of well-known tactics, techniques, and procedures that are all monitored and baselined for anomalies. We found that user training and explaining the motivation behind application whitelisting provided considerable buy-in from end users.
Using a system such as Upvote, we found that users felt they were still in control of application whitelisting and users themselves have had the largest impact in the solution’s success.
