Name: On Demand: April Product Launch Announcement, LogRhythm SIEM
Uploaded: 2026-04-07T17:32:30.873Z
Duration: 41 min
Description: On Demand: April Product Launch Announcement, LogRhythm SIEM

Transcript for "On Demand: April Product Launch Announcement, LogRhythm SIEM": Alright. Hello, everybody, and welcome, to our webinar. Thank you for joining us today. My name is Ryan Gamboa. I'm a senior product manager here at Exabeam. And today, I have, Sofia Stillings, our amazing enablement manager. She's joining me, and she'll, speak at the end here a little bit. So just a just a quick look at our agenda, if I can change slides. I did intros already. I'm I'm ahead of myself. So moving on to our agenda here. You all know the drill. This isn't the first quarter we do we've done this. We do this every single quarter. So we'll start off with a brief review of our our portfolio. We'll take a quick look at our promises that we've made and how we've delivered on those recently, and then we'll jump into the real meat of the webinar, which is new features in 07/24. That'll include some slides before we jump into a demo, and and then I'll pass it over to Sofia, who will give us a brief overview of our partner enablement program, Sherpa, and how it enables our partners, and then we'll have some time for some some q and a. So there is a questions function there that you can, post your questions. So we'll we'll keep an eye on those, Probably save, those for the end, the actual q and a slides, but feel free to throw them in there, and and we'll get to them, in the q and a section. So a a quick look at our Exabeam portfolio. We offer SaaS through our NuScale product, our NuScale offering. This includes a SIEM offering as well as a analytics offering and fusion, which, brings both of those together. You get SIM and analytics. Then, in the blue, we've got our on prem offering, LogRhythm. You all know this, intimately. It needs no explanation, But I will call out that we also have an option for logarithm intelligence. This is our hybrid model that allows you to take advantage of NuScale's AI driven analytics and, bring all that into to your on prem SIM. And, of course, we have Netmon. Netmon is, kinda sits in the middle there between the two, and you can send, data to, either NuScale as well as LogRhythm, and it integrates with both. But that is the the portfolio portfolio. So very brief. There you go. This isn't a a sales call, so, not not trying to to, dig into these any further. I just really wanted to map things out, level set here so we all know what we're talking about in case you hear any of these, these product names. If you do have have questions, though, and and are interested, please don't hesitate to reach out to your rep. But this now completes your training. Certificates are in the mail. You're you're up to speed on the logarithm port or Exabeam portfolio. I keep saying logarithm. I don't know if that's ever gonna get out of me. Alright. So many of you have seen a lot of news about our poor product portfolio. You've you've heard questions or sorry. We have heard questions from many of you. Questions like, what is the future of the on prem platform? So I I wanna address this head on because our message is is very simple. We're committed to the continued innovation, the continued investment, and development of the logarithm SIN. It's a vital and strategic part of our mission. We are, again, dedicated to ensuring that it not only meets your needs today, but, that it grows with you in the future. So that's our promise to you. And over the past year, you can see the investments that we've made in delivering on this these promises. So, we've been focused on modernizing the foundation and improving the customer experience. We, are continuously improving our abilities to collect and understand, security data, and we are investing in, the continued improvements to the over 1,000 products that we currently support today as well as adding support for other products. We've also done a huge number of updates to the back end of the platform in the past year. These updates have resulted in, you know, significant improvements to the performance of the the system as well as the user experience. So we've we've added key capabilities with the ultra warm data tier in our January release. We've also added, the new data indexer dashboards, radically expanding the amount of data that we can search and visualize, for analysts, which is a a huge milestone for us. It not only removed a a long limitation with our dashboards, but it it sets us up, for a very exciting future. If you're still running older versions, you're missing out on some some great improvements here, so I highly recommend getting to the current release. And speaking of the current release, let's walk through some powerful new capabilities, in 07/24. We're gonna focus on the administrators first, and then we'll jump into the security analysts. So, our first feature, one of the most consistent pieces of feedback that we've received from our customers is the need to manage analytics rules programmatically. Imagine you've got hundreds or even thousands of AIE rules, a new threat emerges, and you need to adjust some thresholds or suppressions on dozens of them. Doing that manually, clicking through window after window in the console, it's slow. It's it's tedious. It's prone to human error, and it it just doesn't scale. So that's why we've had a major focus on expanding our, API capabilities. In 07/24, we are delivering significant and long awaited updates to the the AIE admin API. This release represents the the next crucial step in our journey, towards automating at scale. We've we've introduced two new endpoints that finally allow teams to embrace, a rules as code methodology. We've added a git endpoint so you can programmatically list and query any rule, and its properties. And, critically, we've added a patch endpoint that allows you to modify the configuration of those rules. You can now script changes to nearly every property on an AIE rule from its name to its risk rating and suppression settings. The one piece that I'll call out that you can't change via API just yet is the the core rule block logic itself. But, don't worry. That's on our road map for for, an upcoming quarter, so we'll we're getting to that. And we we really wanna make sure, again, we've got full, program I I can't speak. The ability to programmatically update AIE rules at at every level of the rule. So, yeah, even without that, what this update does is it unlocks the ability for you to automate your AIE rule management today. It means you can ensure consistency across your entire deployment. You can dramatically reduce the hours spent on manual tasks and build powerful, scalable integrations with your other security orchestration platforms. Automating your analytics is vital, but just as important is ensuring that the data coming into the system is protected as well. So we want or we know that many of you use modern data routing tools like Cribble or Databond, to get logs into the SIEM. But, many of you have rightly pointed out that there's a a security gap in our initial MVP launch of of that, feature, which is the connection to ingest that data wasn't natively natively encrypted. So this forced some complex, often brittle workarounds, and, of course, it's it's a headache for compliance as well as, audits. So in 07/24, we're closing that gap for good. We now have a security or a secure JSON listener. No more workarounds. It's built in to the system monitor agent. We now have native SSL TLS encryption for these connections. So the value here is pretty straightforward. Peace of mind, simplified compliance. You can now stream data from your, entire tool chain with the confidence that it's encrypted in transit. We've talked about, making it easier to manage your rules, making it, more secure to get your data in, But let's let's talk about the speed of getting data back out of the system. Imagine many of you have been here. We've had a major incident. There's an investigation or a formal audit. You need to reach, into the SIEM. You need to search and find some specific information against six months of data from your archives. Right? It's no longer in the data indexer. In the past, this process, it was painfully slow as the system reprocessed, reindexed the the matching data to to your search. It could it could take days, even weeks, and that's a delay no security team can afford. We knew we had to improve this, which is why I'm I am super excited to announce a a complete overhaul of the second look API. We have replaced the old dot net four back end with the much more performance dot net eight framework, and we've added parallel processing. The outcome of all this work and what it means to you, a nine x performance improvement. We are consistently, clocking restoration speeds at up to a 150,000 messages per second. Just putting that into perspective, a restoration that may have taken you entire an entire week can now be done in hours, or a job that took hours can now be done in minutes. It makes this large scale data retrieval faster and dramatically more reliable and gives you the data you need when you need it. So really, really big improvement there. Alright. Now let's shift a little bit and focus on the security analysts, those on our front lines, the people using the same every day to hunt and investigate. The first thing I want to share here is metric widget, an update that adds a count distinct function. When you're investigating an alert, the total number of logs isn't always the right metric. Sometimes it's just noise. Sometimes you you want to understand, and answer some more actionable questions, which are, maybe about the the blast radius. Right? How many unique user accounts were there, or how many distinct endpoints were there? Which of the servers made contact with this specific domain? Historically, answering those questions meant that the analysts had to stop their investigation, export a huge chunk of that data to a CVS or CSV, and then, you know, pivot to another tool to manually count those, unique entries. So it was slow, really cumbersome, and it it breaks concentration and and the workflow. So with seven twenty four, we've we've eliminated the need to do that. The metric widget now includes a native count distinct function, that lets analysts quantify scope in seconds within their dashboards. You can now instantly get account of unique users, hosts, IPs, or any other schema field, that's available on the dashboards. It's a simple but powerful improvement that gives analysts a a much clearer picture of an incident. And while count distinct gives analysts the scope of an incident, the very next question, that you you may want to ask is is about context. You want to understand the what and the why behind that alert. When viewing AIE detections from a DX dashboard, in 07/23, you may have noticed that some important context was missing. The system wasn't sending internal, or it wasn't sending human readable information to the DX. It was sending these internal numeric IDs. Things like rule classifications weren't a human readable form. It was this ID. So this forced analysts to stop cross, stop cross reference the ID and try to remember, you know, what it meant, which is absolutely painful and a a terrible user experience. It's, it's a lot of wasted time. So in this release, we, we've updated AIE events, so that when they are sent to the data indexer, we enrich them with the readable names that provide immediate meaning. Your analysts no longer need, to look at these generic IDs and figure out what they are. They can see that full classification name, like external host Bruce Forks login. And and because it's real data, it is it's completely searchable, filterable, and allows you to build more powerful dashboard widgets. So just a much more seamless, intuitive workflow, to help teams understand and prioritize threats. Alright. So last one, before we jump into a demo is the search by unique logs ID. At this point in your investigation, your analyst has a better understanding of scope. They have the enriched AIE data, but that that final piece is maybe a a, precision, search on a specific piece of evidence and pull that back instantly. If you're looking at a specific log and maybe you want to escalate or, take it to another tool, right, you wanna share that information, you have to build a pretty wide search today, with a pretty wide, time range or keywords, which returns, you know, potentially hundreds or thousands of results, that you manually have to sift through. It's pretty hard to provide a a specific log to another analyst. So in 07/24, we've added the ability to really find that needle in a haystack. We are introducing a a search function to search by a unique log ID. The unique log ID, which is a a GUID assigned to every log that comes into the system, is now visible, in a column inside of the log grid. More importantly, it's fully searchable in the UI and accessible via the API. So that allows your analyst to take a log ID from anywhere and retrieve it or share that log ID with with someone else, creating a nice little shortcut. And I wanna end on, the strategic importance of this feature because it's it's more than just a convenience, but it's it's about a critical piece of the the workflow and the future for analysts. Our long term vision for for this, for every AIE rule, is to automatically record the specific log IDs that generated the AIE events, right, the the logs that triggered these detections. And when that work, is complete, when we can track that through AIE, we can update the drill down for, for AIE alerts. It will give us an an instant direct query for those exact logs, as evidence for those detections. And it'll be a 100 accurate every single time, and replace a much more cumbersome, AIE drill down function that we have today that's, not always as, reliant. So with that, I wanna jump over to demos, get out of our, SlideWare here. One sec while I move over. Okay. So gonna spend most of our time here on the dashboard and show off some of those analyst functions. We previously I have I have too many widgets here, so I can't show you my add function. But we we added the metric widget here on the DX dashboards. Right? I can click and drag that in. I already have one sort of created, but my my goal here is to show, you know, how many unique detections have I seen maybe over the last, couple days. Let's let's expand this one here. If I just look at all my AID detections in the last, maybe fourteen days, you can see I have a whole bunch of them. Right? And it'll it'll tell me how many of each I've had. But maybe I just wanna know how many detections have triggered at all in the last day, or, in this case, the last, two weeks. I wanna count of each of the rules, you know, the toll, total unique detections that have triggered. Right? So, rather than telling me, individually the count how many times this one went, I just want you to count each one of these and say, hey. We saw seven different AIE rules trigger in the last two weeks or or whatever it is. So we now have that ability. If I go over to configure widget for for this guy, I've already got it set up to, group on common event, which is, an easy way to filter on AIE rules. I can say where my common event is AIE star. Right? Because it is starting with AIE, so I can filter on that. So in the last seven days, let's let's make it in line with our other widget at fourteen days. We've had 627 firings of, any AIU rule. So that should count up each of these individual bar graphs. But now I just wanna count the individual distinct rules. So I can change from a, you know, count total to account distinct, and it'll tell me, hey. 12 different AIE rules have fired in the last fourteen days. So super powerful metric. Again, you could you could do this with IP addresses. Right? Tell me how many different IP addresses, if I if I switch this to IP. Let's do impacted maybe. No. Let's do origin. So zero in this case. These are probably not parsing any any IP addresses, but but you could you know, if you're grouping by an IP address or grouping by, usernames, you could understand how many different users are involved with a a specific rule. Or you can just do a general, you know what? I'm I'm not interested in AIE rules, but just tell me, I don't know, how many IP addresses have we seen in my environment over the last fourteen days. So, a very powerful tool. And then, jumping over to the IP I'm sorry. The the IDs the log IDs. So maybe, if we view logs on these IPs here, I'm gonna jump over to the log tab. There is a column for log ID. This is that unique GUID for every single, oops, every single log, again, that's being indexed into the the data indexer. So I could I could easily copy this and share this ID with someone. Obviously, I could add it to a case. But if I copy it, I can now come up to search, and there's this new log ID field. Oops. Click happy. And I can add that to a search. Right? So I can pull back just this log ID. I think I need to go back maybe a little further. So just make sure I'd I actually get this. We'll make a nice big time window, but I can search back on that log ID. It's gonna go find that exact log for me. And you can kinda see how this, in the future would pivot to something like an AIE rule. Right? I've got an AIE rule. I want to do a quick drill down on it. So allow me to click this widget, click drill down on an AIE rule, and pull back every single log associated with that AIE rule. I did mention that the the log ID is is available here in search, but it's also available inside of our APIs. So if you, run a search, you can you can also filter by this this ID. You can, find it within search results. So it's it's in the body of results and, is also a parameter that you can you can search by. And then, the the last thing that I want to show here is our AIE, API. So new, we we had the ability to get rule status. Right? Tell me if the rule is enabled or disabled. But now I can go out and actually get a a rule. So, in this case, I'm I'm just saying, hey. Give me all the rules associated with the AI engine server with ID one. So this this gives me every single rule. Right? But I can also be specific and and get a a rule by ID. But you can see in here that we now allow you to update let me scroll a little slower. We've got things like updating common event, the classification. We've got suppression, the rule set. So lot of lot of good things in here that that we can update. And then, what you'll see in the future when we when we get to rule blocks is a a rule block, key value pair with, you know, basically, a grouping that allows you to to modify each of the different rule blocks within a rules individual rule. So, yeah, that covers our our demo and updates for 07/24. Let's take a quick peek, make sure we don't have any updates here. Okay. So question, about NetMon. Yeah. We haven't we haven't talked about NetMon here, but that is actually gonna be released in the next week. We'll have an update to, NetMon. The big thing this quarter will be a update to Elasticsearch. It was on an older version. It it will now be on the same version that the logarithm SIM is on, which sets us up for the move to OpenSearch. So a lot of work went into that just to make sure we we could, support the newer versions. But, that'll be out this, in the next week or so. Going forward with net net NetMon for for the road map, you know, I mentioned a move to OpenSearch, so that's that's on our list. We plan to also add some additional capabilities to the the, dashboards to extend the time frames that you can search on, and some other, big, foundational, like, security things that we've been working on there. But, yeah, if you're you're interested in more about NetMon, we can we can certainly get you set up with, maybe a rep to to go into a little more of a deep dive there. Alright. So if you have questions, please drop them in there. Okay. Here's one. The nine x performance boost on second look, does this require any new hardware? Is it purely a software update? It is a software update, but, the the speeds that we're getting is is on dedicated hardware. Right? So if you stand up a second look box and allow that to to be your processing engine, that's that's how we're getting speeds there. So there's there's actually information on the doc site on setting up a a server specifically for this and and what the requirements are. So that was what we used as our our baseline. Still, even if you don't have a dedicated box, you're still gonna see a lot lot better performance from it. But, yeah, just just a heads up, you're you will get better performance if you have something dedicated to it. Okay. The ability to search by the unique log ID is great. You mentioned it was foundational for future AI drill downs. Can you elaborate a bit more on what the future experience will look like? I wonder if this came up during while I was talking to it. I I think I addressed this, but I'll I'll just reiterate. Yeah. We we planned, we planned for AIE to track these log IDs, right, and and store them with any detection. So when a detection is made, we store an array of log IDs for the logs that triggered that AIE rule. And then when you wanna do a drill down, all we have to do is call that array of IDs and go fetch those logs As long as they haven't, you know, been removed from the DX due to, TTL settings, they they would still be available for you to search. It's great to see we can modify rule properties via the API. Is there a time line for when we expect to be able to manage the the AIE rule logic, those those blocks in the API as well? That is actually in flight currently. Our target is to deliver that in our next release 07/25. Alright. Okay. Question about, improvements to second if if there are improvements to second look, I assume this may have, come earlier, but has there been improvements to Elasticsearch? Says they're on an older version. So, in short, no changes since 07/18. That's when we jumped to the latest version of Elastic. Excuse me. We, we are sitting there, as we plan to move to OpenSearch. So Elastic, we are on the last version of the the free open source version of Elastic. And we don't want to, incur any more licensing costs that we, you know, would have to pass down to customers. We wanna stay on open source. So we are planning a move to open search, later this year. That's also in flight. I don't have a specific release that that will be available, but, that work has has started. So, as soon as we make that move to OpenSearch, we'll see some improvements on on that end. Alright. With that, I'm gonna I think I got most of them, but I'll keep an eye on the chat. I'll hand it over to Sofia. And, if there are any other questions, please, drop them in there. We can we can circle back on q and a here after Sofia's done. Alright. Over to you, Sofia. Hi, everyone. I am my name is Sofia. I am an enablement manager here at Exabeam. I just wanted to quickly introduce a new initiative we're rolling out that is going to directly support our partners to sell and deliver Exabeam and ultimately how customers like you experience Exabeam in the field. We call this Exabeam Sherpa. You can think of it as a virtual channel account manager. It's going to always be available, embedded directly into how our partners learn, practice, and are engaging with customers. The goal here is pretty simple. We wanna make sure that every ExoVien partner is confident, capable, and consistent when they're working with you. Traditionally, partner enablement has been very activity based, things like certifications that are completed, portals that are logged into, or courses that have been taken. The challenge has been that we found that those metrics don't always translate into better customer conversations, stronger discovery, or successful deployments. Partners also often end up with a lot of content, but not enough hands on support to actually execute, especially on complex security cases. The gap shows up downstream as slower deals, misaligned expectations, and consistent customer experience. What we're focused with with Sherpa is to close that gap, raising partner competency, not just activity. So outcomes improved on both sides. So this is where Exaviem Sherpa comes in. Sherpa is an AI powered enablement platform designed to partners move faster, but more importantly, sell and deliver smarter. It combines onboarding, training, coaching, and real world practice into one experience that's tailored by role, whether that's sales or technical. Partners can practice discovery, demos, object objective handling using realistic role play, and they're even able to upload demos, demo recordings, or bring Sherpa into real world conversations to get feedback, and follow-up recommendations. This results in partner teams being better prepared before they even engage with customers, and you guys get a more consistent, higher quality experience as a result. So here is our outlook onto XBeam Sherpa's q two road map, focusing on scaling this globally and tying enablement directly to pipeline and performance. This includes structured demo readiness where partners don't just learn how to demo, but they practice it, get coached on it, and master it before going live. We're also integrating smart prospecting support so training can turn directly into action. Learning something and then immediately applying it to the right customers, as well as real time coaching during customer conversations is another key investment of this platform, as well as continuous education so partners stay current as our platforms continue to evolve. And then finally, we're going to be rolling out language localization to ensure partners can engage customers effectively across all regions and markets. All of this is designed to make partner interactions smoother, more informed, and more successful for partners like you guys moving forward. With that, I will pass it back over to Ryan, and he will close us out. Great. Thanks, Sofia. One other question I wanted to address before we close things out. There was a question about upgrading to seven twenty four and not seeing the log ID field. It was it was empty. So the question was, you know, is there any additional configuration required? No. There there's no configuration required. It should just, just populate. The mediator, is set to to do that always. And I believe that started in 07/20, if I if I have that, version right. But one of the reasons you might not see the ID populated is, that it's coming from AIE. So that's a that's a really good call out. The, the function to index AIE rules over to the DX is fairly new, and, it does not yet, log a log ID. So AIE will insert a new, detection into the d x, but that field will be blank. So that's something we're we're adding as well. It'll come, less important for, like, drill downs on AIE rules. But, yeah, share sharing that exact log, would would be difficult without it. You can't, but, it will it will definitely come. So heads up on that. If you're not seeing log IDs in for for other regular logs, Maybe open a support case, and and, have have someone look a little further into that. Alright. I don't see any other questions. But if you have them, you know where to find me. Happy to happy to answer more questions. Also, you can reach out to your reps. I just wanna end with a small plug. If you are interested in in learning more about UEBA, please check out this this white paper here. But we also have a webinar for, the the NuScale product as well. So you can check that out if if you're interested. We can drop a link for, signing up for that as well. So, yeah, just again, thank you so much. Oh, here's the here's the QR code for anyone that wants to join the April launch webcast for NuScale. But, again, thank you so much for joining. We really appreciate your time. We know you're busy. Go check out seven twenty four, and happy happy logarithming. Thanks, everyone.