Interview with Andrew Plato, CEO, President, and Founder of Anitian

Transcript

Ledge: Andrew, thanks for joining us. Really cool to have you on.

Andrew: Ledge, thanks for having me here today. I appreciate it.

Ledge: Could you just give a two or three minute background story of yourself and your work for the audience?

Andrew: Sure. I’m Andrew Plato. I’m the CEO of Anitian. I’ve been doing information security for 23 years.

The founding of my company is, I think, an interesting story. Back in 1995, I worked at Microsoft. I was a technical writer, which is one of the least exciting jobs you could possibly have in the world, and part of my job was documenting code. One day, I copy-pasted a SQL query – database people know what that’s like – into a web browser, hit enter, and it returned all of the data on the e-commerce platform that I was documenting.

Well, again, if you’ve worked in databases you know that was a SQL injection attack. Now, I didn’t know that at the time, I thought I’d just found a bug in the software. Well, fast-forward a couple of weeks later, I went and showed this to all the developers thinking, wow, I was really onto something here. I was able to use that same attack to get into credit cards and what was secure information on the website. When I showed it to the developers, fully expecting them to say, “Wow, you’re such a smart guy Andrew,” the exact opposite happened. They said, “Shut up Andrew. Sit down. You don’t know what you’re talking about.”

It was their reaction and their dismissal of security that is what got me into security. I’m like, “Wait a minute. Why don’t they see what I can see? I’m just a tech writer.”

That’s what inspired me. I went off and started a security company, and I’ve been doing it for 23 years. Had a chance to do really a little bit of everything – from risk assessments and pen tests and compliance work. You name it, I’ve had the opportunity to do a little bit of it.

Ledge: Security wasn’t a huge thing 23 years ago, so you were definitely ahead of the curve. Now I’m thinking, every other day we have a breach of 100 million records. It’s almost becoming the other direction of numbness. Before, we didn’t care because we didn’t know. Now, we can’t care because there’s so much going on.

You’ve spoken a lot about – I looked at some of your presentations – how to even begin to re-paradigm this problem in our heads because clearly the solutions that we pretend to have in place are not working.

Andrew: I think what you’re experiencing is something that us human beings have difficulty accepting, which is that security and many of the technologies around us have really exceeded our human capacity to handle them. Our brains, and just who we are as people, we’re not capable of working at the speed of all this technology. We, frankly, work on a much slower rate. When you get to security as an issue, this is amplified many levels.

We as people are just not capable of handling the onslaught of attacks and problems and issues. Anybody who has run a security information and event management appliance knows it’s unbelievably overwhelming, the amount of data these things produce. We’re simply not capable of dealing with it.

The problem is that a lot of organizations, they haven’t really figured this out and they’re still treating security people as if they’re machines. They’re going to security people, and developers and IT engineers and other people, and expecting them to know everything, to be completely in full capacity of every conceivable thing going on in that environment. That is just not reasonable. The smartest person in the world couldn’t understand the complexity of some of these platforms.

We look at something like an Equifax attack and say, “Oh, Equifax. They’re bad and they’re wrong. The people weren’t qualified.” That might be true but what’s also true is that the people who are running these systems, it’s just not reasonable for us, for the company, to expect them to know every possible weakness in the organization and be able to respond to it at the speed of which today’s attacks are happening.

What that really means is that we have to now let the technology do a lot of this work for us.

Ledge: We’ve got hardware technology. We’ve got software technology. We’ve got network technology. Everything is moving to the cloud. We’ve got a rapidly moving macro environment in which you’re trying to make that major paradigm shift of humans, none of whom – ourselves included – really do so well with change or re-education or whatever that is.

Break it down. We need some kind of different way of thinking that humans can actually do.

Andrew: I think where it starts is an understanding that we have to know what we are good at as humans. We are good at that slower analysis process. That we’re really good at asking why. Why is that happening? Or, what’s going on here? What’s the bigger picture. That’s something human beings can do and we can do quite well.

We’re good at doing that in a collaborative environment. If you put a bunch of people into a room and ask, “Why is this happening?” you’ll probably get a lot of different opinions. Out of that will emerge a story or a picture of what’s going on. Often, that will be reasonably accurate. It will help guide you and give you a trend or some vision or some goals around it. That’s what we can do well and that’s a critical part of security. If you don’t have that analytics happening behind the scenes, then it is just this deluge of data. There’s no meaning out of it.

What that means is that we as humans have to step back and get into more of a role of watching what’s coming out of these systems and then piecing that together into a story. If multiple bad things are happening, there’s some bigger story going on here. What is that bigger story?

One single attack does not mean the entire organization is at risk, but multiple attacks and multiple things going on or a sequence of events, that can tell a bigger story. That’s what we as humans have to do.

What that also means is we need to let go and let the technology do that rote kind of work, that looking through the data and sifting through and looking for the needle in a stack of needles, quite frankly. We have to trust the technology. That’s difficult to do, particularly if a lot of us have grown up in a world where we built these machines by hand or we did a lot of this stuff manually. We always want to be in control of it, like, “It’s mine.” We have to let that go. We have to push it away and let the code do the work.

Ledge: Letting the code do the work is, of course, also dependent upon human-written code. We have this endless agile, lean sort of approach to, we just have to keep solving problems and keep getting better and better and better. How do you get the organizational mindset headed that way?

Andrew: Well, the first good thing that’s important to understand about code is that it learns from its lessons quickly. If something’s broken in code, you fix it, that’s it. It’s fixed. That problem will not, presumably, crop up again. You’re not going to have to relearn that lesson sometime down the road.

Now, of course, I know first person is going to say, “Well, what about recursive errors also?” Okay, yeah, sure. It doesn’t mean that it doesn’t spawn new errors, but the point is that once you… Code is kind of a ‘it works or it doesn’t’ sort of thing. It’s a little more of an on-off relationship versus humans, which it’s like any given one day, if you’re having a bad day, you could completely miss things.

It is a difficult paradigm shift. What I can say is that my generation – and I’m a Gen X, I was born 1969 – my generation is probably the one that’s struggling with this quite a bit because we’re kind of trapped between generations. We still want to do everything ourselves. We’ve got that Gen X mentality to it.

But the generations that are after us, Millennials – I know people like to complain about Millennials a lot, which I think is unfair quite frankly – there’s a much greater comfort level in this automation in technology. This is where something where my generation, and frankly the generation before ours, we can learn a lot from the Millennial generation, that it’s okay to automate.

For many Millennials, automation and this kind of stuff is just normal. It’s natural. Why wouldn’t you automate these things? I think right there, there’s a lesson to be learned. The generations that are coming up, they are much, much more comfortable with letting the code do this work and we, as the Gen Xers, need to let that happen.

I think the other thing that happens is once these systems get up and running – once you codify security, once you turn security into code, when it becomes an integral part of the DevOps process and it starts just integrating into the whole – you quickly realize how much easier security becomes. How it becomes much more enjoyable, quite frankly, because you’re not having to monitor a [Sim 00:10:35] all day.

You’re not watching firewalls and AV logs and all this nonsense. You can really, truly step back and start to do the bigger risk analysis work which, as a security practitioner, is much more rewarding because now you can start having conversations with the business about, here’s a threat we face.

Here’s a bigger threat we face. We face threats from foreign organizations that want to get in and still our data. Let’s craft a plan to deal with that. That’s a much more rewarding problem to deal with as a security professional than, “Hey, by the way, did you know the Symantec engine is throwing off errors all day.” That’s just not as entertaining. Let’s let the code deal with that. Let’s integrate that solution into the code.

Ledge: You remind me of, in my coding days we had log fatigue. Where it’s just like, if this stuff isn’t built right you just get this endless flow of garbage and warnings and whatever. You had to do that in a clean way. Or you could offload that to log management and to software that is largely now starting to evolve into your big data, machine learning and even AI in this space.

What do the next few years look like there? You’re describing a streaming data problem that ought to be processed by machines. That’s a use case that some of that ML and AI really is designed for.

Andrew: Well, the good thing about the emerging technologies in this space is that we can just stream all the data into these big data repositories and just leave it there. There’s a lot of value to just streaming it in there, to letting that data sit there. You never know when you want to go back to it and do some analytics on it.

You look at that movie Moneyball, where they analyze all these little details and all the data behind these players. Well, the same principles can apply now in security and DevOps . You want to go back and analyze the data to find some trends there. Sometimes that log data is valuable.

Having the data is valuable. The analytics of it though, you’re right, the technologies need to evolve, and this is a good example where AI will be beneficial in the future. To have it go through these technologies, look for these trends, spot them, be able to seed these AI engines with key metrics in data and then just let them learn the data.

Unfortunately, we’re not quite there yet. Those technologies are still very emergent. What you are seeing though in security is a move toward automated threat hunting. It’s something we do on our platform and services at Anitian, is trying to automate that process as much as possible. Once you automate it, you then have a security analyst on the job 24/7. They’re working at the microsecond level, not at the month level.

The more you can automate that… That is actually… I don’t want to… I hate to use the word easy. Automating that hunting for threats is imminently doable. It really is just a matter of creating these intricate searches and pattern capabilities where you know that, if this happens and that happens and this happens, that’s an interesting event. That’s that sequence of events. That correlative sort of…

That doesn’t require advanced machine learning to do. You can do that right now and today. The challenge is that to build those engines is really difficult. But the good side of that is that there are companies, like my own, out there that we’re building them. We’ve already built it. We’re not the only ones. I don’t want to make it sound like we’re completely unique here. There are those capabilities now.

The more we can speed and automate that, it reduces that log fatigue on the security side, but also on the DevOps side. Now we have a clear like, “Okay, that’s the problem,” rather than just like, “I don’t know. There’s tons and tons of logs we got to now pile through to try to figure it out.”

Ledge: You’re talking to a whole lot of software engineers now, so I’d love to hear about your process of developing a comprehensive security suite and all the things that you’ve done there.

How did you conceive of and engineer the software product that you rely on?

Andrew: That’s a great question. Thanks for asking that. We had an interesting pathway to that. It started really with having been a security integrator for many, many years and then a security audit firm – we did compliance audit, PCI audits, risk assessments – we watched company after company after company struggle with security issues.

I mean, I can think back to companies that were taking two, three, four years to meet these compliance requirements, and how it was just a miserable process for them. They hated every minute of it. It was like pulling teeth for the developers. Frankly, I didn’t blame them. If I was in their role, I’d be like, “This is miserable but you got to do it. I’m sorry.”

After doing that for a long time and really dealing with the ire of customers who are like, “There’s got to be a better way to do this,” that was really our. We’re like, “You know what, there is. There’s got to be a better way to do this.”

That happened to us a few years ago, where we just finally got fed up with all of this manual tweaking of technologies to make them secure, compliant and we said, “Wait a minute. We know automation is a thing.”

Now, there’s technologies emerging like Phantom and Swimlane – these kind of security automation platforms which are pretty cool. They can do some really neat stuff. But we were thinking, how could you get this even one more layer deep? That’s actually just an automation platform. It sits on top of a bunch of existing on-premise hardware. We wanted to make it where it’s like we want this just embedded right into the entire infrastructure.

When you look at the cloud, everything is code in the cloud. In AWS and Azure and all these cloud platforms, it’s all code. There is no physical hardware, really. That’s when we got tangled up in this, okay, let’s codify the security of these cloud architectures.

It was right about the time we started doing that and building that platform that AWS actually approached us and said, “Hey, we like what you’re doing. You want to do that some more?”

What really it required though was an interesting fusion of skillsets. We were a security company. We had this really rich background of information security expertise, but we weren’t much of a development shop. The whole DevOps thing was a concept for us but we hadn’t really done it.

So we, as a company, had to start adopting DevOps techniques inside the company and that was not easy. I can tell you, a classic security consultancy trying to adopt this agile, DevOps mentality? Needless to say, there were a few Casualties of that process. Like you said, we don’t like change. Some people really did not like that change, but I knew that it had to happen. We had to do it.

We really started using DevOps as just a methodology across not only internal development but even just our regular security consulting practices. Getting into this really, everything’s got to be done in this iterative, fast, with a sprint sort of mentality like, this is what we’re going to focus on now, . Even just moving over to the tools of DevOps, using JIRA to manage our projects rather than. It’s all those little things, adopting that methodology. That’s what we had to go through.

Now, I know a lot of DevOps shops that have to go through the reverse of that. It’s like, how do you then build security into that? The real key to that is making sure that security is part of every process. That it’s designed right into the code. That the security controls are built into your platform. More importantly, that when you’re doing your development, you’re developing on secure reference architectures. You’re not developing in these environments that are wide open to everything, with no security controls whatsoever because, invariably, you end up developing applications that need everything to be wide open and unsecured in order to operate, which doesn’t fly.

If you start that process very early on in the DevOps cycle, developing on hardened platforms, developing with the security controls already in place, mandating the security controls are automatically built into the CI/CD pipeline, it forces your development into a secure pathway. It also means, quite frankly, that in some ways development gets a little easier because there are certain things that you can’t do. It’s like, “Okay, we can’t do that. It’s not an option. Let’s not even explore it.”

Our pathway was that. Once we adopted some of those DevOps approaches and got that into our whole company cycle, that’s how we built the platform. That’s how we started developing our technology. Which really gives developers exactly that. It’s a stack attack that we can deploy in about four hours. It’s an entire security reference architecture that it’s got everything baked into it. With a push of a button, boom, there you go. You’ve got a reference architecture. In our case, we hinge it on compliance requirements or PCI or , so that it’s just now you’re developing in this constrained space rather than just doing whatever you want.

Ledge: I love that story of the mandate to become a software development company. You’re calling it this is the DevOps culture, which is derivation of agile, right?

Andrew: Yeah.

Ledge: To become an agile company as a services provider. Services providers tend not to be agile because they don’t really need to be. You can get away with being a service provider in a non-agile fashion, but you can’t get away with using a service provider mindset to develop complex software without that iteration.

That’s a neat story because not a lot of companies, A, make that turn, and not a lot understand that you can learn from the software process in the rest of the business. That’s really interesting to hear that.

Andrew: Yeah. I do want to emphasize that it definitely had casualties, but we had to be willing to do that. I think that’s one of the bigger mistakes I see a lot of companies, a lot of people, make is, they’re so afraid of any form of failure that they paralyze themselves and refuse to change. Ultimately, they undermine themselves and undermine their own business because that fear of failure just consumes them and overtakes them.

In DevOps world, it’s like, heck no, we want to fail fast. Let’s fail as fast as we can so we learn it and we just iterate and go on it.

That’s another area where you run into that service mentality because the service mentality is always, we can never screw up in front of a customer. We can never make a mistake. I’ll be honest with you, some of our customers, we would say to them, “Hey, yeah, we made a mistake. That’s normal. That’s part of the process. We’re learning here. We’re figuring out how to do this and do it right.” Sometimes people just don’t get that mentality.

What I will tell you is – again, getting back to the generational thing – the generation that’s after, the Millennial generation, definitely much more comfortable with that approach. It’s not foreign to them. It doesn’t feel strange. Whereas my generation struggles a bit more with that.

It definitely requires… It’s difficult. The way to do it successfully is make sure – and in our case is communicating with all those people around it, is, “Look, this is a mandate. We’re going to do this. Come hell or high water we’re going to make this change. If you get onboard, the benefits are we’re going to be able to do more, do better, make more money. You’re going to get more opportunities. There’s just benefits across the board. If you don’t want to get onboard, that’s okay. There’s plenty of other places that aren’t like that, where you can have a comfortable service-oriented job.”

It’s tough to make those decisions. In our case, the company – and a lot of this I think has to do with my own personality – I like change. I like to do the newest stuff. I think that’s fun. That’s what drove a big chunk of it.

Ledge: What’s the old, “You’re going to be very successful somewhere else,” right? The difficult conversations of building and scaling and changing a company. What got you here won’t get you there.

Andrew, super cool to have you here. Really appreciate the insights. Any closing comments for the audience of 20,000 engineers out there?

Andrew: I was going to say I do have one thing, which is for all those people who are working in these monolithic, more traditional IT shops where you’re not very DevOps-centric, I basically give you a warning which is, the future is coming whether you like it or not.

The truth is we have to adapt or you’re going to die. We can’t just keep doing the same classic waterfall methodologies or clinging to on-premise hardware. Things like the cloud and DevOps, the reason these are gaining in popularity is because they work better. My warning to all these engineers is that, I’ve watched a lot of companies let a lot of people go who wouldn’t change. You got to get onboard with this. I will tell you, the rewards are your job does become more rewarding and more fulfilling when you start working in this more agile, collaborative way.

Ledge: I can’t beat that. It’s a great finishing thought. Thanks so much.

Andrew, great to have you on. Really great insights.

Andrew: Thank you very much for having me. I appreciate it. It’s been fun.