What if you could be proactive in your approach to cloud data security rather than a reactive one once the attack has been made?
This is exactly the solution our guest is providing at Panther Labs. We speak with Jack Naglieri, Founder & CEO, about the cloud-native approach and exactly why SIEMs are getting left behind.
Join us as we discuss:
- Developing Panther & taking a different cloud-native approach to SIEM
- The reinvention of SIEM and how it can “detect any breach, anywhere,”
- Creating a proactive security response rather than reactive
- The future of SIEM as “the heart of your security operations team
To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.
If you don’t use Apple Podcasts, you can find all our episodes here.
Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player
Announcer (00:06):
You’re listening to the Virtual CISO Podcast, a frank discussion providing the best information security advice and insights for security, IT and business leaders. If you’re looking for no-BS answers to your biggest security questions or Simply want to stay informed and proactive, welcome to the show.
John Verry (00:25):
Hey there, and welcome to yet another episode of the Virtual CISO Podcast with you, as always, your host, John Verry, and with me today, Jack Naglieri.
Hey, Jack.
Jack Naglieri (00:34):
Hi, John. How are you?
John Verry (00:35):
I am excellent. It’s Friday, and I’m looking forward to the weekend.
Jack Naglieri (00:39):
Yeah, it’s a little bit rainy and gloomy here today, but
John Verry (00:41):
Where is here?
Jack Naglieri (00:43):
That’s San Francisco.
John Verry (00:43):
Oh, that’s San Francisco. I should have known, and knowing that you’re a darling of the investment area, that you’d be out in that area. I mean, that’s where a lot of the good stuff happens. Let’s start Simple. Tell us a little bit about who you are and what is it that you do every day.
Jack Naglieri (01:00):
I’m the founder and CEO of a company called Panther Labs, and our mission is to detect any breach anywhere. I’ve been working on the company for the past three and a half years. Prior to starting the company, I worked as a security practitioner for a combined nine years, let’s call it, across Verisign, Yahoo, and Airbnb, and then decided to start a company to take the plunge into becoming the vendor to build security solutions for security teams just because my experience was really challenging as a practitioner in those companies just due to the tools that we had to our disposal. We figured out some secret sauce that worked for us in the Silicon Valley companies, and we wanted to build a product that could give value to other security teams like my former self six years ago. That was really the whole idea.
John Verry (01:51):
So it’s almost like the time travel. You wish you could go back in time and give yourself these tools then. All right, before we dig into exactly what the value prop is, I always ask what’s your drink of choice?
Jack Naglieri (02:01):
Alcoholic or in general?
John Verry (02:03):
You tell me.
Jack Naglieri (02:05):
I don’t really drink alcohol. I drink wine very occasionally. I kind of stopped drinking a while ago. I’ll do it very, very occasionally. My drink of choice is a cappuccino, for sure. Cappuccino with some type of alternative milk is my favorite, and I’m a huge coffee person, and San Francisco is the perfect place for that. That’s my drink of choice.
John Verry (02:26):
All right, so you’re in San Francisco, so are you drinking San Francisco. Is Peet’s San Francisco?
Jack Naglieri (02:33):
Oh, Peet’s is a chain though. You got to get. There’s Blue Bottle.
John Verry (02:36):
I see, you’re going to the local.
Jack Naglieri (02:37):
There’s Andytown. Oh, my God, there’s so many good coffee places here. Blue Bottle is the canonical Bay Area example of a good coffee shop. You have Sightglass. You have Ritual. There are so many, man. It’s great. I’m in heaven here.
John Verry (02:54):
Yeah, we don’t get that many out here. If you go to the smaller chains, but that are special. There’s a place called [Rook 00:03:00]. I don’t know if you’ve ever been to a Rook, but if you’re ever traveling on the East Coast and you see a Rook, to definitely trumps Starbucks in my book.
Jack Naglieri (03:06):
Where are you based?
John Verry (03:07):
I’m in New Jersey, but the whole East Coast, you’ll see Rooks. They’re great places. My daughter is a lot like you in terms of her taste there, so I think you’re in the right place at the right time. Obviously, we’ve got a growing regulatory and stakeholder pressure for what I refer typically as provable security and compliance, and the importance of having some type of SIEM solution both from a security and compliance validation perspective is super important. You’re taking a very different approach to, I’m going to loosely use the term, SIEM. I know that you have maybe a dislike to the term SIEM. I know. I know. We’ll talk about that in a second.
Jack Naglieri (03:50):
I really hate it.
John Verry (03:50):
Let’s just say you’re taking a very different cloud native approach. You started to allude to this. Tell us a little bit about what led you to develop Panther. What challenges were you having and then how are you solving those challenges, because we’re still having them, I can tell you that.
Jack Naglieri (04:07):
Absolutely. The biggest challenge that I face as a practitioner was operational, overhead, and scale. It just wasn’t viable to get the data that I need to get into a single place, and it required either we severely limit the data that we’re collecting, we filter, we say, oh, we’re only going to maintain the last two to four weeks or whatever it may be, whatever we could afford from [inaudible 00:04:31] licensing perspective, and, really, that just put us in a really horrible place. We don’t want to be in a position where a breach occurs. We only have 30 days of data because of those limitations, and we can’t answer key questions about what an attacker did in our environment, so scale was really always a big limiting factor.
I worked at Yahoo. I worked at companies that had these big data teams, but they weren’t at the service of the security team at all. It was very focused on the core business. It was never focused on how do we get our endpoint data into this Hadoop cluster. But even if you did, no one in security knows how to write a job on a Hadoop cluster. It’s not in our core competency. Our core competency is how do we identify attacker TTPs, how do we pivot around, how do we do an investigation, how do we ask the right questions to get the right answers around an incident, and that’s really what we care about. There’s always this challenge of the tools kind of being there, but it required this big data infrastructure.
Fast forward a couple years later to when I joined Airbnb, and Airbnb was then that next generation of company that was built in the cloud, so, when we approached security, we took that same approach and, instead of us having to rack servers and do virtual machines on a much lower level, we were just spinning in the EC2 in some stuff with a button click, and we were using services like AWS Lambda and SQS, and it allowed us to take these very complicated data systems and go serverless with them. We actually did.
I did a talk in New York in 2016 or ’17 that was about going serverless and how it benefited us as security practitioners, and that actually was in relation to an open source project that we really set at Airbnb called StreamAlert. StreamAlert was this idea of how do we take cloud-based services like [inaudible 00:06:23], Lambda, et cetera, can connect them all together and build effectively a serverless SIEM that allowed us to process any volume of data, get that response really fast because it’s stream processing, and operate at a very high scale with basically no overhead of Ops and allowed us to be even more flexible about how we do our analysis with things like Python, and then, eventually, the concept of a data lake also is introduced. Like, okay, now how do we store this data while we have to structure it. We have to put it into database tables, and then we’re effectively working backwards from that vision I was talking about of like “Here, we have this really sophisticated business data warehouse, but now we’re applying it for security,” and we get all these benefits of scale, speed, flexibility and all those core elements built in.
Subsequently, when I started the company, this is the evolution of those ideas, so those were always the key things that caused us to build, and that’s what ended up being the reason that we build things like StreamAlert at Airbnb. It’s the same reason why I continue to do that effort with Panther. That’s a little bit of history.
John Verry (07:30):
Yeah, and that makes total sense. We’ve been doing SIEM for a long time, and it was two places where we saw the bottleneck. I’m assuming that you saw the same thing, and your migration to the cloud solved both of those. One was on the compute side, if you wanted to do any type of real time correlation especially when you got into a situation where you needed to do correlation and the event rates were going through the roof, the system would just log down. You weren’t able to do it or you weren’t able to correlate over long enough period, and then the second thing, of course was, again, in those same high EPS instances, in the old conventional days, getting them into a conventional database structure, whether it was Oracle or Microsoft SQL was…
Jack Naglieri (07:30):
Impossible.
John Verry (08:07):
… Impossible right? very often… and if you, God forbid, like we had a problem once at a scale at a Fortune 100 organization that we were working with where the automation that was supposed to automatically extend partitions and the database failed. And we had a, basically a brick database. I mean, I can’t even begin to tell you how long it took to try to like, get, spin up another instance, get some of that, and then be able to bleed that information back out. And it caused all kinds of significant challenges. So, so I’m assuming you, your migration and the technology processes that you took address both of those limitations,
Jack Naglieri (08:45):
Which limitations specifically are you referring to
John Verry (08:49):
Compute and storage.
Jack Naglieri (08:49):
Yeah, it does because we’re effectively offloading it to the service. So as a security team, we’re just care. We’re just caring about the business logic. We’re not caring about the underlying operational components of it. We don’t have to patch servers. We don’t have to care about load balancing. We don’t, we don’t even think about that. We just think about how efficient is our system at processing the data. And, and then that’s a much better world to be in because you completely remove all of the unnecessary components that just don’t really play into security whatsoever. And that was a big gripe that I had with Splunk and even like elastic, right? Like you could run a bad elastic query and take down your cluster. And like, we saw that so much, same, well, it’s like, well, if we want to get more data in, we got to add 10 more indexers and we got to think about these things.
And it’s completely unnecessary. And unrelated to security. Security is just about how do we get the data in that we need? How do we answer questions? How do we correlate around that our data and answer security questions, because that’s what we care about at the end of we want to, we’re accountable to the organization in order to both prevent breaches, but in the event that one does happen limit the exposure of that breach. And you can only do that with good data. So that really ends up being the thesis of the company, which is that security’s a data problem. We want teams to be able to bring that data to life. And that’s kind of like the tagline that we say on our websites, bring your security data to life.It’s just this idea of it’s been sitting dormant and disparate and sort of spread everywhere and all these different formats and it has to come together. And that really is a data problem. So using things like fully cloud native architecture, which also runs as a SaaS again, removes that full operational burden and allows teams to just more easily run at scale. And that’s a huge win for a lot of teams.
John Verry (10:47):
So that idea of abstracting, the technical operational stuff away from the security stuff and allowing security professionals to be security professionals, I know that you just had a B round, congratulations is that what has folks so excited about what you’re doing? Because obviously they voted with their investment, so that they believe in what you
Jack Naglieri (11:08):
So, are you saying, are the investors bought into the technical approach or their customers?
John Verry (11:13):
No, no, I’m sorry. What I was asking is it that abstraction that you’re doing right? this separating the security from the underlying, technology and operationalization is that what has the investors so excited?
Jack Naglieri (11:25):
I mean, investors get excited about product market fit. I mean, that’s just the reality of things, right? If you see any company that’s solving a problem and you get that assurance by looking at the users of that platform and how much people, people are willing to pay for it, that’s what investors are excited about. They’re not nuanced enough typically to truly understand like the core of the products, especially a very nuanced one like panther, which is looking at detection of response. And there’s such a small percentage of people on the world who even know how to do that job. So investors are really excited just because, I mean, the core three areas, and this is like somewhat of a tangent about security, but the core three areas of companies that you need to succeed is team market product, you have to nail all of them.
Basically. You have to have a great executive team that also hires a great team of executors who are able to get things done. You need to have a market that’s willing to pay for your product and you need to have a product that satisfies that market. Right. So if they’re looking at all of these elements, they’re doing a whole bunch of analysis, but I’d say the core thing about momentum comes down to product market fit and execution. And if you nail both of those, like you’ll continue to grow and then you’ll build more trust. It’s sort of a virtuous cycle at that point.
John Verry (12:46):
So, before when I said [inaudible 00:12:48] you kind of bristled a little bit and I, and I was on your website and I think you struggled with the website and I, you have a page on there that says, you compare a traditional SIEM versus Panther. And I think you refer as Panther as SIEM reinvented. Can you explain that?
Jack Naglieri (13:01):
Yeah. One liner is always interesting and I don’t think anyone’s really nailed it yet, including us. I think we could describe the platform in a lot of different ways, but the thing I think in essence, it comes down to is Panther is the heart of a security operations team. And we can call whatever we want to call it. We can call it a SIEM. We can call it. And if people are, people have been gravitating towards XDR, which I’m like I don’t like that either because I don’t think, I don’t think a SIEM is always tied to endpoint, which is like how I perceive XDR. And I just think about a security operational center, really being focused on detection and response investigation and the platform in which it supports that has to take data in it has to normalize data. So there’s a level of VTL, which isn’t separate from SIEM fully.
But at this scale, if you’re saying like a cloud data, like SIEM based on a data warehouse, you’re kind of can combining a lot of different things together. You’re combining detection response. You’re combining ETL, you’re combining data lakes, like all these different things. So I’ve been, I’ve been explaining Panther as like a security analytics platform, security, operations platform. It’s really meant to be this generalized way to create security intelligence out of all of your different data. And that’s really how I’ve been thinking about SIEM to me. Like I have the own, I have my own negative connotation with SIEM because I was a practitioner and I knew they didn’t really work. And they weren’t working for me cause they weren’t practical with how I was actually doing things. So that ended up being the reason that a lot of people are like expensive, slow thing that an actually reflect reality.
That’s kind of what SIEMs were perceived as, and we’re trying to change that. We’re trying really hard to change that and make sure that one, we can at least operate at the scale that’s needed at a cost that’s reasonable. And like, to me, that’s baseline right after that point, then it’s like, how do we make the workflows as practical as possible to reflect what we see in reality, which is people want to use things like CIC CD for managing these detections. They want to programmatically interact with this platform, this security operations platform or this whatever SIEM platform. And they just far way to really be effective at scale for once because SIEMs would just throw out false positives all the time. There weren’t really easy ways to tune them. There. Wasn’t an easy way to really express the behavior you were looking for.
And in this world where we’re operating at scale, you have to start to use these things `like data warehouses and software. And you have to just automate things because we are defending against attackers that are using automation against us. So speed is very important and we have to be able to have speed and visibility about everything that’s going on and very sophisticated systems are required to do that. And that’s been the constant challenge in security. So these architectural decisions that we chose allow us to get our around that and continue on this journey of being good defenders.
John Verry (15:56):
Yeah. So I guess, I guess that challenge is that you do a lot of things that ASIEM does, you do them way better. And I agree with that. The problem is that using a new name, people are still going to the market. You looking for quote-unquote.
So you almost have to have I think it’s an educational selling challenge, in that you’ve need to educate them that yes, this kind of looks that way, but it’s like you said, re imagined or reinvented, I think is a nice way to say it because there is such a negative connotation with SIEMs, definitively and deservedly. So I think the vast majority, if you look from, we started implementing SIEMs in 2004 with E security. We did not of work intelligence. We did Cisco Mars. You look at the vast majority of the projects that we did long term, they were failures, which is why we literally stopped selling SIEM for that reason. Because, , generally speaking, you were not able to keep a client happy. And even if you got the darn thing operational at one point in time, just the drift, as the organization changed, as technology’s changed, as systems changed FQDN changed, the care and feeding and maintenance necessary was way too high.
So you mentioned snowflake before, and you mentioned data lakes and you also mentioned that 2% of the people really understand what security practitioners do less than 2%, probably really understand what snowflake and data lakes are. Can you just briefly explain them because I know they’re critical to your product and people understanding the value prop.
Jack Naglieri (17:13):
I mean, in the Simplest terms, a data lake is a very, very, very big database. Like a big relational database is how I would think about it, right? And there’s, there’s a lot of different ways to sort of slice and dice it, because data lakes can be structured and unstructured. So let me sort of rephrase this and say like data lakes are using things a like generalized blob storage, like S3 and storing your data. And then data warehouse is making it usable. So snowflake is trying to be the defacto like cloud data warehouse to where you can feed as much data as you want into this relational database. And then it’ll elastically scale because it has a separation of storage and compute. So typically the bottleneck would always be like the, like the Splunk scenario I gave you, which is I have more data, I need more indexers.
Whereas in snowflake that doesn’t become a thing anymore. It’s just, I put my data in at rest. It’s stored in some really low cost storage. And then I load compute instances to get to that data, versus it being a bottleneck on the way in. So data lakes allow us to have these like massive call it like a sequel database, a huge scales like petabytes, and more than that, it just kind of becomes infinite at a certain scale. And then your bottleneck becomes like how much compute do you want? How fast do you want this thing to run? The other thing that really goes into data lakes is efficiency and storage. So there’s a, there’s this idea of columnar +storage. So instead of storing the entire record in like a single row, you would store the columns of it and then allow for more efficiency and queries.
So when you say like select username from my logins, it’s just loading that username. It’s not loading the entire row, so it becomes much more performance. So that’s really the thing that went into this technology is like, we have a lot of data. We need to search it fast. So what are these things that we can do in compression and storage and compute in order to make that happen? Prior if we were just using something like a Postgre or my SQL database, we’d be very limited with that tight coupling of storage and compute and data lake sort of decoupled it and made it much more scalable, but there’s always going to be trade offs. Even with data lake solutions, like AWS has options. We have things in Google now like bigquery and then you have snowflake and data bricks. And like there’s a lot of players that really came up in this market. So it’s just really a way to operate at a quote-unquote cloud scale without having to worry about the storage and compute coupled together. That’s like the basis of it.
John Verry (19:46):
Thank you. That was extremely helpful. Because of the fact that you are near realtime or realtime effectively, I would assume that you’re able to do some things, which we traditionally haven’t done. I would say that the vast majority of the time when we’ve used the [inaudible 00:20:02] sorry, [inaudible 00:20:03] using that term, but I think people relate to it, using a security operations platform, we’re behind the curve by the time that we find out about something happening it’s happened. And now we’re sort of in response, are we to a point where using Panther, we can go to like more of a proactive security where it’s not incident detection. If you follow the might or attack framework, right, we’re further along. So that we’re actually detecting and responding, perhaps even in an automated way faster, then can get to the point where I’ve been, that security event has had any impact.
Jack Naglieri (20:36):
So speed was always a core element of why we wanted to rebuild this system. Even going back to the stream alert days, a core complaint with Splunk and other SIEMs was that it just took a long time to get any answers. And when you think about traditional security monitoring, let’s say you have certain TTPs that you’re modeling from MI attack across the kill chain. You would run this as a scheduled search. So going back to the coupling of storage and compute, when you have a lot of data, it just takes a lot longer to process and it’s much less efficient in those systems. So the reason that we built the real time element in Panthers to completely wipe that away to where if you have like very Simplistic sort of point in time things, it becomes very easy to find that right away. The beauty with Panther also is that because we’re effectively doing extreme processing, we can, and we’re using Python.
We can get really, really creative and really clever with how we do analysis. So we can, we can cash certain things in really high, high speed storage, like DynamoDB, for example, which is like an implementation detail. But just imagine like why cashing is really useful in web applications. It’s the same thing. You can keep counters, you can keep certain events. Like we have a built in detection that’s like in probable logins, which is a very canonical example that most people are used to, which is Jack logged in from San Francisco. And then five minutes later, he logged in from Rome and it’s like, well, that’s impossible. Like geographically, you can’t travel that fast. Versus if an employee in the remote first world, which is very common, goes from SF to Sacramento in that are like, yeah, that’s fine. We, that’s not suspicious.
But if we see like a log in one place, maybe that user got fished and then the other credentials are getting used somewhere else. So it’s like, because we’re using Python because we’re streaming these things across, like we get the benefit of like speed and flexibility. So getting over the speed element was really important. And then doing stream level processing changes your perspective about how detection even works. We have this ability to also query the data lake periodically. So we can say that we want that to become a source in our event stream. So we can say in the last hour, show me all of the logins that happen. And then when we filter those, right? So there’s a lot of ways because we’ve created this really sort of powerful streaming engine plus Rules Engine. It just, it creates a huge amount of flexibility in how we do this detection, which allows us to be more proactive.
There’s certain limitations in terms of like, the style of doing detection. Like, for example, we’re not going to find anomalies for you magically, right? Like the style is very deterministic by design and who knows what will happen eventually. Like, I think there’s certain applications of statistical analysis and machine learning that play a lot into useful security, but largely I would say like 80% of those things are expressible by behaviors because every single environment is different. And every single, like really, really good attackers look like normal humans. So it’s very typical to just throw machine learning and into the problem and be like, okay, you go solve it. It’s a little bit, harder than that. And you have to really understand like what you’re protecting. So being able to model that out in code gives a huge amount of flexibility.
And Python’s a very approachable language too. So for most security practitioners have used Python for processing data because they had an incident and actually in a lot of way, that’s typically why they had to use Python in the past. They’re like, oh, we copied a bunch of log data. Now I have to process it. It’s like, well, what if you could just do that as it’s streaming? And that’s basically what Panther is. We give users that ability and that allows them also to sort of up level their own skills in software development. And it doesn’t have to be very complicated. It’s actually quite basic where we’re doing field equals value, field in list There are these very basic patterns that emerge, but for those who are savvy developers, they can really go in and extract the power of third party libraries built in libraries, using security tools that are very popular. Like Netflix is a number of open source Python tools that are great.
So it really does change the perspective of like how we can do this analysis. And that’s the part that’s been the most interesting for me. And it’s just a whole new capability that security teams haven’t really had yet.
John Verry (24:56):
Yeah. Listen, I think the idea of using Panther is I love your term approachable. last year I decided that I hadn’t been in code for a long time and picked back up with a programming language. And I played with Python and I was just amazed at the extensibility environment and the number of tools that are out there for every potential field of use. So, and the other thing which is great about Python is that you go to the internet and you search and you can find the answer to almost any Python question that’s ever been posted with some sample code, which is awesome. So I’m assuming, that your best use case is probably organizations that are Similar to the ones that you came from, right? SaaS, cloud service providers, organizations that are probably working in CI/CD world. They’ve got continuous compliance requirements. They’ve got online entities that are generating massive amount of information. Am I missing anything? Are there any other use cases that you see Panther being really significant for
Jack Naglieri (25:55):
The most significant ones I see are just threat detection and response. So corroborating all the data together from anywhere. So when I say any breach anywhere, what I’m referring to is taking your cloud data, your endpoint data, your network data, your application data, we see that very common and pulling it all together into a unified format. That’s searchable, pivot able, correlative, all of these things like that in itself is a very hard problem to solve. And then on top of that, then now you can look for certain types of behaviors. So I’d say the primary use case is true incident response and proactive detection. And then the secondary is compliance. It’s helping your Ops team out with certain things. it’s just understanding those patterns and being able to relay to other internal stakeholders, which is common for security.
John Verry (26:43):
Got you. You said, obviously with, when you said threat detection and response, are you providing any type of a sock service or any third parties providing sock service or is the intention that the Orgs that you’d be working with would be providing that response themselves
Jack Naglieri (26:57):
Right. It’s the latter,
John Verry (26:59):
Any thoughts on that? Is that in the future for panther or you guys going to stay just on the non response side,
Jack Naglieri (27:08):
My intention today is to remain product company versus a services’ company. So, but you never know what will happen in the future. I mean, CrowdStrike famously like added their response service later, but initially they weren’t. So when it’s a bigger company who knows, if enough of our customers want it and we have the expertise to deliver on it, maybe we’ll change our mind. But I think today in the state of in the spirit of focus, it’s best to just be really good at one thing. And that’s kind of the idea that I like right now. It’s a better business model, I think as well,
John Verry (27:44):
I know that probably a large percentage of the data that you’re getting is coming from cloud-based sources based on what you’re doing. And I think you just mentioned that you do capture on-prem data. So is that, does that, , you mentioned EDR specifically, so you’re taking feeds from EDR. If folks want to feed in stuff from their corporate networks as well, that’s possible
Jack Naglieri (28:02):
Oh yeah. Absolutely.
John Verry (28:03):
Any breach anywhere.
Jack Naglieri (28:07):
The really powerful thing that we’ve built is if any company has custom internal data or they have data that we just don’t support yet, but it goes to an S3 bucket or a queue or something, you can connect that in into Panther and you can infer the schema of that data. And then at the other side of that, we, you end up getting is a data warehouse that a secure data warehouse with that data. So we’ll basically ETL the data transformer for you. And we’ll give you an ability to infer that schema pull out the indicators like domains, IPS, hashes, things like that you care about, that you want to pivot on, and you can write Python on it as it streams. So very powerful. And it applies to just generic data that you just have sitting in a bucket so that ETL can take teams years to get, to be honest, like it’s such a nontrivial thing to build and maintain over time to your point. Like for things that drift and air is just removing the Ops overhead for system like that is such a massive win.
John Verry (29:05):
So that’s almost like you’re sort of doing like auto, like in the old days, we’d call them agents. Do we have an agent that understands how to parse this particular data source? It’s almost as if you’re doing auto agent creation, right? You’re taking the data you are you’re. I mean, does that go down to the level of like one of the other challenges that you always have with different types of data sources, data normalization. When you say that you’re ETLing it. You’re automatically figuring out what type of data we’re having and are you able to normalize it as well? So port, like if we have this scheme that port a HDTP web, they all mean the same thing, right? I want to normalize that, or I have three different firewalls and one uses different terminologies for accepting, rejecting “ drop. And it’ll normalize that stuff automatically as well.
Jack Naglieri (29:47):
So normalization has a lot of different definitions. So there’s normalization where you’re saying normalize into the same format, because a lot of security logs exist, CSVs or JSONs or, or HTP style logs or whatever. So there’s a normalization that’s happening from there to there from raw log to structured log, which is more like parsing, like parse the log into its structure. And then there’s a normalization step after. The things that we normalize that we focus on today are really pulling out indicators in normalizing event times. And then in our rule engine, we actually have this mechanism of doing what you’re describing, which is I want to look at all like Deskport 22 traffic that X, Y, Z, like other thing I care about and I want to search across all of my logs. Like we have the ability to that in real time today. And then historically it’s a bit more around pivoting on indicators and things like that.
John Verry (30:41):
Oh, that’s cool. So that port 22 TCP 22, SSH all ends up being to you the same thing. And when I do my query, I’m going to get a return of all that information
Jack Naglieri (30:52):
Right. In the rules today and then on the data lake, it’s something that we’re unifying together now.
John Verry (30:58):
Excellent. And then yeah, I read you on your site. You did the state of SIEM 2021, but back to that word, and there was one finding that stood out to me, was that approximately 20% of companies said it took 12 months or more to deploy thoughts on that. And any other findings that in your state of SIEM that you thought were particularly interesting to you?
Jack Naglieri (31:22):
Yeah that one’s interesting. I think there’s always going to be a very long tail deployment. So I’d be really curious on like why teams would answer a certain way, like what is done to them is done. Like I got my critical data sources in and now we’re good. And now we have our detections or is done. Like it literally took that long to just get it viable, which is my assumption. And I can see why that happens in certain companies, especially when the infrastructures are so complex and you have to get a lot of sign off and approvals to deploy SIEMs. So in the world where I was racking servers or where I was like spinning up, all the necessary components that could certainly take months, it would not surprise me whatsoever. And when I made these changes at companies like Yahoo and Airbnb, it’s getting the blessing from the Ops team.
Because if you think about what you’re doing and it’s a response, it’s like, I need to deploy tools. That’s going to collect a lot of data, push it to a single place. I need to make sure there’s not going to be a bad performance hit on those servers that support the business. Because if that goes down because the security, then you have caused a lot of problems, right. Then you don’t have business to protect anymore. So it’s like, that’s the trade off that you make? I can’t necessarily recall any other specific finding in the report. I pull it up and we can talk through
John Verry (32:39):
I thought it was a really well done study to be honest. And the other thing too, that was always the problem is, even if we probably spent in some of our organization we worked with, we spent more time fighting with the sand team for space than we did actually trying to get things set up. Right, and who’s going to pay for all the storage. Right. So this idea taking 12 months. Yeah. So quick question for you. So, when, if I was a potential client of yours and I said, Hey, how long is this going to take to get this stood up? I would agree with you that a lot of organizations are not getting a lot of value out of the SIEMs for, four to 12 months. What would, what would be your typical ramp time for Panther.
Jack Naglieri (33:17):
I mean, you could get into the tool today, onboard data, and then you can get alerts on the built-in detections we’ve created. So it’s pretty much immediate. As soon as you can, can connect your data sources in we’ll start pulling data. It gets normalized. It gets put in the data like it gets run over the built-in detections we have, and then you can start to craft your own. You can write searches. It’s pretty immediate. There’s no other like, because it’s a server architecture, you just need us to stand up your account for you. And that’s basically it. So you can get going and get like, I would say savvy engineer, savvy security engineer, who who’s been doing monitoring for quite some time gets value right away from it.
John Verry (33:55):
Pretty cool. We beat this up. Pretty good. Anything we missed? Anything else that folks should know?
Jack Naglieri (33:59):
Well, you, so when you were mentioning the state of SIEM report, like the one thing you meant we could have talked about as well as cost, because that’s been a huge bottleneck.
John Verry (34:07):
Okay cool. Let’s touch on. let’s talk about that
Jack Naglieri (34:09):
Yeah. So I mean the economical reasons that people hate SIEMs are they’re expensive and they’re slow and they’re impractical, right?. So expensive and slow kind of get fixed at the same time when you have cloud native for a lot of reasons, because you’re becoming more efficient with processing, you’re sort of outsourcing certain things because it’s very expensive to just run servers. That’s just a constant thing that’s always on versus moving to the cloud. It becomes consumption based and that’s just more economical and more efficient. So there’s a byproduct whereby us designing things in an efficient way, we naturally have a lower overhead and we pass that down to our customers. So we come in at like, like a 50 to 70% discount of a typical SIEM at that same scale, actually at a much higher scale than was even viable before. So that’s a huge benefit for a platform like Panther. And it’s a huge reason why we want to build something cloud native. So, when you get those scale benefits, but also you get the lower cost benefits too.
John Verry (35:15):
When you use that 50 to 70%, is that versus conventional on pre SIEM or are we going to the more modern cloud-based SIEM world of the Splunk? So the AT& T cyber securities are something of that nature.
Jack Naglieri (35:29):
It’s just across the board of my opinion. I don’t think there’s a huge difference. Even if we compared like Elastic, Sumo, Splunk, you’re still paying to get a true production scale. You’re going to pay millions and millions of dollars for that to work. And then you probably still won’t get what you want out of it. That’s the most frustrating part.
John Verry (35:48):
Yep. And like you said, at that dollar level, that’s quite the cost savings to be able to do it at that, at that price point. Cool stuff. Well, thank you. This has been fun, question for you. I always ask, give me a fictional character. Oh, he’s smirking at me. I wonder he remembers that I put this into the agenda, Jack, we’re going to see how fast you can think on your feet. If you don’t remember this, that was, I asked this, okay, give me a fictional character or a real world person you think would make an amazing or horrible seat. So, and why
Jack Naglieri (36:21):
Fictional or real.or is that the fictional
John Verry (36:24):
Or real it could be you,
Jack Naglieri (36:26):
Oh my God.
Not prepared for this question.
I don’t know why, but like for some, for some reason, like Trump came to my head of like someone who’d be a horrible CISO. I don’t know.
John Verry (36:45):
I’m shocked. I am shocked. This is the 80th episode or 80 that’s the first time someone went Trump that’s the first time somebody went Trump. Right. So explain
Jack Naglieri (36:55):
Just someone boasting about,
John Verry (36:57):
Or does it not need explanation?
Jack Naglieri (36:59):
I don’t think you need explanation,
But
I just thought it would be hilarious. Like this is going to be the best tool ever.
John Verry (37:06):
It’s going to be huge.
Jack Naglieri (37:09):
We’re going to be great.
John Verry (37:10):
I’m going to protect you from China.
Jack Naglieri (37:10):
Oh my God.
John Verry (37:17):
You know what? Yeah, just for the record, we’re probably both under.. The Midwest is not happy with us, right? At this point, the Midwest and deep south are very unhappy with you, Jack. You must be one of them liberals from San Francisco.
Jack Naglieri (37:30):
I don’t what they expected.
John Verry (37:39):
That may have been the best answer that I’ve had. If folks wanted to get in touch with you, what would be the best way to do that
Jack Naglieri (37:46):
Panther.io
John Verry (37:48):
Or your Panther.io Cool.
Jack Naglieri (37:50):
Yep. Or @runpanther on Twitter at Jack Naglieri on Twitter. Yeah. I would put my email, but it’s not that hard to figure out.
John Verry (38:01):
There you go. Thank you Jack.
Jack Naglieri (38:03):
Thanks, John. This is super fun.
Announcer (38:07):
You’ve been listening to the virtual CISO podcast, as you probably figured out, we really enjoy information security. So if there’s a question we haven’t yet answered or you need some help, you can reach us at info at pivot point. So security.com and to ensure you never miss an episode, subscribe to the show in your favorite podcast player until next time, let’s be careful out there.
