Ex-PayPal pros shun AI with SecOps IT automation firm

IT automation startups come out of the woodwork constantly, and many look to capture attention by deploying the buzzword "AI." But two veterans of the massive IT environment at PayPal say they'll avoid that route with their new cybersecurity company.

Rezilion was founded 18 months ago by CEO Liran Tancman, formerly the head of PayPal's security products center, and CTO Shlomi Boutnaru, formerly PayPal's chief cybersecurity technologist. It officially launched Dec. 10 with an eponymous product that uses a reverse engineering process, rather than machine learning, to parse application code in the CI/CD pipeline, and automate IT security policy enforcement through partnerships with tools such as Chef Automate. The company raised a round of seed funding of $8 million and has one publicly named customer so far.

SearchITOperations caught up with Tancman this week to discuss Rezilion's unique approach to cybersecurity IT automation.

How did your experience at PayPal influence Rezilion?

Liran Tancman

Liran Tancman: PayPal is an excellent school for how to manage and secure a huge environment. For me, it was a humbling experience. It was a huge organization, with such scale and velocity. That's what I will say about it.

What was behind the decision to stay away from AI? That seems to be all the rage in IT automation.

Tancman: You use AI when there is a pattern to learn, and when this pattern can be used accurately enough so that it doesn't produce too many false positives. But at very high scale, AI fails in two ways: If it keeps changing too fast, exactly how are you going to learn a baseline? The idea [with AI] is that history will repeat itself, which is not true for environments that keep changing every few seconds.

Then there are false positives, even if you get to amazing precision. At a previous company, we got to a false positive [rate of] once in half a billion -- every 500 million events. Mathematically, that's as good as it gets, but when you multiply it by the amount of compute [nodes], at 100,000, and by a million events a day, once in half a billion is actually 200 false positives per day. The classic way you [address] that is to have people tune, but by the time you're done tuning, guess what, you need to retune, because there are 200 new versions [of code] on the network. This is why machine learning is not a good solution for large-scale, fast-moving environments. There are some places in security where AI can actually work. I'm not saying it couldn't -- in IoT, or industrial or even some more classic corporate networks. AI is a good tool in itself. You just need to throw it at the right problem.

So what is your approach?

AI is a good tool in itself. You just need to throw it at the right problem.

Tancman: We plug to your CI/CD pipeline and we look at artifacts that are flowing to production. Every time there is an update, we run a parsing process with what we call miners, you can think of it like a reverse engineering process, where we are figuring out for every server, virtual machine and container, what we expect them to do -- their expected load, what commands they are expected to execute and, when possible, where they're going to communicate to the external world. We determine, based on the code that developers push, what is the correct state, for every instance in production? It is immediate, there is no learning time, just push it and update. Then in runtime we detect what code is actually loading, what commands are actually executing and where [workloads] are actually communicating. Is it what [the system is] supposed to do? If not, we feed that to your IT automation and your DevOps systems and we say, 'This instance is unhealthy. You need to redeploy that, and go back to a known good state.'

Does Rezilion support a GitOps deployment style? If there is something wrong, does it trigger a GitOps build instead of changes in production?

Tancman: Yes, of course. And not only that, the more immutable and GitOps-oriented you are, the better it is for us, because we want as much information as possible from your CI/CD pipeline. And then the enforcement is also automated with GitOps. Where clients still do manual changes in production, we also have a process, [to track and validate] who does what manual changes.

There are a lot of tools that bake security into the CI/CD pipeline and analyze code. How is this different?

Tancman: If you look at all those tools, they're going to find vulnerabilities in your CI/CD. They're going to eventually produce many more vulnerabilities than your development team can actually fix, because there are many vulnerabilities. We are in runtime, so we know what's actually executed. Our statistics show that 72% of vulnerabilities are in libraries and code that are never really executed in production. Because we know what's happening in runtime, we can feedback and say to developers, 'Hey, you know, those libraries, it's true you need to patch them, but you don't really need to do it now because it is not executed. It is not exploitable. The remaining 28%, half of it, we can mitigate. You need a strategy, but we can buy you time. And then there is the 10% you actually need to solve tomorrow morning.' We create more security for less work.

We have a partnership with Chef InSpec, which is exactly that type of tool. We feed them back our insights, on what needs to be fixed most urgently. If you're using Chef as your IT automation and DevOps platform, you can add our resilience to that and have it baked in to your DevOps process.