- Use Cases
IT and Infrastructure
Become an Axonian
Federal News Network (FNN): Let's talk about enforcement. In the engineering world, universities teach basic engineering courses and then applied engineering courses. We wouldn't have any bridges unless you had applied engineering. You have said that Axonius can give good assessment of a system and help with compliance. Well, what happens if something noncompliance is discovered?
Nathan Burke (NB): I love this kind of question, because at my last company, we were about incident response automation. So anytime I can talk about incident response, I'm excited.
When you think about it, let's say that an alert comes into the SOC. That's when the clock starts ticking and every incident response team is focused on metrics like meantime to detection, decreasing dwell time, and the total time from alert to remediation, but the hard part is context.
Imagine you're a cyber analyst and you get an alert about a system that could be compromised. You immediately start asking questions to inform that investigation. You might just have something like an IP address and basic info on an IOC. So you start asking
It's all these questions that you need answers to. But all of this data lives in different silos and it's difficult to get to. Instead of having all of that data in the right place, all at once, there's just a ton of manual effort. That really increases the time that you're spending on something that you want to get done quickly.
That's exactly where Axonius can help — instead of logging into 50 different data sources, Axonius customers can simply paste that IP address into the search bar, click the device, and then they can see everything that's known about it. Customers see things like all of the hardware information installed software, patch level known vulnerabilities, open ports, logged in users, security solution coverage. So I think the incident response is one of the most valuable use cases for Axonius customers.
It takes something that's entirely time sensitive and manual, and reduces that time from hours to minutes and seconds.
Instead of logging into 50 different data sources, Axonius customers can simply paste that IP address into the search bar, click the device, and then they can see everything that's known about it.
— Nathan Burke, CMO at Axonius
FNN: When you look at systems administrators and the federal government, there's changes but then there's changes that matter. Some system administrators will run a sandbox area for application updates test there before they apply it.
This is for the expected system changes. The problem arises when you look at unexpected changes that matter. How can Axonius help when you have more than just these silly little updates?
NB: I think you hit the nail on the head when talking about change and it's constant. And is it meaningful change or is it change that requires action? We're constantly talking about this huge increase in the pace and the rate of change in our environments and things like cloud workloads that can be spun up and down in minutes or ephemeral devices that only exist for a short time. It's just a new world.
If you think back five or ten years ago when the term alert fatigue was everywhere. There's so many examples where we were just constantly hearing the alarm bells go off and need to figure out what's noise and what actually requires our attention and action. I think the only way to understand whether a change matters and requires action is to first have that baseline for what's normal.
If you know exactly what you have – the users, the accounts, the security controls – that's your norm. Once you have that normal, you're able to detect any change that deviates from what you'd expect. I think that's probably kind of academic. Let me get a little more specific and examples.
Most organizations have something to protect their endpoints, like an EDR tool. That agent lives on every laptop and desktop, and it looks for things like malware or other threats. Pretty straight forward. If we expect every Windows machine to have that EDR agent installed, we can try to make sure every Windows machine indeed does have that agent installed by looking at the agent console.
But then let's throw a wrench into this. When I go into that agent console and ask, “Is the agent deployed?”, the answer is binary. It's either yes or no.
But what about those machines where it's installed, but not running? It could be that the user thinks, “That agent's slowing down my machine. I don't want it there”, and just stops it from running. Or maybe there's malware that shut it down, and it's able to evade that agent. Those are those changes that matter. Because although the console tells me that it's installed, it doesn't know that it's not actually working.
That's why our approach works because Axonius is able to gather data from multiple sources and a customer can create a query that says, “tell me anytime there's a machine that has an agent installed, but hasn't transmitted any data to the admin console. And the machine has been seen by another source within three days.”
That way you're using the data from all of these other sources to make sure that it's not off or make sure that it's seen by other tools, even though that thing is installed. I think it's all about really being able to identify those changes that matter, that need action, ruling out the noise and then mapping it to action.
I think the only way to understand whether a change matters and requires action is to first have that baseline for what's normal.
— Nathan Burke, CMO at Axonius
FNN: Earlier you mentioned a clipboard, I had this image of you in a data center with a clipboard running around from server to server and wearing out a pair of shoes in one day. And it's impossible to do. Some people say that automation is the solution, but you've heard horror stories about automation gone wrong and so have I. How does Axonius approach automated action?
NB: I think that's exactly right. There are prerequisites for trusting automation, right? Our approach is simple: Based on any query, customers are able to define whatever automated actions they see fit. There's a spectrum from the most simple, like sending an alert or an email or a Slack message to the more active, like installing software or isolating a machine.
A few other examples:
Maybe you want to add those to the next scheduled scan. I think that's a good example of something high value, low risk. It's a no brainer to automate that.
Why not create a new entry or update the existing one automatically again, pretty, fairly low risk. Removes manual work. I'd say, go for it.
Maybe you want to automatically deploy it or maybe you don't, maybe you just want to create a ticket and let a person handle it.
If you're talking about something a little more extreme, like enabling or disabling a user or a device in Active Directory. If it's all or nothing, maybe that's way too much for me to trust the automation, the risk of something going wrong is too great.
That's the approach we take. The idea is different customers want to automate different things and we don't force them to choose. A nuclear power plant is different from a retailer and different from a federal agency. A lot of our customers already have either a source solution or some kind of intricate playbook on what exactly should happen. So in that case, they can just hand it off to another tool. So that's exactly what our approach is.
41 Madison Avenue, 37th Floor
New York, NY 10010