Interview with Bryan Payne

QCon: You lead the platform security team at Netflix. From what I understand, Netflix is environment that encourages developers to use whatever language that works best for a problem, how does that affect how you do security on a day-to-day basis?

Bryan: It's a real challenge. On my team (since we are largely building services and software pieces like libraries that other people would use), it's a little more straightforward (at least on the service side). We can provide a REST API, and it doesn't really matter what language a developer uses to connect to us.

On the library side, it becomes really challenging though. If you think about it, maybe there's two or three of the most commonly used languages, and, perhaps, we can provide libraries around those languages. But then, you know, what do you do about the long tail.

At some level, the answer is that we just have, what we consider a paved road for developers. And that paved road provides a lot of functionality. Security is part of that paved road, but there's other pieces as well. If you use one of the most common languages we have here, you're going to get a lot of these pieces for free.

If you decide that a different language is appropriate for your project, then that developer needs to take the responsibility to satisfy all the components that they would otherwise get for free.

It's a give-and-take. And you have to understand where people's challenges lie and work to make security as transparent as possible for all the engineers.

QCon: As I read through your abstract, one of the very first lines I see says: "What are the modern, realistic threat scenarios that you should be protecting against?" Can you tell me more about that statement?

Bryan:I think there are two different aspects that come together to create a threat. One is to actually step back and do some risk analysis. So that's trying to figure out, what is important to protect in my ecosystem. Depending on what your company is doing, it may look very different.

Some people might care about protecting a credit card database, some might be protecting proprietary intellectual property, and yet some other might be focused on protecting customer data.

So the first step is to do risk analysis to say, well, what does our company have that's valuable in some way. Then how important is it to the company? How likely is it that it could be breached? These kinds of things.

The second part to understanding threat is to really look at the attacker side of it. So say you've identified some asset that is really valuable, then you can say, "Well, is this something that an attacker can get into? How will they get into it? How challenging it is for them?"

If you have something that's high value, and it's easy for an attacker get to. Then you have a high threat. Inversely, if you have something that's low value, and it's hard for an attacker to get to, then you probably have a pretty low threat.

So the idea is you can work across these two axes to identify what threats look like in your ecosystem.

QCon: What does it mean to build security in?

Bryan: I think that phrase has been popularized by security folks – I will include myself in this crowd – who often see companies create a product that's been around for 5 years, 10 years, something like this. And only then do they say, "You know what? I think for whatever reason, we should probably hire a security team."

And what happens is they hire a security team, security people come in, and they look at your system. More often than not, the team will start to look at things, and they'll say, "You should change this, you should change this." There's all these different things you should change.

At the core of it, you can only sort of do window dressing unless you really want to fundamentally change your product. And a lot of security people would say, "Well, if you'd only called me 5 or 10 years ago when you started, then I could have sat by your side the whole way. You could have created a product that was just the same from a consumer standpoint but we could have engineered it in a way that the security was baked in at every layer. And we wouldn't have to be thinking about how to go back and retrofit or reinvent the product’s architecture."