BSidesSF 2020 - Developing a Baseline Security Standard for Endpoint Devices (Claire Moynahan)

so these are lightning talks so 10 minute talks gonna be real quick today we have a speaker Claire Moynihan and she's gonna be talking about the road to zero trust so I'll hand it over to you do I need this one rather son okay thank you very much Andy yes sir today we're talking about don't trust the endpoints the purpose of this talk is to review a zero trust implementation schema with the focus on building trust and users devices not simply the user themselves okay so my name is Claire Moynihan I'm an enterprise security engineer at Salesforce I've been working on this project for approximately two years now I started it in 2018 as an interim of

Salesforce at that time I was looking at how to implement Google's beyond core model for a broader enterprise use 2019 I returned to school graduated 2020 I came back and joined what my project had become as a member of the device compliance working group the purpose of that group was to establish a zero trust model for the enterprise and the purpose of this talk is to discuss our research up to this point so first we're going to review a really really high level just what is your trust network is and how our project aims to go one step further so a traditional zero trust network model recognizes that trust is a vulnerability and it recognizes that if

educated users can also act as malicious attackers you all probably know that our implementation of zero trust aims to go one step further we want to recognize that a user's device can also act as an agent of compromise and we aim to verify the user's device using the devices configuration statuses so essentially we want to verify a device's configuration or compliance status prior to the device receiving full or appropriate network access so for this phase of the project for its concentrating solely on endpoint devices specifically laptops and workstations for our purposes right now servers and mobiles are out of scope for our user population we've concentrated on the largest volume of operating systems that would be Windows 10 Mac OS

and a bun to Linux 18 after finding the focus of our the scope of our hardware our next step was defining the baseline security configurations or what defense capabilities do we expect the president on all managed enterprise devices second we wanted to document a method to pull those configurations in order to determine the device's compliance rate third we wanted to measure how the current device capabilities compared to the expected capabilities we recognized that this would be different across the three different operating systems based upon in eight different configurations we also recognize that certain compliance mechanisms would be difficult to measure so they might not be present in our tooling set and fourth we wanted to determine the best ways to make this

process actionable or how would we automate this and scale it across the enterprise with the goal of being to measure and verify baseline configuration compliance rates for each individual endpoint device and for the enterprise as a whole so we started with just determining what our baseline security configuration should be and this is a high-level overview but as you can see these baseline configuration statuses essentially are modeled after the CIA triad we wanted to document the configuration measures necessary to ensure operating system and file system integrity these listed configurations also reflect our internal security policies only approve software and kernels only approved remote access mechanisms only approve pseudo accounts etc basically though they're meant to protect against unauthorized system

access so next we were looking at how to document normalize and measure these configurations we wanted to normalize the outputs from these three different operating systems across basically one to normalize them into a boolean true false value and the goal was the results of this normalization would provide the data necessary to calculate the enterprises compliance rate so this was our process and this slides a little bit messy so bear with me essentially what we were doing were you to document the compliance rate across the enterprise to ensure that the metrics met our SLA s we also were looking at the best tooling system to gather normalize this information so first we started with command line

scripts these scripts enabled us to determine what sort of settings we would even be able to call and verify however this output was messy and it was going to be difficult to normalize this output across the windows and UNIX systems next we looked at what tools were already currently present or should already be present on our manage devices she looked at MDM tools the detection response tools the MDM tools also were a bit messy number one the MDM tools at least for our purposes were unique to each operating system number two as you can see from my slide there's a lot of holes in the configurations that we could even verify so if we went with an MDM tool

you're going to have to do a lot of internal scripting to enable that system to work and after gathering whatever information was there we were gonna have to pull the information into like an entirely new database what we ended up doing is looking at our detection and response tooling which was the same across the three different operating systems in addition the detection and response tool enables us to write queries that were granular enough to look at the coast or the computer's name the operating system and then pull whatever configuration we wanted to verify these queries what could also be scheduled so enabled us with that automation configuration that we were looking for so this were automating this tooling

represents the end of our phase 1 of this project this is an example of what our automation looks like at this time and so for our purposes at this point we're looking at pulling this for the 5th column into our API call upon pulling into an API call those configurations will be verified when the device authenticates to the network so currently all of this is being run in our dev environment as we move into phase 2 we're looking at how to take the configuration statuses that we have in dev environment and query them via an API call so when the device event when the user authenticates to the network the workflow ideally will be these are

indicates with 2fa after that the host certificate and its compliance status is called now this step is a step that we're still considering if the compliance status is incomplete or if there are certain configurations that are enabled certain configurations that aren't enabled we essentially have two options one option is the tooling can be triggered that if the configuration is not enabled or the value returns false we can automatically set the tool to enable that configuration therefore forcibly enforcing that compliance rate or we can provide the user with a security education process and state this configuration is not enabled here's how here's the self-help and how you can re-enable this or fix this so as we're looking at phase 2

these are the questions that we're looking at in terms of the final point of or how to make this process more actionable and also keep it from each of the user any questions at this time ok thank you perfect yep currently we're looking at 10 a.m. yes yep in the green shirt our engineer I'm sorry all of our users have local admin rights so all users have root access which means that all of the configurations that should be present on the device can be arbitrarily changed by users if they choose to do so that's why we wanted to that's basically the purpose of this project yes and the black shirt so the MDM tools that we're looking at again

since I said they're a unique across with your operating systems we currently use bigfix jams and puppet so it's just gonna be hard to normalize from those three different platforms and yes in the front row or gray shirt yeah yes so the next step as I was saying of like this step three you are actually implementing this is that in accordance with SLA is okay this is currently out of compliance or not in configuration you have limited like it's a like gradual degradation in network access so at some point after the 30-day period okay no network access this is what needs to be fixed that's if we give the user the choice to self-correct it if we choose to

automatically correct it then essentially will be just forcibly enforcing these compliance rates does that make sense okay okay yes so right now we do not want to grant and revoke certificates we just want to look at what network we're looking at whoa I think that's my time we're looking at Network ackles okay sorry one minute my time is fast okay well looks like there's no more questions thank you very much everybody [Applause]