Zane Lackey has had one of the broadest possible careers in Infosec, having been an elite consultant at iSec Partners, the first CISO at Etsy, and co-founder of Signal Sciences (which was acquired by Fastly last year). Material’s CEO, Ryan, recently sat down with Zane to discuss how to build out a security team, why and why not to get into the vendor business, and how to not suck as a security vendor.

First, can you share how you got started in Infosec and which different roles you’ve played?

Going back to the mid-90s, I saved up a bunch of money from odd jobs to buy a second hard drive for the family computer to experiment on. I started installing Linux... it took me months to figure out the modem settings needed to get it online. Eventually, I got it online, and I jumped on IRC to celebrate with all my friends. Within a minute, somebody hacked in and shut it down. It was this absolute cliché, quintessential light bulb moment where I found myself fascinated in how did they do it, how do I stop it, and how do I learn the systems deeply enough to understand what’s going on?

From there I started really learning. My friends and I would all set up different systems and we would play capture the flag, trying to learn the most effective ways to break-in, as well as not just patch, but actually, how to harden systems, how to do real effective detection, and really just learn security from the ground up.

I went off to UC Davis for school, which had a really interesting security program. From there I applied to a job via a random craigslist posting, which is actually how I landed my first job at iSec Partners as their first consultant.

That was such a defining moment in my career, getting to be hands-on with everyone and learn as we scaled all the way up through the acquisition by NCC Group. I moved over to New York to help build out the East Coast practice and was eventually given an opportunity to be the CISO over at Etsy. After a few years as a CISO, there was a big problem I wanted to solve in the industry. So my co-founders and I started our own company, Signal Sciences, which was eventually acquired by Fastly.

What was the biggest learning when you left consulting and became directly responsible for defending?

When you've only done consulting, you've only really done offense work. Having both the defender and offensive sides was invaluable so that I could understand the trade-offs and what was truly important in terms of risk. The biggest learning, though, was that the ability to move fast actually makes you safer as a company. At the time, security was known more so for being a blocker and slowing things down. The thought was that if things were moving fast, you've lost control and couldn’t possibly be secure. But by moving quickly, I learned you can make changes, start to monitor, bring in new solutions, and it allows you to actually iterate much faster and become safer as a result.

How do you protect a large, fast-moving organization when you’re a numerically tiny security team?

A really effective security organization is thinking about how they can bring security capabilities directly to the other parts of the business so that everyone can self-serve and move quickly.

In a typical security playbook you're supposed to execute security training for the entire engineering organization, and typically what that means is at least a full day-long class on secure development. It’s a lot of “this function and not that function” and everyone's brain has shut off 30 seconds in, they're checking their email, and doing a million other things because people tend to not find that interesting.

Well, what we did is shorten this training all down to one hour (totally optional) lunch and learn sessions. We would set up a dev environment and rollback patches to real security vulnerabilities that we’d seen, and teach the attendees not only how to find them but also how to exploit them. That was super engaging for folks. You have a whole room full of developers XSS’ing and CSRF’ing each other.

The number one thing that I recommend out of security training is to teach the rest of the organization that they should be proactive in engaging with the security team. Coming from the consulting world, often you would produce a pentest report, a security team would consume that file and add all the issues into the bug tracker, and then they’d say shipping is blocked until these are all resolved. There's never been a better way to burn a relationship with the development teams than over something that probably wasn't even critical.

We don’t want security to be the blocker. We want to find the right balance of prioritizing critical matters while being able to ship and iterate quickly. Having fun trainings and showing that the security team won’t try to get in the way every time a developer or DevOps engineer asks a question is a great way to help build an effective relationship.

What are your top priorities when building out a team and function?

I think the most common mistake that I see (and I get to call this out because I made this mistake too) is to try to jump straight into technology or the engineering side. Focus on building buy-in and understanding the goals of the rest of the organization first.

From there, the top priority is to go build relationships on day one. That's your most effective 30-60-90 right there: understanding what the business actually wants from security and what you can do to help deliver that. The senior leadership side that you're going to be interacting with has almost certainly had experience with security, and most likely has had a negative experience. So if you come in guns blazing about security projects that you need to get done and trying to stop everything until they’re complete, the reality is that they're going to go back to their negative perceptions of security. To be effective, be direct that security is here to help enable the business. Yes, it’s a cliché that gets thrown around now, but there's a deep truth underneath it: Really effective security is there to help people move faster, not slow them down.

So go have that conversation with folks and share the types of projects you’re considering, and ask if there’re any reasons why these projects haven’t been done previously. This will help you prioritize projects and position them properly for buy-in. It might slow you down a few weeks upfront, but it will save you years on completing your projects and accomplishing your goals.

What do you look for when hiring a security leader?

Avoid choosing either the very deep in the weeds engineer or total management C-level exec with not much technical understanding. The failure cases of each of those are pretty much what you'd expect: the engineer never grows into a leader or the manager never hires technical enough to accomplish key projects. Focus on finding more balance — of course you won’t find a perfect middle ground, but understand your organization and know where to lean into.

I think really effective security leaders also view themselves as building a company inside a company. They think about their customers, which is the rest of the business, and members of their team are going to represent their “business” to those customers. You don’t want a team that has an ego or attitude problem towards the rest of the business. It will be utterly ineffective.

Practitioners in the industry are really tough on security vendors (and deservedly so). Why on Earth did you decide to become one?

Yeah, I don't think there's an industry that hates vendors more than security. I think the things that are really interesting in the security space come from practitioners who had to solve a problem in-house and not vendors who have heard about a new problem and are going to raise a bunch of money and then see if they can figure out the tech and what customers want later.

Practitioners turned founders get to the point of realizing that their solution has the power to impact way more than just the initial audience. If we really want to scale defense and scale solving the problem, you don't do that inside one company as a security team. You go turn this into a product and technology that people can actually use globally. And so that was really our journey. We stepped out from Etsy and we applied those lessons learned and turned them into Signal Sciences.

We scaled that for almost seven years. We were 150 people, and we defended tens of thousands of applications and trillions of requests across a bunch of the most prominent global production apps and APIs. It was super fun to work with customers at scale defending these real problems in a space where historically people hadn't gotten a lot of value.

Do you have a specific philosophy on founding team composition? Which skills are needed? Should you just work with your friends?

The number one thing to solve for is trust. Have conversations around “if we were in this position, what would you want to do?” Start to see how you're going to solve problems in a really tough situation. When you're successful, the problems just get bigger, it doesn't mean they go away.

I would solve for that first rather than “oh, I have this skill set, they have this skill set. It's a nice venn diagram with not too much overlap, let's go start the company.”

What are the good and bad reasons to become a vendor?

First, it’s really tough. Tougher than you can ever imagine. But it's rewarding because you're able to solve a problem on a much bigger scale. You might be defending the top 10 largest companies in the world, or tens of thousands of SMBs, or everything in between. The right reason to do it is that you are really passionate about some problem and you want to solve that on a much bigger scale.

You might think you need all of these prerequisites to go do it. You don’t. Just go do it. Start shipping. Start seeing if you know what customers do and don’t like. Get out there and talk to other founders. I think the thing that shocks first-time founders a ton is how helpful other founders will be, even if you've never met them before. We’re all paying it forward.

For people starting companies, how much should you build a startup that is designed to be a public company worth billions of dollars versus just building a company?

You should build what's right for you and your own goals. You shouldn't go the venture route just because you think that's the only route available.

The nice thing is you don't have to make that choice on day one. You can start to build a company and at any point decide to take outside investment.

I would just encourage a new founder here to think about what they want — are they most excited to ring the bell on IPO day or is it more exciting to be working with customers every day and never feel forced to go do something other than that?

Those are two wildly different paths and funding is just a mechanism to get there. It's just a step along the journey. The real journey is for whatever outcome you actually want and that's what I would encourage you to spend time thinking about and then work your way back from there. And if you have co-founders, have this conversation upfront to ensure you have a founding team that is all aligned.

How do you not suck as a vendor?

Have empathy for your customers. Understand where they're coming from and how you're able to best help. If you can, instead of cold spamming a prospect reach out via other customers and references that can give you a good recommendation. In those first meetings, be able to say “I know this is a cold meeting. We booked it for 30 minutes, let’s take five minutes and we’ll just tell our story and what we do, and if you're not interested, we can just hang up right there.” Ask if they want to see slides or just have a conversation because no one needs to sit through yet another vendor PowerPoint if that's not what they’re interested in.

Let’s flip the last question on its head. If you're a buyer, what is something you should understand about vendors that would help you have empathy?

At the end of the day, solving problems and doing it faster, better, cheaper is the goal. I think a lot of times the adoption of products slows down because you just don't believe anything that vendors say. I think the number of upfront defenses that folks put up (for perfectly valid historical reasons) can actually slow down a lot of things.

The reality is that you could be less skeptical and just jump straight to testing them to see if there's actually value where you should dedicate resources. Demand quick validation. And as I mentioned earlier, moving faster can actually make you safer.

I know you do a lot of investing as well. Are there specific traits you look for in founders / founding teams?

If I had to distill it down to just three, it would be:

1. Do they deeply know the space? Have they been practitioners?
2. Are they passionate about it, like do they really get excited having a conversation about what they're building and where they're going, or do they not seem as committed and could end up going elsewhere?
3. Are they enjoyable to work with? Life's too short to work with unpleasant folks, so I enjoy working with other founders who are passionate about their space and have a real kind of deep conviction and experience.

What are your favorite books you’d recommend for security leaders as well as new founders?

They would actually be the same. I’d recommend the classic building a company / starting a startup books because you need to understand the drivers of everyone that you're interacting with.

I like The Founder's Dilemma, The Hard Thing About Hard Things, and Crossing the Chasm.

Learning the technical bit tends to be the easiest. Learning the rest is typically outside of your comfort zone, and there's a lot to learn. It's going to give you perspective and hopefully, it's going to give you empathy for everyone else that you're interacting with.

If you were to start your Infosec career completely from scratch, would you do anything differently?

I feel fortunate in that I would probably do the same progression from offense to defense to building a company and solutions that work for many companies. I think the security industry would be wildly better off if more people moved between different parts of the industry. Not only because of the empathy, but also understanding all the different parts of the equation, rather than spending your entire career on just one area. I guarantee it will give you a better perspective and make you more valuable.