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 have the agent. It can run without. 99% of our customers do like the agent because of the additional capabilities that it provides, like alerting, the response actions we just talked about, the compression ratio that we've talked about. It's a 20 to 1 compression ratio at the server. In other words, the server that's producing the events. 20 to 1 compression ratio there, 20 to 1 compression ratio at the final destination. So there's caching capability. So for example, if there was an issue with the agent-- so let's put the stopping of the agent to the side. But let's say there was an issue. The agent itself would continue to function, continue to audit. It would cache those events. And once it reestablished a connection, it would forward the events to the InTrust server. So there's a lot of ways to mitigate that risk of losing an agent, or having an agent service stopped, or things like that. But InTrust does have the capability of having eyes in all directions. Yeah, I just want to point out-- InTrust also has the capability of collecting logs, even on machines that may not be actively on the network. More and more organizations are doing like Azure AD, only joint computers. And we do have the ability to collect logs from those computer objects as well. Yeah, obviously, plus on-prem Windows and non-Windows-- Yeah. --endpoints as well. Here's the question that we often like to get asked, but-- and we do get asked every now and then. But we love to answer, I know. So here's the question. InTrust and Change Auditor together. Why better together? Well, I'll start. So InTrust relies on native event logs, Change Auditor does not. In some cases, some organizations will need to provide native event logs, whether it's for compliance reasons or other reasons. So InTrust provides that for you. Change Auditor, on the other hand, does not rely on those native event logs. And it produces its own. So the differences there is one's producing them, one's collecting them. One's producing events, one's collecting events. But when you marry those together, now you have a way to meet those requirements with a native EVT format logs that you need to keep. And there's details in there that's good information. But you also have the ability with Change Auditor to get the additional details that you would normally not get with native event logs. There's additional functionality. So when you put the protection feature in Change Auditor, and you marry it with the response actions in InTrust, and then you add the compression ratio so we can store all this data, it just makes it a better world to be in when it comes to auditing and securing the environment. Well, Bryan, before you say what you want to say, because I know you had something to say. Speaking of marrying and it's better together-- Bryan, from your customer base, your customers who have interest in Change Auditor, can you say they are better secure, they've got their process in place and a much better format than those who don't own both solutions together from your own experience with your customer base? I think three would collect a lot more data or data to get a more holistic approach as to what is going on when you couple InTrust with Change Auditor together. So it gives you a better visibility to everything in your Microsoft ecosystem versus just one component. Yeah. Especially, also, that-- I'm not sure if you mentioned IT Security Search or not. When I go to IT Security Search, which is basically free with either Change Auditor or InTrust, and I search for say Bryan Patton, I'm getting all the events that were produced or collected, like Rob Tovar put it, about Bryan Patton on one screen. And I'm able to make a better story and track, whether I'm looking at it from a forensic standpoint or from an operational standpoint. I'm able to better track with a better story from that one screen. But both these data sources need to be there for me to be able to do that. Yeah, I know with containment, it's always a big thing after a thing does happen. Maybe it was my account that was breached. And you want to quickly identify everywhere my account has been associated. We'll easily have that ability with all different data sources Change Auditor has done. But let's say there was PowerShell being executed in the context of my account on a workstation. That would come up in that interface for you as well. Yeah. Cool. Well, before we wrap it up, anything else any of you guys want to say? I'm good. Thanks for listening. All right. Talk to you guys later. Take it easy, guys. [MUSIC PLAYING]