Cybercrime – Identity Management – Part 3/4

Cole French:

Managing identities, quite possibly the most difficult and complex task facing any organization. Just like security is often an afterthought in the development of systems, so it goes for the management of identities. We’re quick to give access, leaving security as an afterthought. This creates a tangled web of unintended consequences with privileged access bleeding all over the organization. Tune in for the third installment of our Cybercrime series, where we dive into solving the problem of identity management. Welcome to the Cyber Compliance and Beyond podcast, a Kratos podcast that brings clarity to compliance, helping you leverage compliance as a tool to drive your business’s ability to compete in any market. I’m your host, Cole French.

Kratos is a leading cybersecurity compliance advisory and assessment organization, providing services to both government and commercial clients across varying sectors, including defense, space, satellite, financial services, and healthcare. Now, let’s get to today’s episode and help you move cybersecurity forward. Identity management is the most important security function an organization undertakes. And remember, identities aren’t just people. They’re also assets in facilities. And assets often leverage something called service accounts, which are another type of identity that are especially powerful and problematic.

To do identity management well, organizations must focus on the most basic task, defining the assets within the organization based upon their importance and priority in accordance with an assessment of risk. As we’ll break down on today’s episode, from there, organizations can lean on a well-defined approach for managing identities and their privileges in a manner that strengthens security, while not also requiring perfection. Joining us again for part three of our Cybercrime series is Terry McGraw. Terry’s a retired lieutenant colonel from the United States Army and now serves as the CEO of Cape Endeavors Incorporated. Terry brings over 20 years of experience in cybersecurity threat analysis, security architecture design, network operations, and incident response across both commercial and government sectors. We hope you enjoy this episode.

Terry, thanks for coming back on to continue our Cybercrime series. Just to recap for those of you out there. In our first episode, we discussed the cybercrime landscape. And in our second episode, we talked about credential theft. As a jumping off point, today we’re going to dive into some solutions to some of the cybercrime stuff, particularly the credential theft issue, by talking about identity management. We did kind of touch on it at the end of our last episode, but we’re really going to dive into it today. So, Terry, if you could start us off by just describing where you see organizations struggling the most when it comes to identity management.

Terry McGraw:

I think, in general, where organizations struggle is in implementing a tiered security model for their identity access management and privileged access management. And what do I mean by that? So, Microsoft, whether you be on-prem with active directory or cloud-based Entra ID, formerly known as Azure Active Directory, the idea of a tiered security model. And it’s been a Microsoft best practice for a very long time and been summarily ignored by many, many in enterprise subsequently. And what it really boils down to is treating your privileged and your identity access management in tiers. So, Tier 0, being the highest level with the most privilege. And that’s your domain controllers, that which provides basically all of your admin around your top level domains for your domain controllers in your environment.And the admin credentials to log in and push GPOs, for example, and configure the overall architecture.

And Tier 0 should be the most locked down, should have the fewest level of admin credentials, the highest level of observation and anomaly detection. And accessed only through either a privilege access workstation or a privilege access gateway, where we’re highly, highly locked down. And anything that touches your domain controllers is then Tier 0. And it shouldn’t have regular internet access, et cetera, et cetera. It should be as locked down or as restricted as possible to do that level of domain admin. And so, Tier 0 becomes the foundation, meaning if that’s the highest level of creds that gives the threat actor... Well, it gives an, A, you’re enterprise the most control of your environment. It also gives an adversary the most control of your enterprise. And as such, it should be locked down to the highest degree. So, that’s Tier 0.

Tier 1 in the Microsoft model is enterprise management. I mean think the servers and systems that are at the enterprise, that are provisioned across your enterprise. Whether these be applications that are used by many groups. Whether this be the systems and services ERP, any number of systems and services that service the enterprise. Meaning, there are a group that is accessed by lots of individuals for other data systems. And that should have another set of distinct credentials, meaning the admin logging into a domain should never, ever, ever use domain level creds to then do administrative actions across the enterprise against systems and servers that aren’t the domain.

And then the final tier, Tier 2. And of course, you can become more granular than this. But Tier 2 is essentially your local admin, your help desk kind of resolution or your servicing endpoints, those that are directly connected to users. And so, in that tiered model, what you’re doing from an adversary perspective is denying the highest level of credentials to the folks that are most likely to get compromised, i.e., your users. So, we can think about this in terms of a if an adversary approach to this. I send a spearphish to a average user. I convinced that average user to click and authorize an activity. That gives the threat actor the initial footprint into the environment.

Now, let’s see how this can unfold in a very, very quick, but horrible way. Let’s assume one day that a network engineer or a network admin coming into your environment, very overworked, very taxed, logs in to do some general pruning or push a GPO, do some level of Tier 0 activity. And while logged in, just decides to grab some help desk tickets, and just use that admin to pivot over and start knocking out local admin type activities. The problem with that scenario is now those domain credentials are on a host laptop, if you will, from an individual user. And if that user responds to the phish, clicks on the phish, enables something like Qakbot or any number of loaders or stealers, you’ve now allowed the adversary on their first compromise to harvest all the credentials off that box.

To it, they will find domain level credentials on that box. So, they take it offline, they crack the hash and password, they come back in. Lo and behold, their domain, they have domain level access right from patient zero. That’s not a stretch. This has actually happened. It’s happened in real life. I’ve witnessed it in an instant response engagement. It’s not completely atypical. It happens more often than you would think. And so, maybe that’s a long-winded explanation of what it is. But identity access management and how it can unfold when best practices aren’t adhered to. And then what is the appropriate response to that?

Cole French:

So, the tier model you described plus the example you just shared. So, in a tiered model, it sounds like you want to also make sure that those Tier 0 privileges are confined to the Tier 0 applications or systems, we’ll call them, correct? Would you say that to prevent the scenario that you just described, you wouldn’t want to even allow those Tier 0 accounts to access the type of access to do local admin tasks? Does that make sense?

Terry McGraw:

Yeah, it does. So, unfortunately, once you’re logged in at Tier 0, there’s nothing to prevent necessarily someone from pivoting in and doing other kind of activities across your environment, at least not without additional security controls. And so, it’s really establishing best practice, rigorous auditing, et cetera, of your people, to ensure that they’re not misbehaving while either overworked or just being complacent, or God forbid, lazy. But it does happen. But it also includes not just your Tier 0, but your enterprise server accounts. For example, if you administer CrowdStrike or Defender, or some other EDR or MDR solution in your environment, that is often administered as an enterprise service. You have not only the service, you have the admin account that operates it, but a service account is associated with its implementation.

And so, those level of systems and services are at that enterprise level. And so, if I’m using those server credentials or admin credentials elsewhere in the environment, I also give the adversary the keys to my defensive kingdom by not using that appropriately. So, now, Entra ID, if you’ve moved to an Azure ID or a Entra ID as it’s called now, rule — groups and roles, and the granularity, and the ability to administer them is much, much greater and a much higher fidelity, and it’s a lot easier. It’s also a lot easier to shoot yourself in the foot if you don’t do it right. But that said, it’s much easier to administer across an architecture, if in fact you’re using the Entra ID solution rather than on-prem active directory.

But either way, the principle holds the same. Tiering those credentials and those accounts in a way that you don’t allow all the keys to your kingdom to be harvested should the lowest level of your enterprise be compromised, i.e., just a typical user. Oh, by the way, I should mention, service accounts are a prime target for adversaries. Service accounts are some of the most poorly administered and monitored accounts in the environment. They’re often given to broad a privilege. They’re included in ACLs, overly broad. We don’t rotate passwords. Sometimes they’re not even monitored. And harvesting a service account is an attack path to higher level portions of the administration or environment as well, and often used by threat actors because of that reason.

Cole French:

And I think, too, on the service account issue, this is going way back earlier, in the earlier days of my career when I worked more on the operations side of things and we actually initiated an effort to crack down on service accounts. And the first step of that was to actually get a handle on what is actually going on with service accounts in our environment. How many do we have, where are they being used, all that kind of stuff. And we leveraged some of the tooling we had in our environment at the time, did some scanning. And I mean, quite frankly, the results were shocking, in all the ways that you just described kind of at a summary level. But more specifically, we were using the same service account across multiple applications, systems, and tiers. And by tiers, in this case, I mean production, development, staging, test, all that.

We were using a service account that was intended for a test environment on production systems. We had instances in which the service account password was embedded in software. So, yet a legacy application that wasn’t capable of doing AD authentication in a dynamic way, so it actually had to be encoded in the application. So, if I got access to the system, I could actually open up files within that application and there’s the service account password right there, plain text. So, service accounts are a major problem. And in many ways I think they’re operationally much more difficult to manage and maintain than even user-level accounts, just because users are tied to people and we know who people are.

And even though there’s problems and challenges that come with managing user access, it’s easier for us to tie that to an individual. But for service accounts, they can just... And like you mentioned, overworked, taxed, all that kind of stuff, service accounts are prone to shortcuts. So, a major problem. Does the tiered architecture within Entra ID, does that also address service accounts? Can you use that tiered structure to manage your service accounts as well?

Terry McGraw:

Yeah, and you should. So, in a more macro sense, I think that a lot of organizations, not only architecturally do not design it that way, but let’s assume they thought they did, have never done a real attack path enumeration of their identity and privilege access management or their AD. And that’s a combination of things, because everything we just talked about, bad practices, not tiering your environment. But it also leads to things, for example, Kerberoasting, when you’re using those service accounts, so that they’re not appropriately aged, changed or altered, and tickets are granted, and then they take that hash off, recracking, and they just come back in. So, it’s just sort of a perpetual entry key if they’re just signed, and left, and implemented, and then never altered again, which is sort of what you’re talking about.

Orphaned or stale accounts, meaning people who no longer need access, their accounts are just left there. No one was properly off-boarded from the environment. ACLs are misconfigured and you have group assignments that are overly broad or people who are assigned to groups who shouldn’t be. And that role gets extended. And when you do a true attack path enumeration, and I’m talking like Enterprise BloodHound, SharpHound, BlueHound, those kind of tools in your environment, you realize how a complicated an enterprise can be in their model of privilege management or identity access management. And then how errors over time can lead to horrific consequences.

Because again, it’s unintended escalation paths, just based on user or service accounts being attached to groups they shouldn’t be or those groups given right access when they shouldn’t, et cetera, et cetera. So, there’s a whole host of things that go into the management security, not only from the design principles when you initially implemented. But over time, making sure that you clean this, you enumerate these attack paths, and you do your best to clean them up as you discover it. This shouldn’t be just a one and done. In fact, in a lot of cases, you can’t. Because you can have operational impacts when you start altering the establishment of your active directory trees and forest, as you’ve been managing that enterprise for years, and years, and years, you may have attack paths that you did not intend but have grown over time.

But in addressing them, you may break a lot of stuff. So, you have to do this in a very methodical way with change management windows, rollback procedures. You have to really understand what it is you’re attempting to fix, the best path to fix it, while not creating an operational disruption on yourself. In fact, this is why identity access and privilege access management continues to be a problem, because it can have serious operational consequences if you screw it up. Like I used to say, an enemy-inflicted wound and a self-inflicted wound have the same operational impact. How you react to it is often what’s different. So, I mean, you can shoot yourself in the foot by breaking your active directory or you can allow an adversary to do it, but it is in that long-term negligence that you inherit the most risk.

Cole French:

I would assume, too, that another aspect of addressing it, there’s always, like you said, unintended consequences. So, I think when you’re starting with a system or a setup that’s been in place for a very long time, fixing it, actually, there’s probably... I would assume there’s sort of a secondary level of effort required to make sure, okay, we identified that we need to fix this. We went and then we fixed it, and now did we create some new sort of unintended consequence from a security standpoint out of that. So, I would imagine it’s almost like this, I mean, like you said, obviously, not a one and done, but also not even necessarily a periodic exercise, but it could be a multitude of exercises as you go through these changes.

Terry McGraw:

I like to treat it as a bullseye, right? I mean, the tiered model also serves as how you should address these from an improvement standpoint or a security efficacy point. Start at Tier 0. And clearly enumerate admin accounts and service accounts associated with Tier 0 and question why they have that level of access. You should have the bare minimum it takes to actually do your Tier 0 management and not a single credential more. However, with that said, you should have a break glass account set up. And so, in the event of an adversary activity or a willful insider, you have the ability to wrest control back from your environment by having the ring that binds them all, the break glass account that you have, those credentials are stored offline. Often, you either have a FIDO2 compliant YubiKey, for example. The password is kept in a vault.

It is not accessible to anyone externally and only to be used in fact of emergency. That break glass account is exceedingly important. And I mentioned FIDO2 compliance. It’s often hard or expensive to do FIDO2 across the environment, although I’m advocating everyone move to a passkey environment, if humanly possible. But that FIDO2 device is for your admins at a minimum, particularly Tier 0. And if feasible in your environment, for the enterprise level as well. This takes out the man in the middle kind of attacks. But we’ve already described what that YubiKey provides, where the authentication’s now moved to the trusted platform module. It’s now the authentication is done in a public private key exchange on the device in hand. It’s not done by remote server and there’s no token to capture.

So, if you’re looking to do enterprise management identity access and privilege access, having your admins have to implement a FIDO2 device for a FIDO2 scheme in order to implement their administrative duties, highly, highly recommended. It is the best practice, way, way more secure than the most folks are doing it.

Cole French:

So, you mentioned the break glass account. Can you maybe just go into a little bit more on what a break glass account is/ Do you see organizations that don’t have break glass accounts?

Terry McGraw:

Oh, yeah. I mean, most of the companies that end up in an IR engagement, where they’re calling in for help to recover their environment from either a ransomware and, or exfiltration of data, did not have break glass accounts. Or if they had a break glass account, those credentials were capturable along with everyone else’s. So, when I say keeping them out of band, I truly do mean that. Meaning, it’s a 36 character password, it’s using a YubiKey. The YubiKey is stored in a vault, the password is stored in a vault. There’s no ability for someone to actually get that information, and unless it’s a deliberate activity in an emergency. And those are kept highly secure.

Most companies that end up in trouble have never done that, or have too many admin accounts, have too many broad privileges. Again, the initial access vectors have been the same for 20 years or more. And that’s malware introduced through phishing. It’s unpatched systems, and services and it’s stolen credentials. So, if you’re looking for the ounce of prevention versus the pound of cure, those are the things to help shore up. The problem is it only takes one person to click on the phish to pressure test your entire security architecture. And so, it really does. The operational impact reduction is truly only enabled by your identity and privilege assets management controls. That’s how you reduce operational impact.

And it’s by doing these best practices that you keep your business operational, you keep yourself off the 6:00 news, and you don’t have that existential threat to your business. But yes, to answer your question, in the many, many instant response engagements, break glass accounts are almost never in place, and certainly have a very weak privileged and identity access management program, not by intention. I mean, again, no one sets out to say, “I’m going to completely ignore this part of my security defense.” I guess it’s kind of exacerbated, too. I don’t think we’ve done a real good job in ensuring and vetting the quality of the admins that do this work.

And ensure that they understand it’s not only the administration of adding in users and adding objects, et cetera, but true access control is configuration, true privilege identity access management, true understanding of attack paths in active directory. I don’t think we do a really good job writ large in ensuring that the appropriate skill sets are brought to bear or at least augmented, occasionally, to your normal admin to ensure that we’re doing this correctly. Because the skills can be a little bit esoteric and the hands-on skill for doing this, folks that do it really, really well are super gainfully employed. And very few leaders and managers, even in the security space, could actually do this level of work themselves.

It’s really hard to verify it. I recommend that as part of your pen testing. Pen testing is not only about your system security. And oh, by the way, an attack path enumeration test specifically designed for what we’re talking about. It’s also a good way to ensure that your people are trained appropriately. And lack of training is not an indictment on the person. It’s just lack of opportunity. So, ensure that your people are getting that training and ensuring that they’re meeting that intent.

And so, you’re not only pressure testing your system, but you’re pressure testing your people. And those are good mechanisms to ensure that you’re looking at people, process and technology, not just the technology, which is where we often focus on pen testings, and enumerations, and those kind of things. We often forget about the skills of the people who are supposed to be administering it.

Cole French:

Yeah. We always say asset inventory is not just the devices on your network, it’s also the people, the processes, and even your physical locations where your people and technologies actually reside. So, the skillset, if you could describe the skillsets that are required or that you think are required for admins carrying out this kind of task, and how would you describe them in more detail, the skillsets needed?

Terry McGraw:

Yeah. I think that it’s fairly, I don’t want to say it’s simple. But I mean in much the same way you look at your security professionals, like your intrusion analysts. And if you looked at it in tiers. So, I have the folks that can do initial triage and containment. I then have the next level of folks that can do threat hunting, and look for the non-typical and more advanced trade craft that may avoid or evade your security controls. And then, of course, your highest level are your forensic incident responders. In same way, you can look at your network administration. And they’re not always equal.

Your typical admin that understands your Microsoft certification, who can add and subtract users and do basic functionality, help desk level thing, those are the kind of certificates and skills that you look for, for your everyday admin. When you get into your architectural design and security thereof, that’s a different level of person, which different certifications. And honestly, Microsoft changes these every now and then. Microsoft does have a pretty good enumeration of certificates and the training modules associated that go along with these. But in general, I think the next tier is someone who can design a network appropriately, someone who understands active directory, both on-prem in a hybrid environment.

And if you were going to leverage a full Entra environment, what that means for a cloud and on-prem hybrid, and someone who really understands the network design. And I think the highest level tier of those are folks that really understand active directory attack path enumeration. That is a skill set in of itself, and understanding how to decompose the architecture. So, here’s what I’ve found as attack path and then being able to build you a plan to fix it. And I don’t think I finished my thought earlier. You start with Tier 0 as the bullseye, then you work yourself down to Tier 1, and then you do Tier 3.

And some organizations may never get past Tier 1. But even if you just got Tier 0 and Tier 1 down, you are still removing an adversary from gaining elevated privilege to do enterprise-wide damage. An adversary can still do business email compromise at the user level and do maybe some data exfiltration of that user’s individual stuff, but you’re removing the ability for them to do serious enterprise damage anyway. So, that top level of active directory expertise is really about how do I ensure the security of the architecture that’s been designed, that’s implemented. And again, that might be something that you have to just go ahead and seek a third party for. Those are esoteric skills. They’re in high demand. Most folks never do that well. Hence, we got all these instant response engagements in ransomware. But having someone that can actually come in and test, make sure that your active directory engineers and architects have done it correctly. And then, of course, your help desk folks.

I think the biggest mistake that we make, Cole, is treating all IT people the same. And this is going to be... it’s a little graphic, but I use this joke a lot. A proctologist and a neurologist are both doctors, but you don’t want them doing a high five in surgery. The leadership of a company need to understand that IT people have skillsets that are designed for systems, and services, and levels that are commensurate with their skillsets. You can’t just take your normal help desk person and next thing you know they’re doing intrusion analysis and threat hunting in your environment. Can some of them do that? Yes, but it is not a one for one. And the skillsets, it takes a long time to develop or the expertise level does.

Anyway, I say all that to say hiring folks need to ensure that the people that you’re hiring have the skills commensurate with the job that they’re maintaining. Don’t assume that if they have a bunch of Azure certs, that that means that they’re also qualified to do threat hunting, if that’s also mean if they’re qualified to do attack path enumeration. Again, you need to look at the job at hand, and ensure that the skillsets and qualifications of the people that you’re hiring and, or bringing in as a third party are commensurate with the job that you’re actually expecting them to do.

Cole French:

Great advice. And I think I would just, as I always, highlight when you’re talking about bringing in third parties. I know that a lot of organizations see that and see the cost. And there’s some sticker shock there. But I think you would agree that in probably almost every scenario, the cost of bringing in a third party expert to help you with something. Now, again, I think the biggest, most important thing when doing that is understanding what it is that you’re seeking to get out of that. So, kind of like what we’ve talked about here. If you’re hiring a third party, you want to know what it is that I want them to do and what I want to get out of the engagement. And that’s going to dictate cost and help keep costs down, frankly, from a scope perspective. But all that to say, it’s almost certainly going to be less than if you leave it all to chance or you just do the best you can, so to speak, without that expertise.

Terry McGraw:

It’s exponentially smaller, I guess, or the inverse, logarithmically smaller. The cost of an incident response engagement or ransomware activity, where you have operational disruption. So, you’re dealing with the business loss, the inability to actually conduct business for X amount of time. And oh, by the way, on average, it’s about five weeks for full operational recovery from a ransomware. That’s five weeks of some level, if not complete operational impact or outage, some level of degradation for that time period. And it can be enormously expensive. Compound that with, in almost every case of cybercrime that involves sort of ransomware activity, data exfiltration is now a component. Meaning, they’re stealing data from your environment as an extortion tactic later.

And so, now you have litigation potential costs that are associated with that data exfiltration, which is why a lot of the threat groups find it... they focus more on the data exfiltration than even the malicious binary to encrypt the environment. Legal fees. I mean, if your law firm is $1,500 an hour for external counsel and they’re bringing in more than just one, they’re bringing in a team of folks, depending on the size of your organization, that stuff adds up very, very quickly. Then you have potential litigation from the data that was exfiltrated. So, you have your stakeholders now suing you, loss of contracts and confidence that they go elsewhere. So, you now have long-term business impact. You probably have a shorter term. If you’re publicly traded, there’s probably going to be a loss in stock price.

I think those things are fairly short term, like the market valuations. They come back in time. But we’re talking about financially having to restate your financials if you’re publicly traded. These are impacts that are big. They’re really big and they’re very, very costly. The infinitesimal cost of bringing an expert to make sure you don’t fall into this or hiring the right people, or ensuring that you’ve exercised due diligence by testing your environment, et cetera. I know why companies don’t do it, because it’s a margin impact. Cyber is always a margin hit. It doesn’t add to the value of the company, doesn’t add to ARR, MRR. It’s an operational... or CapEx, OpEx. And it’s not margin generating. It’s a margin hit.

And so, I understand why companies loathe to do these things. And it’s hard for a lot of boards and financial... or the finance wing of a company to understand the business risk mitigation strategy when it comes to dollars. But that’s why the security folks have to speak in business language, not cyber language. You have to articulate business risk and business risk reduction, and mechanisms, and language that the board understands, because the consequences are really, really dire. And they are existential threats. So, you got to do your best to enumerate that for your stakeholders so they’re making the appropriate investments.

Cole French:

That’s all great advice. And I think, again, like I mentioned, too, I think it’s important to really understand. In addition, I know that the economics of it are kind of maybe their own piece in and of themselves. But I also think to the degree that you can within your organization, learning and understanding what you need to do and being able to articulate why you need to do that. And it could be even in small steps. Like you talked about earlier, focus on that Tier 0. I think a lot of times we see problems and it’s like, “Oh, man, I got to tackle this whole thing. I got to finish all of this.”

But really, break it up into smaller pieces and focus on each of those pieces in a priority order. And then maybe some of the costs, maybe you can defray some of that cost over time, because you’re really focused on Tier 0 for now. And then once we get that situated, move on to Tier 1. And it doesn’t become sort of this runaway cost. So, I think there’s ways in which you can help that problem of cost, by really understanding what you’re trying to do and scoping it appropriately.

Terry McGraw:

No, you’re absolutely right. And you really hit the nail on the head, let’s not do it all at once. But you don’t have to do all either. There’s never going to be perfection here. You’re never going to be 100%. The old Murphy’s law of combat. If your perimeter is so good that the enemy can’t get in, you can’t get out. That’s true. I mean, it’s true for networks. You’re never going to be totally secure. For example, even in the most highly secure environments, even in a air gap system, a nation state can always hire someone to work inside your organization. There’s never purity of this. So, you’re always going to have to do a risk-reward matrix, and a risk assessment, and establish where that good enough is, and how you can mitigate the rest of that risk. Whether you offset some of the liability or concerns with insurance. Whether you buy down the risk to a point where you’re confident that you could overcome the potential loss.

And honestly, you don’t have to do it all. In the world of cybercrime, maybe not necessarily nation state espionage, but in cybercrime, certainly you don’t have to be faster than the bear. You have to be faster than everybody else around you, because threat groups want to make a quick buck with the lowest level of effort possible to monetize that theft. And so, everything you do to raise the bar, make it more and more difficult to extend out the kill chain, et cetera, the less likely you are to be that victim. Make it as hard as possible to avoid the easy way in and the easy way to enumerate. And what I’ve articulated and what we’ve both been talking about are basics. We’re not talking about adding advanced analytics and all that other stuff.

I mean, those are all important. But if you haven’t done the basic structuring of your network in a defensible posture, start there. I mean, don’t invest another dime until you’ve maximized all the money you’ve already spent. That’s another piece of my advice. Make sure what you’ve got, you’ve done correctly, you’ve got fully implemented, you understand, it’s well enumerated, and you understand where the gaps and seams are. Don’t spend another penny on the next magic bullet until you’ve absolutely insured that you’ve maximized the investments you already have.

Cole French:

Yeah. I’ve heard people say, don’t let perfect be the enemy of good. I feel like that’s kind of what we just described. And as we bring the conversation to a close, I did want to bring up a scenario we haven’t really talked about. It lurks in the shadows, so to speak, of what we’ve talked about. But kind of a specific scenario that we run into a lot in the compliance world, which is around separation of duties and least privilege. So, small organization. I only have two or three network people, admins. We kind of all wear different hats.

In your experience and from your perspective, what’s the best way to address... because one of the issues with identity management is making sure that I have different people performing different functions. I don’t want my network admin to also have privileges to access logs, because then obviously he might perform some function and then delete the logs. So, how do you suggest smaller organizations with really small IT staff address issues like separating duties and the least privilege?

Terry McGraw:

Yeah. So, that’s a difficult one, especially in small to mid-size enterprise. Well, hell, or even large enterprise that have under-invested. You get two or three really overworked people or even one in some cases. I’ve actually been at a federal credit union where their one IT person was also the security person, which is also their IT manager. So, not only is that just for... Just take out malicious insider from the scenario for just a second. But just what happens if, God forbid, that person leaves, and he goes on vacation? I mean, there is a problem when you go to that level. So, I mean, some of it is just recommend. Look, you can’t be that single-threaded. But in practical terms, Entra ID makes this a little easier to control roles in groups and to make sure that you can’t do certain functions with one set of credit.

So, first thing is, is even if you have one or two people, ensuring that their duties and responsibilities are separate and distinct from the roles that you want them to admin. So, it goes back to tier modeled. Make sure that you have a clear delineation. Be someone who is the domain level admin, someone who’s the enterprise admin, someone who’s doing help desk. And you need at least two there. For the domain at the highest level, the global admin, the domain level admin, what I recommend is that when that person escalates their privilege, that another person has to approve it. In Entra, it’s simple to get that alert and to authorize it. It’s a little bit more challenging active directory, but it still can be done.

And even if that person is a manager who’s not have admin level skills, that notification and approval is a very good check and balance to having someone do a malicious insider. Maybe not accidental, but certainly malicious. Meaning, I know someone’s requesting escalation of privilege, I have an audit for it, et cetera. So, at least I know about it. Ensure that your SIM, XDR, your EDR system, whatever it be, has anomalous logging detection. And oh, by the way, alerts for log deletion. I mean, that’s a big thing and it should go to somebody. It shouldn’t all go to the same person. So, that notification can be an email generated to another manager.

Again, even if that manager does not have the technical acumen to be able to do that job, they’re being alerted that that activity has happened. It’s now an escalation point and someone can ask what’s going on here. So, even if the person’s non-technical, you still need to have somebody else in that separation of duty that can be a check and balance on your one to three man operation, so that anomalous activity is at a minimum being alerted and investigated. That could be through a third party, an MSP or MSSP. It could be through software. Let’s say you have CrowdStrike, you tune that up and you have an escalation path to other people in the organization. So, that anomalous based behavior is looked at and is queried.

And so, you’re marrying separation of duties, anomaly-based detection, and third-party checks. And oh, by the way, escalation of privilege, at the highest level, has to be approved by yet another person. So, even two global admins need to approve each other’s activity. So, if you have two GAs, one GA can’t just arbitrarily escalate their own stuff. They have to seek permission to have that authorization escalated.

Cole French:

So, another aspect of that that you can add on to what you just described is rotating duties. So, if you’re a really small organization and you have an administrator in a specific administrative role, rotate that person, so you have two or three people every six months who are changing out these roles. Now, that can be a little tricky, because it requires folks to have different skillsets potentially. But I mean, if you’re a small organization, you’re kind of already relying on that anyway. So, we’ve worked with organizations that have done just that, that they’ve had each of their admins swap out duties every six months.

Terry McGraw:

That’s a great idea.

Cole French:

Yeah. I would say doing that, along with what you just described, would really cover this for a lot of those smaller organizations that are looking like, how can I actually address the problem of making sure that I don’t end up in an insider threat and keys to the kingdom scenario inside my own organization?

Terry McGraw:

Well, along with that, too, and you sparked my memory on this and talking about rotation. You should on a regular basis also be rotating your Kerberos infrastructure, as well as your passwords. By the way, Kerberos, part of Active Directory authentication has a memory of two. So, even if you reset it, if you reset it once, it still has the previous instance and the current instance in memory. So, you want to do a double tapping Kerberos every time you rotate it. So, you should, and not only when you’re enforcing password rotations... I think passwords by the way are a delusion, but it’s a little separate topic we can get into. But in the authentication piece, having the Kerberos reset as well. People often forget that.

So, not only are you rotating duties, but you should also rotating credentials and the mechanisms by which the systems authenticate to the servers. And that ticket granting service gets reset as well, so that an adversary can’t use an older Kerberos ticket to still get inside the environment and compromise it. So, you should be rotating that as well. I failed to mention that as part of a best practice, but I want to make sure I touched on that. But sort of tangential to your rotating of duties, which by the way is a great idea if you have no other solution. The only other thing I would add as advice is it is the business owner or the business operational wing’s responsibility to ensure that the well orchestration of their company and managing their business includes the risks of that business, which also includes the cybersecurity risk.

And the onus is on the operational wing of the business to mitigate risk, not the cybersecurity folks. Don’t make your CISO the enemy of the CFO. Operational folks need to understand that the greater threat to their business and the investments that are required to operate the business effectively. And my advice to the folks that are running the enterprise is to be part of the solution, not always look at it as a margin threat.

Cole French:

And if you want kind of a primer on risk assessments and what it looks like to conduct risk assessments, we did cover that a couple of episodes ago on the podcast. Now, to Terry’s point, it is more of an organizational thing. We do talk about that. The specifics of the risk assessment are more from a cyber perspective, but we did talk about it more from a holistic perspective and trying to get away from the... Within compliance, we have kind of a focus. We narrow our focus and think that risk assessment is just a cyber exercise. But in reality, it’s a business exercise, it’s an operational exercise, and it should encompass far more than just cyber. It should be anything that could happen to your business.

So, we definitely covered that topic. A couple of episodes to encourage you to check that one out if you want more on what it looks like to conduct or at least get started towards conducting a good, solid risk assessment for your organization. Terry, thanks again for coming on and recording this now, our third episode in this Cybercrime series. I really appreciate your perspective and always enjoy hearing what you have to say.

Terry McGraw:

Well, again, thank you for inviting me. It’s always a pleasure to do business with Kratos and the folks that you’ve brought to bear on this problem set. And I’m happy to join you anytime.

Cole French:

Thank you for joining us on the Cyber Compliance and Beyond podcast. We want to hear from you. What unanswered questions would you like us to tackle? Is there a topic you’d like us to discuss or you just have some feedback for us? Let us know on LinkedIn and Twitter at Kratos Defense or by email at ccbeyond@kratosdefense.com. We hope you’ll join us again for our next episode. And until then, keep building security into the fabric of what you do.