Just Patch It, Please: From Infinite Deferrals to Actionable Deadlines

Summary

Steph Rizzuto and guest Jason Kikta discuss the critical relationship between IT and security. They explore the evolution of these roles, the challenges faced by IT departments in contributing to security, and how Automox's innovative approach helps bridge the gap between IT and security functions. The conversation emphasizes the importance of collaboration, the need for a cohesive tech stack, and the shift from deferral-based to deadline-based security practices.

Transcript

Steph Rizzuto: Hello and welcome back to Automox's product talk podcast. I am your host, Steph Rizzuto and if you're new here, I am one of the product team members here at Automox. And today's episode, we're going to be talking about why great security begins with great IT and how Automox helps IT folks achieve that greatness.

I have a very special guest here to help me talk through this. If you watch any of our other podcasts, you're probably very familiar with him, but Jason, for folks that are just new in general, can you give us a quick introduction?

Jason Kikta: Yeah, absolutely, Steph. Thanks for having me on. Hello, everyone. My name is Jason Kikta and I am the CISO and also the Senior VP of Product here at Automox. I've been with the company about two years.

And before that, I spent about 20 years in the US Marine Corps doing IT and cybersecurity.

Steph Rizzuto: All right, thanks for that Jason. So he is really well suited for today's podcast. He's been over both and we are gonna dive into a little bit about how they feed into each other and how, know, Automox helps IT folks and what their role is in security. So Jason, from your perspective, like what role does IT play in security?

Steph Rizzuto: And maybe you can even speak to some of the challenges that you've seen over the years that prevent IT departments from contributing to the security posture of their company like they should.

Jason Kikta: Yeah, absolutely. And I think this is where I've been around long enough that I have. I don't know that I would call it a unique perspective, but there's, you you really have to have been doing this for a long time, at least 20 years, 25, 30.

Now I'm depressing myself. But to have seen the change and how that has shifted over time, because in the beginning, there was only IT. I started out in the 90s when security was a thing, yes, but it was something done by IT professionals. It was not its own separate discipline. And it was

Steph Rizzuto: Yeah, I was gonna say.

Jason Kikta: really mostly limited to passwords. Getting passwords on things was a big security achievement. And patching wasn't even part of the security equation yet. And yes, there were occasionally patches for security reasons. But patches back then were mailed out on floppy disk or on CDs. And large organizations would

It will, there wouldn't even be a regular patching cadence. Most of the time it was, Hey, their machines come in for maintenance. Let's try patching it or something broke on their machine. It's not functioning the way it ought to. Let's try patching it. and so was very focused around functionality. And I think as well, like most people don't understand simply because the security patches get so much attention that, you know, pound for pound, the majority of patches today are functionality patches, right? 

Even when Apple releases a big update for macOS and it talks about having a dozen CVEs that are fixed, that's great. But that is 10% of the entirety of that patch. And the rest of it is about fixing functionality, adding functionality, adjusting functionality. security is just not the majority of the patching equation. But it is a critical part and so it's important to understand that, but security was the responsibility of IT. And then as we evolved on into the 2000s and we started to see, you know, a lot of the, you know, email spread virus events like, you know, I Love You and Anna Kournikova. And then we moved into the big internet worms like Code Red and Nimda.

You know, security started to become to get enough focus that it started to become its own discipline. And we saw the rise of security vendors and security products, not just to adjust, you know, and don't think about just to address a problem, but also, you know, you now needed someone whose full time job was to manage a firewall. And was that really an IT function? Or was that more appropriately categorized as a security function that needed security leadership, security management? 

You know, security essentially grew out of IT, but there are a great many things that are, are in security imperatives that still remain the responsibility of IT. Right. And I think patching and configuration are the two most obvious examples where the configuration of a system, the patch state of a system, those are absolutely security imperatives of the security team. It's going to have policies around and be very focused on.

But implementing them remains and should remain the responsibility of IT because they're the ones who make those sort of changes on user and workstation and server endpoints. So those two teams need to work together. IT professionals still need to have a good understanding of security and that security mindset.

Steph Rizzuto: And you know, what I've seen and experienced is that's where maybe sometimes the challenge comes in. Those two teams working together. You know, I've seen it to where they don't necessarily always not speak in the same language, not, you know, not working as cohesively as they should. Can you, you know, in your mind, what about Automox helps them do that?

Jason Kikta: Yeah. That's where I think we've taken a fundamentally different approach than a lot of other folks in this space and where, you know, as, you and I on the product team, try and drive the product forward, we've started asking a lot more critical questions about what are the sort of tasks that an IT team needs to not only cover for their own responsibilities, but be able to cover because of a demand signal or requirements set down by their security or their compliance organization and trying to calibrate the product to be able to better meet those needs. So an increased focus on highlighting that work was done and delivering it via API because we see so much demand for being able to export the results of patching and configuration to an outside tool so that it can be counted for security or compliance purposes and, you know, rather than just internal reporting for IT benefit, you know, moving the move that we're making from a deferral based system to a deadline based system, I think is a great example, right? Deferrals are a very IT centric concept of I'm going to give this patch. The user might not be able to do it right now. I'm going to let them, you know, hit pause a few times and come back to it later.

And, and that's really an adaptation of the days of touch labor, where someone from IT would literally walk into, your office space and say, Hey, you know, I'm from IT. I need to do patches on all the computers in this room. Can I do it right now? And you'd have a few people who weren't there to log in or, know, maybe that wasn't an issue, but, they would say, Hey, I'm in the middle of something. Getting come back later. And so a deferral is, can you come back later? 

And it doesn't really take into account the modern security and compliance imperative of you need to have this accomplished by a deadline. And so by moving to a deadline based system where you can say, it must be done by this date and time, you may do it at any time at your leisure in between now and then it's here, it's ready, it's always available. But, you know, the deadline is the deadline. That's a more modern way of thinking about it. 

That's where we're trying to do everything from the way policies flow and integrate with each other to the kind of proof of work that you're able to produce to the end user experience, you know, really letting IT cover those security imperatives, but do them in a style that is conducive to the normal IT workflow and cuts down on their labor.

Steph Rizzuto: 

Yeah, well said. We're really excited about that shift to from deferrals to deadline.

Jason Kikta: Yeah, yeah, I think that's I think it's gonna be a big one. It's one of those things that it seems minor, but it has really good impact and it gets people thinking, right, because deadlines are how people express it right when I wearing my my CISO or CI-SO depending on how you want to pronounce it. I've never I've never heard people agree on that. But when they want to focus in on or sorry, when they get a task related to that, they go and they, you know, it it's given as a deadline. It's not, hey, I want it done. You know, I want it done this week. But, you know, you can give them three deferrals of eight hours each. Like no one says that they say, I need this done by the end of the day on Friday. Right. And so that is a very direct translation of I have received this task from management.

This is when I need to have it accomplished by and, and, this just like, let's them really oriented on orient on it in that way and be assured that they're going to achieve the outcome that, that they need. Right. And so it's that, that outcome assurance portion that I think, you know, where having a product that is simple and reliable and, just, you know, really straightforward, it does what it says. It's, it's, you know, you can really rely on those results. That's where it's really important. 

It's not just on patches, it's configurations as well of, you know, you have a set of things that you want to assure every single, you know, endpoint has each and every day, right? Is the password policy in compliance? the, you know, you know, the security configuration compliance, are these services shut down? Are these things enabled? 

Do I see these agents on the machine and being able to run a Worklet to run and go and execute that evaluation code to say, is this the case on this machine? And then if not, move into that remediation code to be able to fix that result and let you know that something was out of compliance. you're still assured that whether it was in or out of compliance, it is now in compliance as of the time that I set that worklet each day and it's ready to go for the workday. That's really, really important. And so those are the kinds of things that we, you know, we focus on and try and just make it easier each and every day.

Steph Rizzuto: Yep. Well, I feel like we could talk about this all day and there are all kinds of examples we could use. But as we come to a close, do you have any final thoughts that you kind of want to share, get out there?

Jason Kikta: Yeah, I think the thing that I would leave the audience with is, you you should think as an IT team, should think cohesively about your stack and what tools you want in your stack. And if those tools are, you know, really oriented to your use case or, or, or not. And, and, and so the example I give of that is one thing that I'm passionate about on the security side is that security ought to be free, right? You should not have to pay an upcharge to cover security imperatives in your IT tool. shouldn't be paying extra for a single sign on or authentication or audit logs, those should all just be included. And so, you know, if other tooling is charging you a premium for that, then they're probably not as interested in your needs as a customer. They're really just interested in extracting the maximum value. I think that's it's a very wrong headed way of doing it. It's a cynical way of doing business because you can make good money by simply focusing on your customer's needs and fulfilling them really well. And I feel like that's the culture that we've set and we maintain here at Automox. And I'm really proud to be a part of it. 

Steph Rizzuto: Agreed, agreed and well said. Well, as always, thanks for joining us and I will see you guys next time. Thanks, Jason.