QCon10Years
Conference:March 7-9, 2016
Workshops:March 10-11, 2016
Sign up to be informed when registration opens for QCon London 2017 (3/6 - 3/10)

Presentation: Building a Modern Security Engineering Team

Track: 
Security, Incident Response & Fraud Detection

Location:

  • Windsor, 5th flr.

Duration

Duration: 
2:55pm - 3:45pm

Day of week:

  • Tuesday

More talks on:

Key Takeaways

  • Learn practical advice for building and scaling modern application and infrastructure security programs
  • Hear lessons learned for organizations seeking to launch a bug bounty program
  • Understand better how to run realistic attack simulations and learn the signals of compromise in your environment

Abstract

Continuous deployment and the DevOps philosophy have forever changed the ways in which businesses operate. This talk with discuss how security adapts effectively to these changes, specifically covering:

  • Practical advice for building and scaling modern application and infrastructure security programs
  • Lessons learned for organizations seeking to launch a bug bounty program
  • How to run realistic attack simulations and learn the signals of compromise in your environment

Interview

Question: 
QCon: Who is the audience that you are primarily targeting with this talk?
Answer: 
Zane: I think it lines up fairly well with the QCon audience that I’ve seen in the past which is leads, a group lead, a CTO, or an architect. It’s the folks that are seeing these shifts that are happening and asking “How do we apply that to either my entire organization or to my particular group?”
Question: 
QCon: What is your role today?
Answer: 
Zane: I am a co-founder and Chief Security Officer of Signal Sciences. Signal Sciences is a company that myself and two others founded after leaving Etsy. We used many of the lessons learned at Etsy in building a new product at Signal Sciences.
Question: 
QCon: What is the motivation for your talk?
Answer: 
Zane: When I arrived at Etsy, I found out that they were doing 20 production deployments a day. As you can imagine, my first step was to reach for the security whiskey. But the second step was to figure out how to adapt security to this setting. At that time, it was only us and Netflix doing continuous delivery. We are calling it DevOps and CI/CD now. At the time there was no playbook, and we had to figure out what to do about security.
One of the greatest lessons we learned at Etsy (and we are now seeing it applied throughout the security industry) was that security should not be a blocker. Security should not stay in the way, but it should become part of a process that people want to engage with. My motivation for the talk is to share some of the lessons learned at Etsy.
For everything that we did well, there were 20 things that we spectacularly failed at. I hope these lessons are helpful to other organizations that are finding themselves in a similar place. This is the talk I would have wanted to see on day one of starting my new job there.
Question: 
QCon: Can you give me some examples on how security can be an enabler rather than a blocker?
Answer: 
Zane: There are multiple plans of action: how security reaches out, why security would reach out, or how it does it. On the cultural side, how do you build the security team to have empathy with the rest of the organization? When someone comes to security they should not say “That’s the dumbest idea I have ever heard.” Instead security should say, “I see what you are trying to do. Here’s the concerns on the security side, and here’s how we can mitigate them.”
If security can drive that sort of conversation, then people actually will want to interact with you. There seems to be this kind of existential crisis for security right now because if the other teams don’t have to talk to us, what is going to happen? Is it going to be pandemonium? Actually no. It means that we need to rethink the way we build security teams in order to get people to want to talk to us. Then we can have productive conversations. Security teams had a tendency to run some tool that would give them 10,000 potential issues, and they would ship that to a development group and say “It’s your problem now.”
A development group would do the only rational thing that one could do in that situation which is to delete all emails from the security team that contained attachments. Because it turns out of those 10,000 results, 9,900 of them were false positives. So you don’t have time. You are trying to ship features. You are trying to build a product.
The security team should focus on what is critical. Security should say “Here are 10 specific issues. Here are the three that are super critical, that we need to solve them. Here are the other ones that we would like to work with you on over the next month.” And not “Here is a big report. It’s your problem now.” I think that sort of mentality has to go away.
Question: 
QCon: You discuss a few things you’ll go into you your abstract. Can you discuss a bit about how a bug bounty program should work, and then how to run realistic attack simulations?
Answer: 
Zane: We make so many of our security decisions without proper data. Many of the breaches carry the same exact breach style, just repeated everywhere else. I think the big lesson to be learned is getting data on how these breaches are happening and applying it to our own organization. The idea is to make it difficult to be take place at all.
How would we detect that breach? How would we lower the value of what the attackers actually get? We are starting to see this in some of the products that are coming out now? One of the ways to help get these answers is a bug bounty.
The real value of a bug bounty is not to have a cheaper penetration test. The real value is to treat every vulnerability found by participants as a mini.incident. Then you can say “Someone found this really severe vulnerability,” rather than saying “Thank you and here is reward for it.” Treat that finding as an incident in your environment and ask “Would we have detected this? How would we have made this harder? If they had done this, what would be the value of whatever they got access to?”
Then how can we run these simulations of attackers. That can be via a bug bounty or a responsible disclosure program or an attack simulation. How can you use this data to run incidents, get better at it, and then ultimately use that data to influence where and how you spend your time. I think that’s one of the big problems facing us in security today. We are so under resourced that we need to ask the question “Where should we spend our time?” Right now, we don’t have great ways to answer that question other than gut feel if we are being honest with ourselves.
Question: 
QCon: What do you the main takeaway from your talk?
Answer: 
Zane: The number one takeaway I want from this talk is that security can help enable the shift towards CI/CD and DevOps. The idea of security as a blocker has to go away.

Similar Talks

Multi-Host, Multi-Network Persistent Containers
Far from the mobbing crowd
Hot code is faster code - addressing JVM warm-up
Successful Go program design, 6 years on
Rust: Systems Programming for Everyone
Using Pony for Fintech
Effortless Eventual Consistency with Weave Mesh
GoshawkDB: Making time with Vector Clocks
Distributed Consensus: Making Impossible Possible

Tracks

Covering innovative topics

Monday, 7 March

Tuesday, 8 March

Wednesday, 9 March

FULL SCHEDULE

Conference for Professional Software Developers

Follow QCon

Contact

Menu

QCons around the World

Qcon