UFS Spotlight: Jesse Kriss of Netflix
Welcome to the User Focused Security Spotlight! In this blog series, we interview key figures involved in making security more accessible and transparent to end-users. We will inquire about their contributions and thoughts on the UFS space, ask for advice, and more!
In our inaugural edition of the User Focused Security Spotlight, we are proud to interview Jesse Kriss of Netflix. Jesse is the technical lead in Netflix’s User Focused Security group, and one of the core developers of Stethoscope, which provides end-users with recommendations and advice to keep their company assets secure.
A screenshot of the new Stethoscope app r unning on an employee’s macOS device.
Jesse has been a major champion of User Focused Security, and first introduced the term to the public in Stethoscope’s open source announcement in 2017. Now that we are in 2019, we wanted to circle back with Jesse and hear about how his perspective has evolved, and solicit his advice for folks interested in implementing UFS at their organizations.
Let’s see what he had to say!
Tell us about yourself, your role at Netflix, and your history working in Security Operations.
I’m currently the technical lead for User Focused Security, which is part of our larger Information Security organization at Netflix. Our team works to make the end user experience around security as smooth as possible for the people Netflix trusts to run our business, create innovative content, and increase viewer joy.
It’s a role that combines user centered design, software engineering, and product strategy in order to achieve our security goals with minimum friction and frustration.
When I started at Netflix about three years ago, it was actually my first job in security. My background is in web development, human-computer interaction, and information visualization, and I’ve done various combinations of those things at IBM Research, Figure 53, the Obama 2012 tech team, and NASA/JPL. I joined Netflix just as the security team was starting to build more tools for wider audiences, so it made sense to bring someone in with specific expertise around building software for humans even though I didn’t have a security background. One of the fun things about design work is that the same processes work for different domains, and it’s always fun to learn about a new area of practice.
What is Stethoscope? What problems is it designed to solve?
Stethoscope started as a web application that would let people view the security state of all of their devices, along with instructions on how to get them into a better state, like encrypting a hard drive or turning off remote login. We’d bring in information from other systems, like JAMF, Landesk, and Google MDM, and present it all in a relatively straightforward way. This project actually started shortly before I joined Netflix, and I worked on the UI design and implementation for the first version that Andrew White and I presented at ShmooCon 2017.
The goal here was to make it easy for people to know what to fix, and how to fix it. For basic things, like disk encryption and turning on firewalls, we felt there was value in people understanding the features and why they’re important. And if they felt they really needed to leave a feature in a less secure configuration, perhaps temporarily, they could do that without it being forced back.
The second phase of Stethoscope was the Stethoscope app. This is a desktop application that runs the checks locally, and provides recommendations. If you just open it and run it, it doesn’t report back to any servers. In fact, it’ll work totally offline. But it also runs a local-only web server that allows requests from a certain set of urls. In our case, we allow access from our single sign on portal, so that we can use javascript in the login page to check information about the device at authentication time.
There were a few problems we were aiming to address. First, Netflix has a culture of transparency, and values freedom and responsibility. These principles don’t align very well with the typical systems management approach. Invisible software with admin rights pushing out centrally managed policies works against that ideal, in addition to having fairly significant security risks if the admin controls are compromised.
For a variety of reasons, we also don’t strictly control the inventory of devices that can connect to internal Netflix systems. It’s totally fine for a Netflix employee to buy a laptop at the Apple Store and use it for work. We also have a significant number of vendors, contractors, and other third parties who need to access our systems, and we’re very unlikely to control that hardware.
Given all of these things, we prefer to have a model where we can check machine configuration at access time, give people clear guidance on how to make simple changes themselves, and not rely on strict inventory or a trusted bootstrapping process. Stethoscope gives us that ability.
From what we can tell, the first mention of “User Focused Security” as a term of art came from your introduction to Stethoscope blog post in 2017. Can you tell us more about how/why you chose the name?
The term was actually being used within Netflix security before I joined, but it hadn’t been used publicly, yet. I’ve seen the term “end-user-focused security” before, but typically in the context of training and awareness, not software tools.
In its original usage at Netflix, I understood it to be akin to “identity is the new perimeter"–that we’re ultimately focused on the security in the context of the user. Questions about the security of an account, device, or session, are all ultimately about the user.
It also has a nice resonance with user-centered design, one of my areas of training, so I expanded the term a bit to also include the idea of security approaches that are designed with a focus on the context of use, appropriateness, and usability. It brings in the recognition that for a security tool to be useful, it has to actually be used.
What have you learned about effective User Focused Security since 2017? How has that impacted future versions of Stethoscope?
Anytime you’re trying a new kind of approach, it’s really important to be clear about what you’re trying to achieve, and how it should be measured. It’s a chance to drive towards what you actually want to achieve, and the use cases you want to support, rather than just following the usual industry metrics. Often, a new approach won’t even be directly comparable.
For instance, at first we thought we’d move to the Stethoscope app exclusively once it had a reasonably high level of coverage. But even that simple statement is tricky–given that knew we had devices before that weren’t tracked by systems management, we didn’t actually know what our target goal was.
Ultimately, I think it’s much more helpful to describe goals in terms of outcomes. If a laptop is reported lost or stolen, how likely are we to know if the disk was encrypted? If we need to send an email to everyone using a certain version of an operating system, how accurately can we target the audience? With cases like that, we can be clear about the specific workflows we want to support, and we can have a discussion about how comfortable we are with a given level of certainty.
How do you encourage stubborn users to keep their devices secure? Are there consequences if you ignore Stethoscope at Netflix?
For people who either aren’t running the app, or who haven’t changed their settings appropriately, we have a variety of tactics. Sending out email reminders has boosted our numbers, especially if we focus on a particular practice, like disk encryption. We’ve also had success going to the managers of specific departments and enlisting their help. It’s easy to say, "Hey, it looks like people on your team don’t have the right settings. Could you ask them to go to Stethoscope and make fixes?”
One interesting thing is that Stethoscope can help us enforce other best practices. Every so often, someone will come to us and say, “Hey, I actually need remote login turned on to do my job, can you make an exception for me?” So far, those cases have all led to us being able to recommend a different workflow for the task.
Beyond periodic nagging, there aren’t currently any more serious consequences for ignoring Stethoscope at Netflix. That said, we may very well get to a point where we’ll require a recent passing Stethoscope check to access particularly sensitive applications.
Do you see User Focused Security compatible with traditional user endpoint security monitoring, or are they mutually exclusive?
I actually think they can complement each other very well. First off, I think of User Focused Security as an orientation and a philosophy, one that can extend well beyond endpoint security. Secondly, I see Stethoscope as a lightweight approach to validation and guidance that can be used across a wide range of situations and context, with varying levels of control over–trust in–the actual devices. It’s totally fine to have a subset of tightly managed and controlled machines that also happen to report via Stethoscope. You’d simply expect that group to always pass policy checks.
Why not just use MDM solutions to enforce the security practices that Stethoscope covers? Wouldn’t that be easier and more effective?
If you have that option, and the person using that device finds it reasonable, then sure. But what do you do about devices you don’t control? Do you somehow keep devices without MDM from accessing your internal web applications or SaaS apps? Do you make all of your vendors and partners install your MDM profiles? Stethoscope is really about having lighter weight visibility into a larger set of devices and workflows that you can get with standard MDM.
Often, just getting the machine in the right state when it’s first set up is the biggest barrier. If somebody gets a new device from our help desk, which is typical, they’ll set things up to match the Stethoscope recommendations. From there, a lighter touch is usually sufficient.
A lot of folks we speak with feel User Focused Security can only work well with very technical end-users like software engineers. Does this match your experience?
The necessary expertise for these configuration options is pretty minimal. If somebody’s comfortable opening up System Preferences, and maybe typing in their password, then it’s not too high of a bar.
The issue in my experience is actually more about expectations around whose job it should be to manage these kinds of settings rather than level of expertise. We do hear along the lines of “Shouldn’t this be done for me? Netflix didn’t hire me to manage my security settings.” I think this is totally valid, and in those cases, Stethoscope can be used as a quick check for whoever is doing the setup, and can be used to make sure those settings don’t drift.
That said, I think when security is managed for non-technical users without their involvement–and especially without their knowledge–we’re missing an opportunity. User Focused Security aims to educate and empower end users so that they can become partners in security, ideally taking their newfound knowledge to their personal devices and beyond. Less technical users are still perfectly capable of understanding essential configuration options and tradeoffs if they have an interest.
You recently formed a dedicated team around User Focused Security. Do you expect that team to focus solely on automation and tools, or are there non-technical aspects to the team’s mission?
There are definitely non-technical aspects. Rather than treating the team as a focused development shop for particular tools and automation, we’re really aiming to change the actual process of designing the tools and processes so that we are finding optimal solutions for both the real context of work and our security goals. We want to figure out new ways to combine our technical services, capabilities, and platforms into the most effective, clear, and low friction product suite, while aligning with the principles of our company culture.
What advice do you have for companies interested in implementing User Focused Security?
The only kind of security approaches that work are the ones that are actually used. And any friction and confusion that your tools, processes, and controls create are costing you both money and the goodwill of your users. An investment in better matching the needs of your users should improve your security posture while giving time back to people that they can spend doing their job well. Or, put another way: challenge the status quo for fun and profit!
On behalf of Kolide, I want to thank Jesse for providing such detailed answers to all of our questions. I also want to thank all of the engineers at Netflix that worked along-side Jesse on this terrific project and open-sourcing it for everyone’s benefit.
If you are interested in learning more about Jesse and the projects he’s worked on, check out the following resources:
Introducing Stethoscope — Netflix Tech Blog
The New Netflix Stethoscope Native App — Netflix Tech Blog
User Focused Security at Netflix: Stethoscope — ShmooCon 2017 (Youtube)
[Stethoscope Repo](https://github.com/Netflix-Skunkworks/stethoscope— Github
Stethoscope.app Repo — Github
Follow @jkriss — Twitter
