SIEM concept

Spotlight: SIEMs suck. Panther is out to change that. 

In this Spotlight episode of the Security Ledger podcast, I interview Jack Naglieri, the CEO and founder of Panther, about the evolution of incident response, the failures of the current generation of SIEM technology and the growing need for what Naglieri terms “detection engineers” – security analysts who can use their coding skills to create fine grained detections.

As always,  you can check our full conversation in our latest Security Ledger podcast at Blubrry. You can also listen to it on iTunes and Spotify. Or, check us out on Google PodcastsStitcherRadio Public and more. Also: if you enjoy this podcast, consider signing up to receive it in your email. Just point your web browser to to get notified whenever a new podcast is posted. 

[MP3] | [Transcript]

One of the biggest challenges for cybersecurity companies that charge to market promising to fight cybercriminals and other miscreants is that the landscape on which they battle is constantly changing. The ongoing parade of major breaches and cyber incidents is the proof of that.  And yet – as in kinetic wars – with each new incident, the seeds of the next generation of defenses and weaponry are sown. 

Lessons from the Yahoo! breach

Take our guest this week. Jack Naglieri is the CEO and co-founder of Panther, a company that is trying to reinvent the market for SIEM – Security Incident and Event Management – technology. The germ of the idea for the new company stemmed from Naglieri’s experience, early on, working in incident response at Yahoo! as that company dealt with fallout from a massive data breach at the hands of Russian intelligence that ultimately exposed data on all 3 billion Yahoo! user accounts – the largest known data breach  in history.

“SIEM vendors don’t understand what the practitioner is doing. There’s a lot of SIEMs that people ubiquitously hate…but I don’t think that has to be the way any more.”
Jack Naglieri, CEO of Panther. 

The size and scale of Yahoo! operations – complicated by its mix of acquired and developed technologies; on premises and cloud-based systems and more – exacerbated the challenges of doing incident response. Furthermore, the tools available for IR at the time, including SIEMs, were too rigid and slow to scale to the challenge. That’s still true today, as organizations wrestle to adapt an older generation of tools to address modern threats and attacks. 

SIEM is dead. Long live SIEM!

For Naglieri, the experience at Yahoo! and subsequent work for AirBnB highlighted the need for  a new kind of security persona: what Naglieri calls a “detection engineer” – essentially: a security analyst who can code. He also saw the need for a new kind of SIEM: capable of making sense of massive, realtime streams of data from diverse platforms and allowing engineers to do “detections as code,” using common coding languages – like Python – to fine tune detections, rather than asking analysts to master arcane and proprietary scripting languages. 

Jack joined me in the Security Ledger studios to talk about his journey in the information security space and the experiences that led him to launch Panther. We also talk about the ever-evolving challenge of incident response and  how the first generation of SIEM tools is showing its age and leaving organizations in the lurch. 

You can listen to the podcast using the player (above) or download the MP3 using the button.


Jack Naglieri: My name is Jack Nagli. I’m the founder and CEO of Panther.

Paul Roberts: Jack. Welcome to Security Ledger Podcast.

Jack Naglieri: Thanks for having me.

Paul Roberts: You’ve written for Security Ledger, you’ve written a really great kind of opinion piece. We’ll link to but I think this is your first visit to the podcast.

Jack Naglieri: It is.

Paul Roberts: Yeah, that’s great to have you on. So for folks who aren’t familiar with you or with Panther could you just give us your your origin story and also talk about Panther and what the company does.

Jack Naglieri: Sure. I’ll give you the short and sweet version of my origin story. I moved out to Silicon Valley in 2012, got a job at Yahoo as an incident responder on their security team. Worked there for about four and a half years in the years of their biggest breach, which also was the biggest breach ever on the Internet, which isn’t really a brag. It’s just a fact. . So

Paul Roberts: A billion users if I recall? I think.

Jack Naglieri: Something like that. It was pretty…

Paul Roberts: A lot of zeroes…

Jack Naglieri: I obviously can’t talk about that, but, So was [00:01:00] around in the company during those days and then worked on the IR team for a while, transitioned into being a security engineer because doing instant response at that scale was pretty much impossible and the tools that we had just weren’t working.

So I wanted to try and build build and deploy tools that would make my life as an instant responder much easier by getting the right data, formatting it properly. Being able to search it and having data retained for more than, a few weeks or months, which is very common in a lot of SIEMs. And then after that, after Yahoo, I moved to Airbnb doing the same thing, but in a cloud native environment.

And Airbnb was really in its blitz scaling stage. At that point we had thousands of employees and all around the world and it was really gaining a lot of popularity, just more generally in the in the culture in the travel culture. And it was really an incredible time and moment for me [00:02:00] as an individual to learn about the cloud, learn about AWS, things like that.

During that time, we built an open source to tool called Stream Alert. Stream Alert, and. Stream Alert was a data analysis framework built on a bunch of AWS services like Lambda and Kinesis and s3, and it really allowed us to have an alternative to SIEM that was much more scalable, cheaper, faster, and more flexible.

And we established our security monitoring program all around Stream Alert and all around this idea of automation and serverless and really cool new tech. We also built another tool called Binary Alert that also was released, which is similar, but for binary analysis using YA rules. And then we had a few other things internally that we never released, but that really became the inspiration and precursor to what Panther became.

Stream Alert, not Binary Alert. And because of the success of Stream Alert, we really saw that, okay, this is actually a huge need and we’re seeing a lot of big companies out in Silicon [00:03:00] Valley and beyond really adopt this paradigm of streaming analysis, detection as code and then eventually what led into a lot of the work that we do around data lakes because SIEMs were just super slow, super expensive, really rigid, and not really built for the engineering security persona that we all were because we knew that the engineering persona was required to scale a security program. That brought me, and this isn’t a short version at all, I’m sorry, it’s a little bit longer. The short version would be three sentences. But after Airbnb, I started a company, and it’s actually kinda an interesting origin story because I obviously had zero entrepreneurial experience at that point.

All I had done was work inside security teams and build tools and operate at a big scale, and that’s really all I knew. But what’s so fascinating about startups in Silicon Valley just in general, is there’s a constant process that’s [00:04:00] happening on the venture side where people are just trying to figure out like, what are the biggest next problems to go solve?

And an investor who is thinking about this in the ops world reached out to me and was like, Hey, I saw your project. I saw Stream alert. It looks really cool. Would you be willing to have a convers. And I was like, sure. So I was already thinking about if I wanted to try and create a company around this anyway.

I thought it’d be really cool to work on this full time. And that was always the motivation. It wasn’t ever me wanting to build a company. It was just this project is impactful and it’s super interesting to me and it’s allowed me to learn so much and grow so much as an individual. And I’d love to continue making it as good as it can be.

And there’s just this pattern. I would’ve hopped from company to company had I not done this and just rebuilt this over and over again. Cuz that’s a pattern that happens all the time in big Silicon Valley companies, or really just any company at a massive scale. There just aren’t off the shelf tools that really work.[00:05:00]

So I met this investor and we had a really long conversation about what this could be and I was leading with, hey, like this is a really big problem in security and this is really the angle that Stream is designed for. It’s designed for security. And, few weeks later we were like, let’s start a company. So he incubated Panther from the beginning and then we built our verse first versions of our product and Panther was really designed to be the continuation of that idea of what if we built a SIEM that I like to say a SIEM that doesn’t suck just cuz funny. But in a lot of ways, most SIEMs just generally suck and suck because they’re poorly designed, super expensive. They really don’t align to

Paul Roberts: Kind of mass customization, right? That you an expert just to get it to work. Yeah.

Jack Naglieri: Right. But I think the thing that I’ve always struggled with SIEMs is you have vendors building SIEMs over in the corner, and then you have practitioners and there’s massive gap in between where [00:06:00] SIEM vendors don’t actually understand what the practitioners are doing. So what ends up happening is we build a lot of these tools around the SIEM because of that. And that’s, I think, why this big disconnect exists where there’s a lot of SIEMs, people just ubiquitously hate, but it’s the, it’s like a necessary evil is what people learn to live with. But I don’t think that has to be the way anymore. I think that having a company that’s specifically designed with a practitioner in mind is so important and that’s why I’m really excited about what we’re building and what we will build will continue to build for many years going forward. So started the company in 2018 just after leaving Airbnb. This investor helped me incubate the company. We made our first hires and then we were just trying to figure out like, where do we even begin? ‘Cause SIEM is such a massive problem. There’s so many components to it. There’s the data element, there’s the analysis, there’s a response, there’s alerting, there’s pulling data. There’s routing to your [00:07:00] team, there’s false positives, incident management, and it’s just like the list goes on. This enrichment, I didn’t even talk about that.

There’s so much that goes into it. It could literally be four or five different companies, we’re a single company and we’re trying to take this massive problem on. Eventually what we ended up doing in 2020, about a year and a half later after starting was we open sourced a lot of the stuff that we had built, and effectively what it was is it was a better architected stream alert with a user interface and really building the idea around UI driven workflows, in addition to a lot of the command line driven workflows that existed in Stream Alert.

But the problems with cly based workflows is that analysts basically just can’t use them. It’s all GitHub oriented and analyst going from a pure analyst job, which is looking at logs and understanding the security context of them from a developer, like to a developer workflow is a huge. So the whole idea with Panther in the beginning was let’s build something that’s [00:08:00] faster, even more scalable, and starts to abstract these workflows into a ui.

And then that way, we still want the scale components and things like. We created a really scalable platform. Today we have some customers that send us, upwards of a petabyte of data per month, which is pretty remarkable because I don’t think, I don’t think any other SIEM in the world is able to do that.

And there’s obviously like asterisks around that, right? It’s depends on the pipeline that you’re using and like there. There’s always edge cases with SIEM, which makes it also very hard to build. And no one is consistent. No one’s even consistent with how they name their detection and response teams.

Everyone calls it something different. Sometimes it’s a C cert team. Sometimes it’s action team. Sometimes it’s like some random phrase the CSO made up, it doesn’t really have any consistency, which is hard. But so going back like 2020, we open source in January, we open source this, very like V zero version of what we had.

It had some other features as well, like cloud security [00:09:00] scanning and just scanning your database account, modeling your resources as json then being able to use detections as code to analyze it in addition to the core part of the platform, which is taking in your log data, normalizing it, and then allowing you to run detection as code on it.

So it’s basically Python function, so you can run on data as stream. Then it lands in a data lake, and then you can query it with sql. And those pipelines just historically are extremely nuanced, extremely hard to create and manage. And the fact that you can basically, with zero work just onboard all of your data, it gets normalized and then you can stream it at any scale stream and analyze it at any scale is a pretty remarkable step function increase.

Right? That’s a really strong zero to 10. I wouldn’t even say it’s zero to one.

Then there’s the 10 to 100, which is basically what we’re working on now. And we have been working on building the primitives for, which is how do we abstract all those technical things out so teams get the benefit of scale and these workflows of detects code without [00:10:00] having to understand the technical nuance of it.

So when we open sourced, that was the start of this is how do we get people using this and. It was fairly successful. Like we had, a few hundred GitHub stars and we’d been using it. And really my goal was I just want 10 customers. I just want 10 people paying for this. then I know we have a business.

And that’s what we were able to do at the end of 2020, which was really remarkable. And also keep in mind the timeframe here, we open source in January, 2020 pandemic.

Paul Roberts: Hmm..what was happening in January, 2020? Do I remember that? And…

Jack Naglieri: A thing called the Coronavirus. This. Starting to show up on are talking about it like, oh yeah, this thing out of China what’s gonna happen?

Everyone’s like, yeah, it’s fine. I’m gonna keep going out. I’m gonna keep flying and stuff. And then, lo and behold, March we go into full lockdown and I’m, at this point we’ve raised four and a half million. have… I think we have 12 people in the company. [00:11:00] Uh, we had zero customers, zero revenue, and I was just like…

Paul Roberts: And staring down the barrel at a global pandemic that seems to be, cratering economies.

Jack Naglieri: But the thing that’s interesting is we’d already built the company pretty remote, and I had a handful of employees out in Europe at that time because one of my earliest employees is this this engineer who was ex Amazon and to his credit, and him and one. They’re the reason that our architecture is so scalable because they built it for Amazon and Amazon scale is like mind blowing.

And they told us like the scale of things they were doing per day. And I was just like, that’s crazy, but also please design this for me. You clearly know what you’re doing

Paul Roberts: No. But yes…

Jack Naglieri: That’s one of the great greatest joys of being a founder is not being the smartest person in the room. And in empowering and hiring really great people who have remarkable experience.

So anyway, because we had those people spread out when the [00:12:00] pandemic happened, it wasn’t a huge change to the company cuz we had already established our written culture. We’d established things like Scrum and I’ve always brought Scrum with me anywhere I went, even in the Yahoo days.

I learned DevOps. I almost said from a young age, which is funny, but from, my time as a security analyst to make that jump to engineer, I had to learn DevOps because I was deploying tools at a massive scale. And that’s really hard to do when you have hundreds of thousands of systems of different operating systems.

And think about Yahoo, right? They’ve, they’d been around for 20 years. They had acquired companies. They had this crazy combination of like on-prem and cloud.

It was a really unique experience that I probably would’ve never had anywhere else unless I was at Facebook or Google or some company of that scale and that really helped…

Paul Roberts: Yahoo, obviously, predates both those companies, right? I They really are, an OG.

Jack Naglieri: For sure. And they had incredibly talented engineers at that company. People who built. Infrastructure as code [00:13:00] before it was a thing, so making that transition to things like Chef and Terraform was so fascinating and watching that happen. But anyways, so Panther was fairly remote when the pandemic started, but we were still such a young company and I had no idea if we were gonna survive.

So thankfully we survived. And I would say actually we, we ended up thriving during that time because our whole business was built in the pandemic. And it’s really challenging to build a startup in general. So adding pandemic on top of that was a fun experience. But 2021 was such a whirlwind of a year. 2021 was the year that we uh, we took our team from 20 to 100. We scaled our customer adoption in a similar fashion. And we signed on some incredible companies and teams to use Panther like GitLab for example and many others, Dropbox, et cetera. And these are all on our website. [00:14:00] And that was a really,

Paul Roberts: Yeah.

Jack Naglieri: Yeah, it was really amazing and really hard at the same time. And we were trying to really build the company to support that growth. And that was first time I ever really felt that pull and that scale.

And it was a really remarkable time. So that kind of leads to where we are today, which is, how do we continue to evolve, right? Because I always wanna be a company that’s evolving and continually fixing, improving the lives of security practitioners.

That’s the reason that we exist. We exist because I didn’t wanna just keep building SIEMs internally myself,

I thought there was a better way. And, I’m also not the best person in the world to do it. So I wanna try and hire the best team that I. From all these different backgrounds and we’ve been able to do that, which is really remarkable.

And , the whole goal now is like what I was saying before, how do we abstract a lot of the technical underpinnings that have to exist for SIEM to be successful and make it approachable for the broader market. So we of end this pain of SIEMs suck and all they do is throw me false positives.

[00:15:00] And it’s actually funny. I was, I did a poll on Twitter the other day. I’m actually pulling it up right now so I can see what the latest is. And I asked the question, I was like, what percentage of your alerts are false positives? And more than 50%, actually 50% said 75% and more

Paul Roberts: Yeah.

Jack Naglieri: …are false positives. That’s so insane. That’s crazy to… That’s so mind blowing to me. 13% said zero to 25. So that means overwhelmingly 90% have at least a quarter of their, actually probably even more than that, 75% of teams, at least half of their alerts are false positive. That’s so crazy.

Paul Roberts: Do you think some of that is just because of the shall we say the advanced age of many of the prominent SIEM platforms? know, You think about Splunk, that’s a product really, thats, I don’t know how old Splunk is now. It’s certainly more than a decade old.

Jack Naglieri: Very old.

Paul Roberts: Yeah. And really designed in some ways for an earlier era than the one that we inhabit now.

Jack Naglieri: And that was the whole premise for why I started the company. Companies like Elastic and Splunk, and even Sumo Logic for that matter are all very old companies and they, I’ll give them credit. I don’t wanna say that it’s a terrible business and it’s a terrible product because it really did serve a need and it still does serve the need today, right?

If you go even further back before those tools, it was really first Gen SIEMs before them, right? And then we moved to the log analytics platforms because those SIEMs didn’t scale and they weren’t flexible. And now that pattern is happening again, history is repeating, but this time it’s the cloud version.

And if you’re not doing these primitive things like structuring your data and operating in a cloud native environment, you’re gonna always live in this world of ops hell. And it’s such a distraction. It’s such a unnecessary distraction for security teams. they need to be operating at a much higher level than that.

They need to be thinking. What can I strategically do instead of tactically like putting out fires? [00:17:00] And that’s the only way the security teams are actually going to evolve over time, because if we’re always being re reactive and not proactive, then nothing really gets better.

Paul Roberts: Kind of term definition. You mentioned detection as code. Could you just for our audience, sort explain what you mean by that?

Jack Naglieri: It’s actually a lot more basic than people probably think. As security practitioners we’ve always written little python scripts to analyze things locally. At least I, I always did because my SIEM couldn’t do it, I was like, okay, I have 50 terabytes of log data that’s just sitting here on a drive somewhere in a virtual machine.

I’m gonna write a Python script that analyzes it. Think of detections is code is a streaming version of that. So instead of your logs living on a disc somewhere and a Python script that loads them.

Imagine if you could just analyze the data as it’s streaming to a data lake. And a data lake’s a fancy way of saying a cloud data warehouse, like a structured cloud data warehouse.

And that’s really what detection is. Code is, it’s declaring the attacker logic [00:18:00] or the logic that you care about as the team. example SSH logins from not the US very basic example, right? Not the most, not the best rule, but just, for the purpose of

Paul Roberts: Better than nothing.

Jack Naglieri: Right? So you would say, okay, my Okta has an action field action equals in Python you would say action equals user sessions start and then the really cool thing is you could say actually sometimes there’s a few permutations of that. Maybe I wanna say it starts with user session start, or maybe I wanna do a regular expression, or I wanna do a list look up or whatever, right? Like this thought process is trivial in Python, but in something like a Splunk or an Elastic or whatever, where they, those languages were all about just simplicity.

It’s much harder to do that logic. So we built this protectionist code paradigm in Stream Alert. Which I don’t really think there was any other tool that, that did it before Stream Alert, and it just allows you to have so much more [00:19:00] efficient detection creation.

You would have 200 or 400 rules or whatever, but before you can condense that down in like half because you can just cover more cases in a single detection.

And because the language is more flexible and more powerful, you. You can just, you can do things that are of like medium sophistication, which is so much ease versus this like crazy long query. You’re just like, what the hell is this thing doing? have no idea. And then the other thing with detection is code is you can test it.

You can be like, okay, given this sample or given these samples, I expect these two or three alerts to fire. That’s awesome. And having that assurance that the thing is gonna work. When you put it in production is it’s table stakes at this point, right? We’ve been doing this in software engineering for years.

Why don’t we have it for security? That was the whole idea behind it. So detect is, code is literally just using basic python or, sub whatever language [00:20:00] and express your logic in Python instead of a, a domain specific language. That’s the whole idea behind it.

Paul Roberts: So would a YARA rule be an example of detection as code?

Jack Naglieri: It does an example, especially with what Chronicle put out, the Yara L language, which is bit more, I don’t know if it’s fully Turing complete language. I don’t, yeah, I can’t recall if it is, but yeah, that’s an example. I’d credit them for that. Absolutely.

Paul Roberts: One of the challenges that, that you talk about a lot is just the, the difficulty of, managing security across, hybrid cloud environments like detection response, correlating activity. Those are all challenges in, the types of iT environments that most startups most companies of any size at this point operate versus the old days, with traditional IT environment. Could you break it down for a little bit for us? Where are the pain points, and how, and what are the challenges um, that companies are encountering as they’re trying to correlate activity [00:21:00] and, identify, emerging threats in these hybrid environments.

The interesting thing with hybrid environments or really with just logging in general, is every security team has a different tolerance about what they want to look at and what they don’t wanna look at. What I mean by that is some teams I know don’t care about endpoint logs at all. They’re like, we’re not gonna look at it cuz it doesn’t matter.

At the end of the day, what matters is has access to product. Yeah. I’ve heard of teams talking about that. Yeah. Because cuz they assume that every device is bad in some way. They just automatically, it’s like untrusted. And they’re like, all we care about is who’s accessing our production environment and from where.

I think that’s a very, that’s a very spicy take. Most teams don’t do that. They’re like, drop on CrowdStrike or Sentinel One and, get that data somehow.

Yeah, sure.

Jack Naglieri: So the first challenge in my mind is just bridging the two environments just in general. Like how do we get our on-prem data into the cloud?

That’s one [00:22:00] challenge in of it itself. Can we at a high scale, cuz production environments are very high scale. How do we get this data into the cloud? And it can be a simple answer sometimes, but it’s never simple to do logging. Logging is a very challenging problem because it’s highly vari, like variable.

Like the scales go, can go up and down by 50% per day based on like traffic patterns, right? If you’ve ever worked in a company where you can see. It’s very common, like during business hours to have like super high traffic and then less in, in the downtime, whatever that is for your company.

So it’s pulling the data into the cloud and then economy for scale. That’s one big issue. And then after that is the like, like identity and resolution at sea resolution is what people have been calling it. Where you’re saying, Jack and ok. Jack.Naglieri, whatever at is, jacks_naglieri over [00:23:00] here. And just being able to do that resolution across everything is, it’s all very difficult.

Paul Roberts: Sure. Yeah.

Jack Naglieri: Personally, I don’t think anyone’s really cracked it. Both the scale and and the accuracy side. I don’t think anyone’s done a great job of, and there’s still work to be done there, but and the fact that there’s so much unpredictability with on-prem data.

So as a SIEM provider, I have to live somewhere in the middle of that where I give enough primitives for people to pull in their custom data and then have it fit into the models that we create. And there’s always a level of education that has to exist with that. So that’s a challenge. But in terms of modeling attacks and things like that, I think everyone would say, oh, we have MITRE ATTCK.

As our, our framework for expressing detections and, we’re no different. We have the MITRE ATTCK matrix in Panther. You can write detection, map to it, et cetera. So that’s what, that’s pretty standard. People are doing that. And it’s a great framework for visualizing the kill chain sure that we have our bases covered.

But it’s by no means and all be all, you still have to use, you still have to use what’s very specific to your environment. And the threat models in attack are a good baseline, but they’re exact. They’re, like I was saying, they’re by no means exhaustive. So having that intuition I think is important.

And being able to pull in your custom threat modeling and layer it on top of MITRE ATTCK is super important.

Paul Roberts: You’ve written about this notion of a detection engineer and you’ve got a sub stack actually, and you’ve written about it there and check it out. So I thought that was really interesting. It’s a new, it sounds familiar, but I think you’ve imagined a new role that’s like an amalgam of other roles. Could you talk about the concept of detection engineer and like what the advantage of having somebody with that title and role might be?

Jack Naglieri: Of course the detection engineer is literally a security analyst who can code. That’s basically it. If you understand the tax and you’ve done incident response and then you learn how to code. Congratulations. You’re a detection engineer now.

Paul Roberts: Yeah. You talked about this earlier when you were talking about, the difficulty of, like command line interface for people who are used to, who are coming out of SOCs and stuff, right? Like they’re not, that’s not something that’s familiar to them in the way that it is to a developer.

Jack Naglieri: For sure. And I’m being like, somewhat like facetious, right? It’s yeah it’s more than that, right? It’s someone who has a security background who then learns DevOps and software engineering principles, but not at a very deep level. You you don’t need to learn certain things like chef and Puppet. Maybe you do. It really depends, but I’d say you don’t need to be an expert at those things like you would if you were a DevOps engineer or an infrastructure engineer. It’s not that level. It’s maybe a quarter or a third or a half of the level of, full on software dev.

Paul Roberts: What do you need to know?

Jack Naglieri: That’s a good question. I’d say so as I was answering that question, I was thinking about it. Likely what you need to know is you need to understand infrastructure. So you need to understand the, [00:26:00] the core, like 80% AWS services or GCP or Azure, whatever cloud you’re in, you need to understand those fundamentals.

The big things like pub sub in, in Amazon, that’s Kinesis or SQS. Just understanding like messaging, how data moves from one place to the other. You should pretty much understand that and have a good sense of how to build really basic pipeline. So an example of that is can you feed some data to S3 and then can you analyze it with a Lambda function and can you build all of that yourself. If you can actually do that, you’ve probably learned all the primitives that you need to be a detection engineer, which is infrastructure and software development.

And then the security side is taken care of because you’re an analyst by default. And I’m actually kind of of giving you a little bit of a sense of what I did.

Paul Roberts: Yeah.

Jack Naglieri: right? Because I started as I had an internship. 10 years ago, probably long, longer than that. This point, it’s 20, 22, 12 years ago, and I learned what a SIEM was and I learned what malware was and how to remediate that and how to re-image systems and why you’d do it and what you’d look for, right?

And then once you [00:27:00] learn that, it’s cool, how do I do this at but more, how do I do this at a much bigger scale? And that’s exactly what you have to learn with DevOps and software engineering. It’s, how do I take this one thing I did on one system and repeat it on hundreds of thousands of systems?

Or hundreds of thousands of logs. That’s exactly, it’s all, that’s all we’re doing. That’s all the detection engineers are doing. You’re operating as a security analyst, but at a much bigger scale, and that’s just required. Now you have to do that because moving to the cloud and everyone going from, in the office to fully remote, it just created more things to look at.

It’s very, it’s a lot simpler than we think, than we make it out to be by using these terms like detection, engineer. Whatever. Talking about the transition of data growing, it’s –no one really talks about the very primitive element of it, which is security engineers are evolving for scale, and that’s all DEs (development engineers) are. It’s the same thing.

Paul Roberts: So did you have development chops before you started tooling around with SIEMs, or was it the other [00:28:00] way around you? You honed your chops doing, security response and working in SOS and then picked up the development afterwards.

Jack Naglieri: I did not work on software engineering as a analyst or in SOCs. I never did. It probably would’ve been immensely useful, to be honest…

Paul Roberts: Did you have that skillset though, or did you have to teach yourself that after Yahoo?

Jack Naglieri: I, so I taught myself during Yahoo because I made the transition from being an analyst and just using, name a big SIEM and

Paul Roberts: Splunk.

Jack Naglieri: I’m not gonna say Yeah. So I, my background is, my, my major in college when I was 18 was information technology. It’s so basic and, but it’s very wide. Also keep in mind like I went to school, so I went to school and I’m dating myself I guess, even though I’m still fairly young. But I went to college when I was it was 2008, I went to George Mason and. In the DC area. It’s nothing like Silicon Valley. No one talks about startups. No one talks [00:29:00] about being an entrepreneur. There’s no sense of what it means to study computer science. It’s just a such a different culture.

It’s very government oriented

Paul Roberts: gonna say, everybody just talks about what agency they’re gonna

Jack Naglieri: polar opposite. Yeah, so I studied it cause I was like fairly technic. And thought was interesting and always was savvy with computers and didn’t really know. And my family, no one in my family is as technical as I am, so I was the first one to go into this field and with IT I studied software development, I studied networking and then security.

And I was like, okay, I think I’m gonna focus on security. This sounds cool. I almost went into networking or development, but I was like, security feels like super important and is gonna be really needed in the next 10 to 20 years and beyond. Unsurprisingly, I guess I was correct in that. So I studied IT and then I had like really basic software experience when nothing, nothing that’s truly valuable when you’re in the And then I think it’s so funny, we [00:30:00] spend so much time thinking about school and then you go work in the real world and you’re like all that was useless. And I had to literally learn everything again.

Paul Roberts: Yeah.

Jack Naglieri: So I picked up a bunch of books and I’ve always been good at learning just by, by reading and applying that knowledge in real life.

And that’s exactly what I did. So I bought a bunch of books and learned how to code in Ruby while I was at Yahoo because I was deploying things in chef. And Chef is a Ruby language and Chef was the way that I learned software engineering and DevOps. And the thing that’s crazy about this is security, DevOps and software are three completely different mindsets, and it’s very hard to learn all three of them.

Meaning if you take a DevOps engineer and you give them a security problem, they’re gonna be like, I don’t know, it’s, that’s completely weird to me. Same thing if you give a software engineer DevOps problem, they’re like, Item Potents, deploying this out to a bunch of different machines and nodes, like I don’t get it [00:31:00] right.

And vice versa. If you give a DevOps engineer software problem, they’re gonna be like, I don’t know, I just write basic stuff. So it’s fascinating that we have this requirement today with section engineers that have to basically have sit at the intersection of those three things. And that’s so challenging.

It’s so challenging to learn and find. And I think that sort of exacerbates the problem that exists. And if we go back to the primitive part of this conversation, which is that SIEMs have historically sucked, then this makes everything harder because now you not only have to find people with those skill sets, you have to build and manage those tools over time because the vendors have done a bad job.

So I’m working backwards from that, which is how do we provide a platform that one gets rid of the ops burden. check check, cloud native, good architecture. Cool. That’s done. And then the next part of that is like, how do we take a lot of these nuanced things that we did with detection in response, such as detection is code and C I C D and these like really scalable things and how do we abstract it?

And then how do we bring [00:32:00] in more things like incident management and in collaboration, how do we bring that back into the SIEM in a way that actually works? And that’s really where my head is right now. So it’s fi figuring out what do the things exist around the SIEM. How has it historically been, and how do we make that better?

Because at the end of the day, I don’t wanna see this anymore where people are saying, “Oh, 75% of my alerts are false positives.” That’s terrible. Like why is it like that? Defense that I’m kind tired of it, and people are trying to just sit, abandon, abandons him and be

Paul Roberts: And there’s huge cost to organizations for that noise, right? In, in terms of mis missed alerts and also, false positives as well. But just stuff getting through and we now know, we all see every day what the consequences of that is.

Jack Naglieri: For sure. And there’s human consequences, right? It’s,

Paul Roberts: Yeah. Burnout.

Jack Naglieri: On the other side of that. And it’s it’s not talked about too much. Actually it is said a lot like, oh burnout. But you don’t really talk about how to prevent that. And part of it is [00:33:00] being a good manager and. Setting them up for success by, helping them either in their processes or in their tooling.

Paul Roberts: Final question. You’re so insightful around this space and this technology.

I’m really interested in where you see things going. Especially, we’re entering a period where I think within information security, you’re seeing a lot of consolidation. You’re seeing a lot of buyouts and M&A. Layoffs too. There’s a lot of, there’s a lot of movement. I’m interested in where you see the space going and obviously where you see Panther going.

Jack Naglieri: Yeah, I love that question. Way I’ve been thinking about this slightly is I wanna make security teams smarter and faster than attackers. That’s been the thing I’ve been saying to myself for the last, like few months, and whatever it takes to get to that point is what we’re gonna do. And as you allude to in the m and a comment, a lot of the tools are getting more bundled back into each other, [00:34:00] and I think that only is going to work.

If you solve this false positive problem and the reason that we’ve built these things like SOARs is a reaction to bad SIEMs, and we put them behind the SIEM to validate the alerts, to ping users, to run threat intelligence and do the things that the SIEMs can’t do. So I think there’s gonna have to be an evolution where we crack the mechanism of having enough flexibility, but not too much flexibility for security teams to detect the things they actually care about and be able to respond in a way that matters. Cause a story I hear too often is, oh, this thing demoed great and then I deployed it and it was total crap. I think part of that problem is, again, going back to what I was saying around vendors getting closer to the practitioners and I. The future of security tooling has to be built with that in mind, and when I talk about what a modern security [00:35:00] company is, it’s predominantly a company that was built by a practitioner who actually understands the problem and was in, in the seat of being a security person prior to being an entrepreneur. So That’s how I see it changing. I think that, again, it’s having the right people work on the problem and approach it in a way that still reduces the overhead from security teams as much as possible to where they can actually just focus on good security work. And going back to this idea that I have around smarter and faster, it’s it’s really central and core to what I think about every day with our product because Panther and SIEM in general is the heart and soul of a security ops program, cuz it’s that thing that receives all the data and then really sends the next step out somewhere. Whether that next step is go destroy this machine or respond, it’s that thing in the middle, it’s the brain.

So I wanna make [00:36:00] that as, as good as I can possibly make it.

And empower our teams to just focus on the things that matter that are security relevant for.

Paul Roberts: Jack, is there anything I didn’t ask you that I should have or anything you wanted to say that I forgot to give you the chance to say?

Jack Naglieri: I can plug, I can give a plug really fast.

Paul Roberts: Go ahead.

Jack Naglieri: We launched something really recently that I’m really happy about, which is you can go to Panther and you can get a 30 day trial by just clicking a button, and with that you’ll be able to manage all your security logs, it automatically normalizes them and it manages the underlying data warehouse.

So it’s basically an infinitely scalable log management solution, which is awesome.

You can do threat detection and enrichment, and you can use detect detection as code. You can plug that into your C I C D pipelines, which is great for compliance, things like that, All again, for free. It comes with, not for free, but you don’t have to build it.

Then the last part of that is you can query this data as far back as you have it. It’s sql, so if [00:37:00] you’ve never done sql it’s just a very structured way of querying our data versus it being like, I’m gonna drop a random string in a search box. benefit of that, of course, being scale, And over time we will see that evolve and become easier and easier.

But the underlying tech that Panthers built on is so important for setting us up for future success and for solving a lot of the problems that we have today around high cost, high ops, overhead, et cetera. So give it a try. Hack on it. You can write some Python in the ui. You can ship. By clicking a button, and then you instantly can stream your data as whatever scale it is in real time, which is really sweet.

And then you can plug into things like your Slack, your Jira, your Asana whatever it is. And you can also pull data from Okta, from aws, obviously from gcp, from a ton of different SaaS platforms and really bring it all into one place.

Paul Roberts: Very cool.

Jack Naglieri: my whole hope is that people stop building this themselves and managing it themselves. [00:38:00] It’s a lot of work and a lot of pain and we’ve been thinking about it for four years straight so far, and we have a team of over 150 people thinking about it every day.

 We love to hear feedback as well. Our product team is always talking to customers every week and getting more on the ground feedback.

So if you guys have that, like we have a Slack community as well, and you can ask us instantly and we’ll respond. We’re here to help. I want security practitioners to know that, we’re not a vendor. You have to be afraid of, a lot of us are ex security people who are just now building this platform for you.

And that’s my goal and that’s all my focus is gonna be

Paul Roberts: By security people. For security people.

Jack Naglieri: Exactly.

Paul Roberts: Hey Jack Nagli of Panther, thank you so much for coming on speaking to us on Security Ledger Podcast. It’s really been a pleasure.

(*) Disclosure: This post was sponsored by Panther. For more information on how Security Ledger works with its sponsors and sponsored content on Security Ledger, check out our About Security Ledger page on sponsorships and sponsor relations.

Comments are closed.