Autonomous IT

Jason Kikta (00:01)
Hello and welcome to the Automox CISO IT podcast. I'm your host, Jason Kikta, and I'm excited that you came back to join me for another hopefully fun-filled episode here in the month of October. And I think I'm more excited than usual about this month because we're doing a topic that's near and dear to my heart, probably because I pestered them until our marketing team gave in to me.

This month we're doing "Great security begins with great IT." And as those of you who've listened to the show for a while know, this is something about which I'm really passionate. I probably harp on it a little too much, but hopefully we can consolidate a lot of those discussions here today and also expound on it in new ways. So

The first thing that I think is important to talk about and understand is that, having really good IT is helpful to security because they're both after the same thing. It's actually the same goal. And that goal is normalcy. It's a standard. You know, if you think about it, security is the art of detecting anomalies in your network, right? What is normal?

And then therefore what is not normal? What what might be out of that abnormal behavior, malicious activity, you know, whether it be an outside actor or someone in the company who's doing something that they ought not to be, you know, being able to find those things to do that anomaly detection requires you to have a relatively solid understanding of what your baseline is of what

normal looks like. But that's not all that different from IT, because when you think about it, IT's job is to make the network work to make the systems work for the users. And that requires inherently a lot of troubleshooting. And so, as someone who spent a lot of his career doing troubleshooting, you know, if I didn't have a solid baseline image with which to work, it was really hard to tell

what had gone wrong on a given system to where, you know, a piece of software didn't work or a setting didn't, wouldn't apply or whatever the case was. Because, you know, I couldn't figure out, well, what makes this system, this person's system or this person's account or this person's access different from all the rest, right? It works for others. Why doesn't it work here? And, you know, the harder it is to do that comparison, the harder it is to, to do that troubleshooting step. So.

you know, that goal of setting a standard baseline of having a an established known good configuration, you know, inhibits both your it and your security goals. So I think like that's, that's sort of the foundational concept here. And then it you know, you can extrapolate onward from there of, know, having that set baseline allows you to make really good configuration choices, it allows you to make

Really good patching choices and to, to, you know, really get consolidated, you know, sort of consolidated grip on identity and authentication. Right. Do you want to have, you know, your users just picking and choosing and using a multitude of vast array of different systems to authenticate, or do you want to collapse down into this is my single sign on solution. This is my password management solution for the things that I can't put into single sign on and.

It's one of those two, right? It's going to be in one of those two because things are not supposed to live elsewhere. Will they? Yeah, from time to time, you're going to find something that doesn't and, you know, you can deal with those policy violations as they come up. But then, you know, that helps you if someone is, you know, like an actor is trying to smuggle something into your network or hook up an authentication provider that you didn't authorize, like that stands out

as anomalous activity. If you're an Entra ID shop and all of a sudden you see Okta usage, that's not good. If you see Okta and all of sudden you see this other product, that's probably, at a bare minimum, it would be a violation of your policy. But depending on what it is, it could actually be malicious activity. I think the other thing to understand, and this is where

You know, it's not something that's self-evident if you haven't encountered it before, but, you know, once I started thinking in this way and explained to others this way, it seemed to make a lot of sense and really help other people understand it, is that, when you take this sort of anomaly detection approach, then you find that you don't need a lot of specialized detection. And what I mean by that is,

I used to get questions on how do I detect an insider threat versus a malicious actor? And the reality is, that those aren't so very far apart. Yes, a, an insider threat will do things differently than a malicious actor will. But when you think about it, you know, a malicious actor gaining access to your network, they're going to try to pose as

a legitimate user, legitimate administrator and trying to assume some degree of a persona that belongs to a real person and then do things that are, you know, violating the confidentiality or the integrity or the availability of your systems, right? And obviously, there are exceptions to that when you talk about, you know, taking over like service principal accounts and cloud architecture, like things that don't have a human being tied to it.

where they're trying to pose as the machine, but but the majority of intrusions and the majority of techniques are around, I'm going to take a human beings persona and then you know, sort of manipulate that to my will and to my the ends I'm trying to achieve for espionage or effects or criminal activity. And so if you even back a step back up a step further, there's there's an even

clearer approach you could take, which is user safety, right? So instead of thinking about what is the state actor going to do? What is a ransomware actor going to do? What is a, an insider threat going to do to my network? I started about thinking like, what is my network encounter most every day and what it encounters the most of are not those things. What it encounters are normal users just trying to do their jobs as best they can. And they make mistakes.

Right? Like they don't understand what, what, you know, that if they do a certain thing, it could cause an issue for at least for themselves and sometimes for other users on the network. so you have to factor in that sort of user safety component of, I'm going to have things like, you know, least privilege as one of my core principles, because having least privilege means that someone, whether they be in accounting or whether they be on the IT team,

can't make a massive mistake that would take a large chunk of the network down, kick users offline, cause people to lose data. Potentially catastrophic, painful or time consuming results. And so if you engineer for that of, want to prevent people from making mistakes, you're already covering some of those security imperatives that are going to help you way out at the extreme example of

Chinese intelligence is trying to break into my network and steal my information, right? Like you covered some of those bases over here in user safety well before you got to that point. And then from user safety, you you know, you work into other topics. And again, like before you get to insider threat, you already had Shadow IT because Shadow IT, you know, not helpful to your network can can have some negative outcomes of

you know, someone comes along and says, "Hey, like, you know, your employees are, are pirating my software. They're, you know, misusing this thing. We found corporate data on the service to which we have, you know, we have no NDA in place and no commercial relationship to protect that data. We're not doing security monitoring on it." And I think there's also, we can have a whole other talk on how I think that, you know, Shadow IT is a little bit,

you know, indicative of failures in the IT system, right? Whether it is the, the service we didn't provide them wasn't adequate or they didn't know how to access it or, know, they didn't think it was possible to do. Like they didn't understand the finer nuances of it. And like, those are definitely things that you want to address, but, but in order to do any of those things and to figure out, look, is this a gap in our IT program or is this user just, you know, just did what they wanted to do? It doesn't.

doesn't really matter if you can't detect it. And so detecting that is sort of the next tranche of things that you want to think through. Again, what services do I expect to be running in my network? What sort of files and formats and what type of computers, right? If we're in an all Windows shop, and I see Macs on my network, that's not good, vice versa as well. So you know, understanding what should be in your environment.

from the network level down to the individual applications that are installed is very important. And that helps you cover down that Shadow IT. And then you move into the malicious insider or the insider threat. And again, that insider threat, they're going to be taking data. They might be accessing things to which they shouldn't be accessing as part of their job role. And if you're seeing a user

exceed their authorized access, moving data, downloading data, copying data, right? Like those are all things that yes, it helps you catch that malicious insider. But what you actually might be finding is, you know, some outside threat actor, cyber threat actor who's in your network and is manipulating that account to do those things. And then you move into, okay, this is what the criminal looks like. And this is what the state looks like. So start with

user safety. That's what I'm really getting at here is that user safety, and then sort of working your way through really helps that out. And then the final thought I'll leave you with, because I promised I would keep it to three this month, is, you know, it's really comes down to the my big three of cybersecurity, which is it is again, it was the same thing I used to say in DoD, when we would come to do an incident response, and we'd find some very

heavy state actor in a network and the network owner very much wanted them out of there. You know, their mind was on eviction and like, let's get them out now, stop them from stealing sensitive government data. Yes, that is a thing we will do. And I'm going to go take care of that. But what I need you network owner to think about is if you don't have a way and are doing it on a regular basis to know what's on your network,

to keep those things configured and patched and to protect identity and authentication on that network, then nothing I do matters, right? If I can't do those three things, then none of the rest matters because those actors will be right back in here in a day, a week, a month, a year, because they'll be able to, right? Because you can't cover down on your fundamentals. And again,

Right? Like those are also sort of IT fundamentals of I should absolutely have an inventory of what's going on my network. I should absolutely have a baseline by setting and maintaining configuration and patching and software installation standards. And I should absolutely, you know, have a firm grasp on how authentication and identity is, is treated and maintained and postured within my network. And if I'm covering down on those IT imperatives.

the security stuff just follows, right? Because then your security program isn't having to build from scratch. They're adding a layer of expertise and nuance onto those existing IT imperatives. And that's how you get your two teams working together and working together as one integrated whole rather than as, you know, mere counterparts who are floating along together or worse yet as adversaries, right? IT and security should be the best of friends and by

designing our programs to work together as one, we can achieve that. So thanks for joining me today. Again, a pleasure as always, and I will see all of you back here in November. Stay safe out there.