Cut costs, increase storage with InTrust and SIEM integration

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 whom is about to smile. Here we go. Bryan Patton is a principles systems consultants with Quest and Robert Tovar, solutions architect with Quest. And we're going to be talking about INtrust. I get a lot of questions, guys. First question and last question I get all the time is, hey, I have a SIM solution or a SIM solution, which ever 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 SIM is typically intended to be for security incident and bit management, not necessarily for retention. So when we're looking at our 21 compression ratio and our ability to search for either from Microsoft ecosystems, I think that's complementary to any SIM that you may have out there. We are also working with [INAUDIBLE] projects, so we can identify which role of them should be forwarded to your SIM for actual security, a bit analysis after this thing 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, the 21 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, they kind of collect all this information for security incidents. Well, it's typically, originating on the workstation, but very few customers actually collect the logs from the workstation. There's the logs. Logs for a tax originally would be a PowerShell, and due to the cost structure of most SIM tools, it just becomes unaffordable to be able to do so. So Rob's point, the best way to collect all those sort of bits and scale out down to the workstation level, including PowerShell and [INAUDIBLE], 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 I'm not sure which one of you guys we'll 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 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-less capabilities where we can state with an INtrust 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 action-- so taking what Bryan just said, you're looking out for certain activity, and that's event data. 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, from 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, you can 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. You can run without. 99% of our customers do like the agent because of the additional capabilities that it provides, like alerting, the response options 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 agents 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 the 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. 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 [INAUDIBLE] 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 endpoints as well. Here's the question that we often like to get asked 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 is producing them, and one is collecting them. One is producing events. One is collecting events. But when you marry those together, now you have a way to meet those requirements with the native EBP 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 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 INtrust and Change Auditor, can you say they are better secure, they've got their process in place in a much better format than those who don't own both solutions together from your own experience with your customer base? I think they would have clocked a lot more 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. 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 all in 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 this thing does happen. Maybe it was my account that was breached, and you want to quickly identify everywhere my account has been associated will easily have that ability with all different data sources Change Auditor is done, but let's say there was PowerShell being executed in the context 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. Later, you guys.