Cut costs, increase storage with InTrust and SIEM integration

Welcome. This is Quest Unscripted. A v-log series on trending topics. And Quest solutions related to Active Directory. Office 365. Oh, and don't forget Azure AD. You are here because you have questions. We're here because we have answers. I think. We will address questions we've received from customers. Who experience the same challenges as you. All with the goal of helping you confidently move-- --manage-- --and secure-- --your Microsoft environment. We call the show Quest Unscripted, because-- Except for this intro-- Nothing we say is scripted or rehearsed. And we're pretty sure you'll notice that right away. Hello, guys. This is Ghazwan Khairi. I'm a strategic systems consultant with Quest Software. And I'm joined by two of my favorite consultants, one of them is about to smile. Here we go. Bryan Patton, principle systems consultant with Quest and Robert Tovar, a solutions architect with Quest. And we're going to be talking about interest. I get a lot of questions, guys. First question and last question, I get all the time is, hey, I have a SIEM solution or a SIEM solution, whichever way you want to call it. And you are telling me that InTrust kind of does the same thing. So your answers, please. Well, the first thing first is a SIEM is typically intended to be for security incident and bit management, not necessarily for retention. So when we're looking at our 20 to 1 compression ratio and our ability to [INAUDIBLE] either from Microsoft ecosystems, I think that's complementary to any SEM that you may have out there. We are also working with Sigma projects so we can identify which role it should be afforded to your SIEM for actual security, event analysis after something does occur. So that's one key point I usually focus on. Yeah, I agree. Just to add a little bit something to that is that with InTrust, with the 20 to 1 compression ratio that Bryan mentioned, we don't charge in any way, shape or form for the amount of data. So I have customers that are keeping their event data for up to 10 years. So it's unlimited storage, or data. Most of my customers collect all this information for security incidents, which typically originate on the workstation. But very few customers actually collect the logs from the workstation. There's the logs, logs for attacks originated via PowerShell. And due to the cost structure of most SIEM tools, it just becomes unaffordable to be able to do so. So to Rob's point, the best way to collect all those bits and scale out down to the workstation level, including PowerShell and SYSSPAWN is a huge value prop. All right, the next question, the leading question that usually comes-- you just said PowerShell. Response actions to something that may have happened through PowerShell or through ransomware or through accidental attack or what have you. So not sure which one of you guys will take this, but can you talk to us a little bit more about what kind of response actions we can do with InTrust? Well, I remember listening to a Darknet Diaries episode with Tinker, where he got caught because he was running PowerShell commands from an accounting department. So I'm thinking of the allow those capabilities, where we can state with an interest that only these different people can run any PowerShell. That can kind of give you a good awareness to what's going on. And the great thing about that is you don't have to collect the logs to be able to just allow that as an allow-less type action. Rob, is there anything you want? Yeah, I was going to add that with response actions-- so taking what Bryan just said, right, you're looking out for certain activity. And that's event data, right? What within the events are we looking out for? And then the response action is what are we going to do about it? What can we incorporate in that PowerShell script? We support other scripts, but the point is-- what can we do to react to that activity? So it can be something as simple as someone added a user to a group and we want to undo that. Or it can be more elaborate, just depending on what the script itself has within to run whatever processes or do whatever else you want it to do. So it's really that InTrust is looking out for the activity. That's the alerting part. And then it's the response action reacting to it. So whatever you can put together as far as a response action within a script is what we can launch. So it's not limited to something that InTrust itself can do. It's what's within the response action that you wrote. Now, we have a lot of them out of the box. But if you wanted to create your own, you could do so as well. Yeah. You know, Rob, both you and I got a question yesterday from a customer. Somehow, something got uninstalled. Agents of interest were uninstalled. And they're like, we don't really know who did that. So the next logical question would be, does InTrust audit itself? Can it audit Itself? Can it tell you who at least stopped the service in case there was harm that was done? Yeah, so there's two parts to that answer for me. First of all, InTrust can or does use an agent. But it doesn't necessarily have to use an agent. So even if you decided not to run the agent, we could still pick up the event logs and see the activity. But as far as InTrust auditing itself, it does. So if someone were to use for example our Management Console to uninstall the agents, we could see exactly who did it, when they did it. And so InTrust has a way of auditing itself so that it can provide those details. But once again, it doesn't necessarily have to