Presentation: Defense in Depth: In Depth

We'll essentially be looking at the different layers at which security can be compromised. So those layers are ranging from the codebase to architecture to the product. Basically, I'll be looking at where holes happen in between those layers.

The talk is segmented it into the different areas where you might try to apply security. The point of the talk isn't to try to say how to do security, it's more to point out this is where a defense in depth mindset applies at these different layers and anti-patterns that I've seen and patterns that that could be applied.

What I've learned about security is there's no one way to do it, but there's a lot of ways to get it wrong. So it's really just trying to get people in the mindset of taking a holistic approach to security. The whole overall message is you need to be thinking about security at these different points. Even if you get something wrong, by using this thorough approach you’ll be in much better shape from a security standpoint.

The current layers I plan to discuss are code, architecture, product, and team. These are the different ways that I tend to think about security. You could think about security in terms of the architecture, but the point I’m trying to get across is that (when you’re doing security) if you’re just thinking about just the technical architecture, you’re missing things. There’s always like a patchwork of security requirements and things get missed when they're applied from a specific lens. I think the layers lets you look at things holistically.

One pattern that I look at the product level is when you’re collecting data, don’t collect all of the data. Basically, looking at defense in depth as a way of minimizing risk. As an architect, you might be thinking of Defense in Depth as egress and ingress controls. Where your product might be collecting all of the data and that’s a huge risk anyway.

Another anti-pattern is at the team level. It’s where you have a rockstar or someone who is writing all the code and no one else on the team understands what’s being put into the code base. In that antipattern, you don’t have other people on the team really understanding what’s going into the product. Again, that’s a risk.

These two examples are really interesting because if you're a security professional you might be paying attention to one of those problems, but you might not be paying attention to them both. You wouldn’t necessarily think about it being a security problem, yet both introduce a security risk.

Yes, this talk is a defensive talk. So if you’re someone who is building a product, this talk is talking about what are some of the proactive decisions you should be making rather than post-compromise actions to recover from an attack.

In addition to my current work at HashiCorp, I’m also a core Tor developer. So I think it’s interesting to see some of the things that have led to the massive data breaches as lessons we can learn from the privacy movement.

If you think of a lot of the data breaches that have a happened, much of the harm came from data that wasn’t necessary to collect. Companies have things like data lakes that are really scary because you put all your valuable assets in one place. I think an important trend that we can learn from is to think about some things that have made privacy protecting tech successfully. Things like making sure you are not collecting data that is risky or something that (if attacked and collected) would harm the user overall.

I think GDPR is a great step in that direction. I think we’re going to see more enterprises, for example, paying attention to things like end-to-end encryption.