Great Security Demands Great IT: Why Automox’s CISO is Customer #1

Episode Summary

In this episode of CISO IT, Jason Kikta discusses the importance of using Automox to improve both IT and security posture. He emphasizes that good security begins with good IT and highlights the value of consistency in implementation and execution. Jason also talks about the need to focus on average exposure times and tailor risk management based on the roles and functions of different machines. He concludes by emphasizing the importance of patching as a way to mitigate risk and ensure business operations run smoothly.

Episode Transcript

Hello and welcome to the Automox CISO IT podcast. I'm your host, Jason Kikta. It's great to have you back again. You know, I found out last week that we're up over 25,000 subscribers now, which is really incredible considering that we haven't been on the air that long. So,  I just wanted to start off by saying how amazing that is and meaningful. It really means a lot that people find our podcasts

interesting or, at least amusing. I think, my, my, my eight-year-old daughter likes to, to look up the podcasts on, on YouTube and then play them on the family room TV and then critique my performance. And by critique, mostly mean, laugh at me and, and point out that I'm bald. So, she's, she's, enjoying it if no one else is, but,

This month, we're doing something a little bit different. We're doing a sort of retrospective across many of our podcasts talking about how we use Automox here at Automox. So, you know, we're not just producing the product, like we're customers ourselves. And as the CISO here at Automox owning, having ownership of the IT and security

department and being responsible for the for those teams. You know, I'm I often joke that I'm customer number one. And and first in line to, as I say, drink my own or eat my own dog food, and then the head of engineering has the the much better phrase of drink our own champagne. But you know, it's, it's been a really interesting journey here, the last two years

learning about not just learning about the product, but but you know, using the product in new and novel ways to better improve both the IT posture and the security posture of our network here at automarks. And I think that's probably the first thing that I want to cover today. And it's

something I sometimes talk about in security talks, but it's not always an obvious thing. And it's, it's obvious when you hear it, but people don't tend to think in these terms. And that is really fantastic security begins with really good IT because security is about identifying anomalies and investigating them. Then, you know, dealing with them, if it turns out that it's, it's, you know, real or

maybe trying to tune it out if it turns out that it's a false positive. And it's very hard to do if you don't have a sense of normalcy in your network. If you don't know what normal looks like, then that becomes very challenging. Just the same, know, IT practitioners crave the very same thing. When I was running IT networks for the Marine Corps, you know, I wanted them to be as stable

and reliable and predictable as possible because that made life better for my users. It made things easier for my help desk, saved my engineers a lot of time. So being able to, you know, get that level of stability and predictability repeatability, was just foundational to the work that we did. And

what I've always liked about using Automox because that high level of automation has made my life very easy here to where I could, you know, as I've said so many times before, designate a policy to say, "Hey, I want these critical patches knocked out by the end of the week or the end of the day," you know, and having set policy and it really, I should probably distinguish having set policies

critical CVEs, high, mediums, lows, functionality patches that don't have CVEs associated. But then also being able to differentiate from those, or really not even differentiate so much as deviate from those set standards to say, "Hey, this is a really critical patch, and I want everyone to be patched by the end of the day. I want everyone patched

by 6 PM Eastern," or whatever it is. And I will take the hit if there is a business disruption. so being able to.

bend off of that baseline and adjust to circumstances as they come at you are really important. Likewise, when you have automation, when you know when things are supposed to run and they're running on a set schedule and you know roughly what your deferral window is, then you can make assessments and look at things like, you know, your mean time to remediate

you know, number of outstanding patches by category and, you can sort of build out and explore the data to make those critical determinations of, Hey, are we getting better? Worse? we on a plateau? And if I want to, you know, try to change something of being more aggressive with a policy or,

maybe even educating the users, establishing a new policy, deploying a new piece of software. Is that changing things? And is it changing things? Is the trend going in the direction that I want it to, whether it's up or down? Am I getting the results that I expect? And so it goes back to that, that core

core concept of consistency, right? If I'm consistent, I have consistent implementation and execution. I have consistent metrics. Now I can start to fiddle with the system and configure things the way I want it to be or experiment with different mechanisms and see if it produces

better efficiency or faster outcomes or, or, better overall performance, whatever it is I desire. But you know, if you can't hit, if you don't have a consistent target going into that, then it's a very difficult to know whether or not what you did is successful. may seem like it logically like it'll be successful, but you know, you're essentially going based on vibes at that point, which, is, is better than nothing.

But it's not not optimal when you're trying to to understand whether or not you're doing the right things and you're focused in the right areas. So that's that's just, you know, I cannot overemphasize it enough. I think the other thing is, you know, another useful way is being able to really focus on average exposure times

in the, in the areas that matter most, right? There are things on your network where you might

have a higher exposure time and be less worried about it because there is no realistic path to target or the path to target is very challenging or the path to that target for a malicious actor would necessarily involve crossing a lot of security boundaries, making a lot of noise.

So you can break that risk down by groups. You can break that risk down by other things like third -party patches, right? And do you care about all third -party patches equally, or do you care about those high risk items? know, a program that is primarily designed where you know your business use case for it is only processing of internal files. These files are generated locally. They're stored within

company repositories and they're processed again locally. They don't come from the outside. They don't go to the outside. That's something that you don't have to put as much effort into and you can assume more risk there. Whereas something like say a web browser, right? A web browser that goes out to the internet every day and is interacting with a lot of unknown sites. And as we've talked before, another podcast about the, basically the browser being the new operating system.

That's something that's critical to the patch right away, right? You do not want to have delays in processing your, or, excuse me, updating your web browser. So your risk appetite is going to vary based on the roles of the machines, what they're doing, the types of, network topology that they're attached to and how close they are to that network edge. And

the types of applications that we're talking about actually on machine itself. So, you know, that's where it's just been, like I said, at the beginning, this has been a very valuable journey for me at Automox to be able to work with a tool where I can have that level of control and that level of fidelity of setting policies and setting policies that are aligned

to my risk appetite as a CISO. And more importantly, establishing that balance lets me be very aggressive in the places where I have to be aggressive and I might maybe disrupt something or cause some undue delay. Well, not undue delay, but cause a bit of delay.

And then trade that off with yes, but I'm not being aggressive over here by choice because I don't need to be. And I think of it really as a form of political capital that I'm going to spend and invest more heavily in the places that I really have to. And then I'm going to save away, in the areas where it's, it's not as critical. And, and that lets me, that's what

that buys down that risk of being aggressive over here. So patching is more than just what's my mean time to remediate? What's my average exposure time? These are really articulations of how we perceive and deal with risk on a daily basis and ensure that we can keep business operations running

also cover those fundamental responsibilities we have to be well-patched, secure, and safe. So thanks again, everybody, for listening. Like I said, 25 ,000 is a really exciting milestone. If you're going to be out at Black Hat or DEF CON next month, please hit me up. And I will see you all in August. Thanks so much.