The Art and Science of SOAR
Our guest today is Cody Cornell. He’s CEO of Swimlane, a SOAR platform provider. Cody began his career in the U.S. Coast Guard and has spent 15 years in IT and security, including roles with the U.S. Defense Information Systems Agency, the Department of Homeland Security (DHS), American Express, and IBM Global Business Services.
We’ll learn about his career path from sailor to CEO, he’ll share his insider perspective on SOAR platforms and how organizations are using them, and we’ll learn about how he thinks organizations are best implementing threat intelligence to protect not just themselves, but the community as a whole.
This podcast was produced in partnership with the CyberWire.
For those of you who’d prefer to read, here’s the transcript:
This is Recorded Future, inside threat intelligence for cybersecurity.
Hello everyone, and welcome to episode 121 of the Recorded Future podcast. I'm Dave Bittner from the CyberWire.
Our guest today is Cody Cornell. He's CEO of Swimlane, a SOAR platform provider. Cody began his career in the U.S. Coast Guard and has spent 15 years in IT and security, including roles with the U.S. Defense Information Systems Agency, the Department of Homeland Security, American Express and IBM Global Business Services.
We'll learn about his career path from sailor to CEO; he'll share his insider perspective on SOAR platforms and how organizations are using them; and we'll learn how he thinks organizations are best implementing threat intelligence to protect not just themselves, but the community as a whole. Stay with us.
I grew up in rural Montana, 100 miles away from any meaningful airport, and to get away from that and to get out into the world, I joined the Coast Guard. I spent about five years in the Coast Guard, my first duty station was aboard a polar class ice breaker, so I got the chance to go to Antarctica and the Arctic.
And then after that I went off to electronic school, so I did electronics, radio repair for a couple of years, and then some logistics around that. And that's really where I got started in IT, that's where I started going to community college classes at night, learning about Linux and Unix, starting to build some things on my own in my own spare time. And that's really where my career got started.
So you transitioned out of the Coast Guard, where did you go next?
My first job was actually working for one of the defense contractors in the D.C. Metro area. So I worked for one of the intelligence community organizations, initially just doing help desk work, and then system administration work. But when I was out of the Coast Guard, that was a part time job at the time, I actually joined and worked with the VAE Systems, working on some DISA programs around vulnerability management, host-based intrusion prevention, and things along those lines.
And eventually you moved on to the private sector.
Yeah, so I did some work in the government space, then really transitioned over into financial services and commercial. So I spent a number of years helping organizations deploy enterprise technologies, be they endpoint or otherwise, into their environments, I did that at American Express, helped build a security operation center for a component of DHS when I was working at IBM.
And then I ended up building a consulting company after that, in 2010 started my own consulting practice, again, helping organizations build security operations or the tooling that's needed for security ops. That was really where we started deciding that we wanted to build a product to support some of the problems that were associated with alert fatigue, disparate technologies not talking to each other, and things like that.
Now, as you're making your way through your career, and I'm thinking particularly in your early days as you're getting your feet under you, what were the guiding forces that made you decide, "This is an area I want to focus on, these are where my interests are."
Yeah, if I go back to high school, actually talking to my high school guidance counselor, the job that I wanted was to be a burglar. I always thought it was intriguing to be able to circumvent the things that were in place. Physical security hacking wasn't really a thing, we just called it trespassing. I didn't do it as a kid or anything like that, but it was always intriguing for me. And as I got into electronics, which kind of led to IT, I started seeing what security was inside of technology, and it had some of the same attributes of that cat and mouse type of idea, how do you see what's going on, how do you circumvent what's going on?
I really at one point thought I wanted to be a pen tester, I think a lot of security people want to go down that path. It turns out I wasn't the world's best pen tester, I thought that the problem of building systems on the blue team side of the house to actually keep people out all the time, having to be right more often than not, was really a much harder problem to solve, and one I was just a little bit more attracted to.
Now, in terms of your own management style, as you're putting together teams in a leadership position, how do you approach that?
I think, growing an organization, you're looking for people that do different things at different phases. Really early on, you have people that are comfortable doing things they've never done before, they have to be utility players, no task can be below them, and I think that's always the case. But those types of people are a little bit different. Then, as you scale an organization, you're looking for people with deep specialties, deep domain expertise in a particular function, if it's R&D, or if it's product, or sales, whatever it might be. That changes over time.
So you're always looking for some of the characteristics that we look for here at Swimlane specifically, folks that are going to punch above their weight class, that are always trying to get better at what they do, and always trying to make the organization better. But on the flip side, the skillsets you're looking for does change over time. The specialization continues to increase over time as the organization grows.
Yeah, that's a really interesting insight, and I wonder, for you personally, when I look at your work experience, from the Coast Guard through organizations like the Department of Defense and American Express and IBM, these are all large organizations. When you decided to go out on your own, was there a bit of a culture shock there, that you weren't within these big structures of companies?
Yeah, I mean, there's definitely a different culture between a startup and working for a contractor that's supporting the Defense Department, those are two fundamentally different organizations. I always felt that I thrived a little bit and enjoyed chaos, even inside of those organizations that have a ton of structure.
I think at times it didn't make me the best employee in the world, in all honesty. I think I was pretty hard on my managers, and sometimes on my peers, and I'm getting a little karma for that from time to time as Swimlane scales, understanding some of the things that I did that I see other people do and ask of me that I probably should have done. Hopefully at some point I can go back and apologize to those folks for doing those things.
But the teams inside of those organizations a lot of times function as startups. I mean, they're trying to solve a problem, the business has an issue they're trying to fix, they're trying to deploy a piece of technology, they're doing that in a tight-knit group. So there are some attributes of working in those organizations that is startup-like.
That being said, there are things that are obviously different. You can't punt on anything when there are 10 people in the company. If something needs to get done, there's nobody else to do it, you just have to do it yourself. And I think a lot of times that's new and novel for folks, and that's something that, based on a character flaw of not being able to delegate well, I was able to embrace.
But not everybody loves that. They're used to having somebody that they can sometimes send that over to. If it's graphic design, or if it's customer support, or whatever it is, folks are typically used to being able to give that to somebody else. And not having that option is sometimes eye-opening for folks. Some people just totally embrace it and they love it; some people realize that that's not what they want to do.
Yeah. Now, with the creation of Swimlane, which is where you're CEO now, can you walk us through what was the spark of an idea you had there, and how did you go about forming the company?
Yeah, so as I mentioned, we started a consulting company, one of the things that we were doing was competing for work that was against other big organizations, if it was the big four, or a big systems integrator in the fed space. We were trying to win SOC transformation, building out a SOC, whatever it might be. And in doing that, we were spending a lot of time talking to folks about what they were struggling with, we would look back historically at what we had struggled with.
And in that moment we thought if we had a product that would differentiate us and allow us to go capture those customers where our competitors were just selling based on their past experience – and they had some great experience, so we were trying to combat that – but in building that product initially, we put it in front of some different folks and got some feedback, and realized that there was a lot of appetite for what we wanted to do around an automation and a platform and a data centralization capability. We realized quickly the economics of a consulting company and the economics of a product company are very different, and that was really, really intriguing for us.
Now, you all have a SOAR platform. Can you describe, for folks who may not be familiar, what does that mean?
SOAR stands for Security, Orchestration, Automation, and Response. It's a fairly new segment, I think people are still trying to figure out what it means to them at times, but at the end of the day, what we're really trying to accomplish is, there is a lot of work that security teams have to do that is high-speed, it's very, very repetitive at times, but it absolutely has to be done, and it has to be done in real time to meet expectations, to keep dwell time down, to capture best practices. And what Swimlane is really built to do is enable organizations to do security operations at scale when they have limited human capacity to do all the things that they want to do.
Now, when you're out and about and you're talking to folks, and learning about the things that they do, and sharing the information about what you do, do you find that there are some common misunderstandings that folks have when they're trying to get their hands around standing up these sorts of functionalities?
What people do from time to time is, they look at the problem that really drives them to look at SOAR in the first place, right? So your really common use cases are around phishing or SIEM alarm triage, and they look at those and go, "If I could just not have to triage phishing emails every day that are submitted from our users, or if I could just get all these endpoint alarms triaged on a daily basis, I'd be in a much better spot." And a lot of times that's great, that's absolutely the case, if I can take that off the plate of a team and reduce a team of ten's workload by 15, 20, 30 percent, that one use case will justify the investment that you make in a technology like SOAR.
I think one of the things that they fail to look at or think about is automation is applicable to almost every use case inside of SOAR, from dev ops to cloud infrastructure to vulnerability management and patching. There are all of these things that you're going to want to be able to automate away, and not really bringing that full breadth of use cases into your product selection and product evaluation process is something that I think people fail to do from time to time. And that causes them to run into situations where they've got something in place to solve for one use case, but they haven't set themselves up for success over the next several years to automate hundreds of use cases.
Now, in terms of automation, that's an area that fascinates me because I often wonder, when organizations are dialing in automation, which I think in most people's minds we consider to be a technical thing, but how much of that is an art versus a science, where's the intersection there?
It's interesting because I think a lot of times, when people think about automation, they're thinking of that clinical science component of it as, "I need to take data from system A, put it in system B, and if you can do that for me, that's great. If you can extract data from a source in real time for me, that's great."
But the other side of it that I think is really interesting about SOAR is, this is one of the big first innovations that we've done around security and people. If you think about all the other technology, the 100 billion dollars we invest every year in threat detection and mitigation, that is watching the endpoint, watching the wire, watching the perimeter, watching mobile devices. It's not, "How do we actually take the people that are doing those jobs and make them more efficient?"
When you're talking about people, it's never binary, it's never black and white. Organizations have people, they have their own adversaries, they have their own politics, their own regulatory compliance requirements. These things are less science, I think we'd like to see our regulatory compliance be a little more science-y and a little less vague, but on the flip side, there's an art component to that.
And people I think underestimate the impact of historical events and politics on how it drives operations and being able to support that and being able to support that in an automated way. That sounds like a big leap, but I think that's what people need to think about when they're bringing these technologies in.
Now, when someone is setting up an environment like this, they've engaged with you or another provider of a SOAR platform, how do they ensure that when they're getting things set up that they're future-proofing them against their own future growth? That the stuff they're building today, they're not going to have to reinvent the wheel when the company's twice as big, or 10 times as big, or even more.
I think that's a great question that folks should be asking themselves, because yes, the company is going to grow, and that might take quarters or years, but the technology that you use, the infrastructure that you leverage to grow the business, the adversaries that are going to be focused on you, they're not going to change on a quarterly basis, they're going to change on a daily and weekly basis.
So that ability to be able to iterate through the changes that are going to happen inside of your environment and be able to respond to that is something that's super important. And I think for us, that was one of the hard lessons we learned really, really early on in building Swimlane. We took the product to a couple different organizations that were within the same government agency, that should have had the same technology and the same escalation and the same regulatory compliance. And they both asked for something different, and it wasn't the same different, they asked for something totally different.
And that was interesting for us because that drove one of those underlying engineering tenets of building Swimlane, which is we don't want to dictate to our customers how they do operations. Because it's unique to their business. And in order to be future-proof, you have to have a system in place that allows you to change to the needs of the business, the changes of the people, the changes to your threat landscape in real time, as opposed to being dependent on a vendor saying, "Well, this is how you visualize this data, and this is the integration that you have, and these are the limitations on how you iterate."
Even though your life is changing in real time, the product that you're using might not be able to, and I think that's something that we focused on early on, and is commonly told to us by our customers and our prospects is something that they're really excited about.
Well, help me understand, when someone has gone all in, and they've gone through the transition, and they're up and running and reaping the benefits of being on a SOAR platform, what kinds of benefits are they enjoying? What kinds of things are they coming back to you and saying, "These are the things that maybe we didn't even expect, but these are where we're saving time, we're running more efficiently." What kind of stuff do you hear back from them?
Yeah, I've got two that really stand out just because they're recent, and one was near and dear to me. I'm talking to a managed service provider right now that has implemented Swimlane, and they're looking at how many customers can they support with the number of people that they have. So if you think about managed services, one of their biggest expenses is around the number of people it takes to manage a certain number of logos on their side, a certain number of customers. And if they can draw the number of people they need down to manage a broader number of customers, it's really good for their business, that's the business they're in.
And when we have customers like a managed service provider that tell us the reduction in the level of effort to triage, our bulk customer alarms goes down by 60 percent? That's hugely impactful. That impacts their bottom line, it impacts their margins, it impacts how they can retain and attract talent, because those people are not doing repetitive and mundane tasks. That moves the needle in a very significant way for an organization like an MSSP.
Another example of that is more of a direct customer where they have to have a tier one team that has to keep eyes on glass, and they have a lot of turnover in that. As soon as those people get trained up, they move on, they go on to more fulfilling jobs. But that function always has to be fulfilled.
What they were able to do with automation is implement that into their environment, that all the roles, which in this case was north of 10 full-time people, were able to move into more fulfilling functions, if it was forensics, or counter-threat intel, or incident response, whatever it was that was a little bit more than just eyes on glass and triaging basic alerts. That was a huge win for that organization that was able to take those people and put them into much more fulfilling roles.
I want to touch on threat intelligence a bit with you and get your perspective on that, and the part that you think threat intelligence plays in an organization's defenses.
For us, the thing that I really have always been impressed with threat intel since day one is that ... Security people historically don't like to collaborate, they're siloed, especially across organizations, right? There's this, "We're going to keep what we do secret." And threat intelligence I think is the first real big, meaningful step in organizations looking at how collaboration is going to change the way that they do operations on a daily basis.
And to see this come into fruition, to see how people are sharing, how that benefits multiple organizations, and how we get that rising tides raise all ships, it's a fundamental change not just in technology, but just how security teams operate. To me, that's the thing about threat intel that's most exciting, is just the sheer paradigm shift that it put into our environment, on top of obviously the value in using threat intelligence from a day-to-day security ops perspective.
The thing that I think is really applicable to threat intelligence that's interesting is, if you look at some of the standards that are associated with threat intel sharing, be it STIX or whatever it might be, there's this concept of indicators of compromise, and then we really want to move into more detailed information. So if it's techniques or whatever it might be.
But there's a section within those standards typically that's around course of action, which is, if I see this behavior, however I identify it, if it's behavior or if it's an IOC, whatever it is, there's some corrective action that generally we want to associate with that. And I think that has been one of the underutilized components of threat intelligence sharing, is how do we actually couple, "I saw something bad, this is what it looks like" with “If you see it, this is what you should do.”
And I think that component, obviously from a SOAR vendor perspective, is really, really attractive, and I think it's where we work with the Recorded Futures of the world to work to help organizations not only identify bad behavior environment, which is obviously the first step in identifying that we need to take action, but how do we couple that with what do you do in this moment to make sure that, just because I found it, I actually know how to mitigate it and I can do that at scale.
So I think that component, I'll be honest, riding on the shoulders of the folks that built this collaborative thought process, be it ISACS or just general intelligence sharing overall, is being able to couple that course of action, what I should do when I see this as being that next natural progression.
You know, looking forward, looking ahead, based on the experience that you've had, as you look towards the future, what sorts of things are you seeing in terms of the things that security professionals are going to have to prepare for, the challenges, both technical and human challenges, what sorts of things are on your radar?
I think there's obviously a shift that's happening as it relates to the skillsets that are needed to be a security practitioner. Historically, the pipeline of people that got into security were system administrators and network engineers, things along those lines because they understood how the infrastructure works, they understood how to configure and control them, and they had a progression into those security roles.
And I think, with infrastructure changing, with the adoption of cloud and virtualization and containerization and things like that, the skillsets that are being used to manage infrastructure now and into the future become much more dev ops centric, they become infrastructure as code. And that skillset is a little bit different.
So as I'm talking to folks that are transitioning into security, or thinking about getting into security in one capacity or another, those skillsets around dev ops, around software development, around understanding how that works, is very different than the advice I would give 10 years ago on how to transition to security, when focuses were on things like system vulnerability management, endpoint patching, and things like that. There's a pretty big shift in the skillsets that I think people are looking for to, again, try to future-proof themselves from a personnel perspective on where the business is going.
And folks like yourself, who've been in the business for a while, have to stay at it and keep up to date.
Yeah, always improving is something that I think security people are actually really good at. Typically they're curious by nature, they're tinkerers, they like to see how things work and if they can break them, and if I can break them, how can I prevent that from being broken? I think that self-fulfilling prophecy at times is really what makes a good security practitioner, is that idea that I need to understand how the things I'm using today, every day work, right?
So if I decide that I'm going to stop using Exchange, and I decide to use the G Suite, all of a sudden the things I used to poke around on Exchange for to see if I could relay mail or whatever it might be – I'm dating myself a little bit there – but whatever it might be, you start reapplying those things to do infrastructure. And I think that's the thing that keeps people current, is just that underlying curiosity applied to the thing that is new and that I'm leveraging now.
Our thanks to Cody Cornell from Swimlane for joining us.
Don't forget to sign up for the Recorded Future Cyber Daily email, where every day you'll receive the top results for trending technical indicators that are crossing the web, cyber news, targeted industries, threat actors, exploited vulnerabilities, malware, suspicious IP addresses, and much more. You can find that at recordedfuture.com/intel.
We hope you've enjoyed the show and that you'll subscribe and help spread the word among your colleagues and online. The Recorded Future podcast team includes Coordinating Producer Zane Pokorny, Executive Producer Greg Barrette. The show is produced by the CyberWire, with Editor John Petrik, Executive Producer Peter Kilpe, and I'm Dave Bittner.
Thanks for listening.