Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: What’s the Deal with Service Accounts?
Quick Take
On this episode of Compliance Unfiltered, The CU Guys dive into the often-overlooked world of service accounts. They explore the critical role these accounts play in organizational environments, ensuring seamless communication and authentication across systems.
Adam shares best practices for setting up service accounts, including the importance of descriptive naming and secure password management. The episode also features cautionary tales from the trenches, highlighting common pitfalls and the importance of proper documentation and controlled testing.
Tune in to learn how to enhance your organization’s compliance and security posture by giving service accounts the attention they deserve.
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process.
Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the ricky ticky tabby to your compliance cobra, Mr. Adam Goslin. How the heck are you, sir?
Oh, you know, just trying to, just trying to thaw out over here. Yeah, man, we’re getting, we’re getting some real entertaining weather, if you will. So, um, yeah, we’re, we’re supposed to be, uh, later, later this week, dropping down to, oh, I don’t know, uh, in the morning, it’s supposed to be zero or negative. Yeah, yeah. It’s, uh, it’s going to be awesome.
And I don’t think that doesn’t sound like fun. Yeah. I don’t think we’re seeing freezing for about two weeks. So yeah.
It’s a good time. You know, what’s interesting is that most people, when they hear someone say, I don’t think we’re seeing freezing for at least a couple of weeks, that’s like a reprieve and they feel exciting about that, but you guys are on the opposite end of the spectrum. That’s a wild thing for someone from Southern California to hear about. So for you and for all of the others out there listening that may be impacted by inclement weather, stay safe.
We’re thinking about you.
Adam, as always, I just wanted to let folks know that we enjoy hearing from them and the feedback that listeners provide really is a stop that brightens our day. Any input on topics that they would like to hear about is something that we’re really excited to take in. So with that in mind, for those of you listening, if you do have something you’d like to share, a comment, a suggestion for a topic, your favorite recipe, let us know. [email protected] and we look forward to chatting about it on a future episode of Compliance Unfiltered. Well, today, Adam, we’re going to talk about something a little different, specifically something we haven’t chatted much about before. And that is service accounts. Why don’t you give the listeners a high level overview of service accounts and what they’re typically used for?
Sure. So in an organizational environment, the systems will use accounts for communication, for authentication to the network, for interaction between web servers and database servers or file servers and basically look at it as the accounts that the infrastructure or software within the environment is leveraging to be able to effectively communicate with other systems and other infrastructure and all that fun stuff. So service accounts is kind of a, it’s similar to your login when you come in in the morning and you log into the network, you put in your username and password and everything and then you can get to your email and get onto the network, et cetera.
Similar type of notion, but it’s an account that’s just used by the systems within the environment. So it basically, those accounts kind of keep things ticking, communicating, moving, all of that fun stuff within an organization’s environment.
Sure. Now, what are some of the things that listeners should take into account when setting these accounts up?
Well, you know, and this comes from, you know, from a year or three of, you know, kind of dealing with, you know, dealing with different organizations and, you know, and whatnot. Best practices as well, but, you know, just things have tripped across, etc.
But, you know, as an example, you know, typically with a user’s account, you would, you know, the different organizations have different methodologies, right? First name, dot last name, or first initial and last name, you know, type of a thing. And similarly, get into the habit of using descriptive names for your service accounts. So you actually know what these accounts are doing. With most accounts, there’s an additional field that will be providing, like, a description of what this account’s being used for. So you don’t need to get too wordy with the naming of the account, but you put detailed descriptions in, you know, against those accounts so that it’s really clear, you know. You got to remember, you know, a lot of times these accounts, a lot of times these accounts are set up and then people aren’t, you know, aren’t doing anything with them for extended periods of time. It may be years down the road and somebody’s come back in and going, well, what the heck is, you know, XGK42C user account doing? No clue. So it helps if you name them appropriately, et cetera, because what I’ve seen in some environments, like, well, what’s this being used for? Oh, let’s shut it off. Yeah. So sometimes it doesn’t end up well. You know, for those accounts, setting up long, complicated passwords, these are machine-based accounts. They don’t give a hoot about entering in a 50-character password, you know, scrambled, you know, scrambled barf. So, you know, set, make sure you set those to long, complicated passwords because no human is going to need to, you know, it should have access to the passwords anyway, but certainly not using them, you know, other than one-time, you know, one-time entry to go in and get those, get those set. You know, the other piece is making sure that you’re not capturing those passwords anywhere other than a break glass-style location. In that… I guess…
I want to take a second on this what the heck is a break glass situation
Yeah, okay, so the term goes back to, you know, when they would have, you know, an axe or, you know, whatnot, like this is a British department building and in the stairwells they’ve got, you know, axes or fire hoses or whatever behind glass, you know, where it’s like, hey, break the glass in an emergency, you know, type of a thing, you know, that’s kind of where the notion of a break glass, you know, location comes from. Basically, this is your holy moly, we’ve got a freaking emergency and we actually have to get a hold of this.
It shouldn’t be readily accessible to the, you know, to anybody within the organization. It shouldn’t be readily accessible to the users. It shouldn’t even be readily accessible to, you know, the administrators and whatnot. Basically, put it someplace that, you know, that, yep, you can go get a hold of it if you need to, but nobody should need to, you know, go and get a hold of that account in any of its credentials unless you’ve got to replace a system, go set up a new system, you know, et cetera, and, you know, in many cases, you know, just take the opportunity to go reset the password, a new, you know, type of a deal. So nobody should have access to those, you know, to those accounts. The part of the reason for that, and it’s kind of related to my next point, but part of the reason for that is that you don’t want anyone in the organization with a capability for being able to get to or see those accounts and to be able to masquerade, if you will, on the network as if they’re the system. You know, there’s various things that the organization can do, depends on how, what level of lockdown their existing infrastructure and technology will allow, but, you know, you may even take those passwords and the use of those accounts to a level where I should only ever expect this service account, let’s pretend it’s a web server communicating to a DB server, I should only ever see activity under that account between the web and the DB servers as an example. So, you know, set an alert if it’s, if all of a sudden the use of that account pops up over on my, you know, active directory, now you’ve got a problem. So, you know, doing things along those lines to basically lock those accounts down as best you can. And the next point that I was referring to is finally go in and make sure there’s a just make sure that you’ve set your settings for your service account so that they will not allow interactive login. And what that means is, you know, that you’ve got to do that setting from the, you know, over on the operating side, you know, if you will.
Well, tell us more about why you don’t want to allow interactive login.
Well, when you’ve got… So let me first explain. I’ll explain what is interactive login. So when I’m able to go to login in the morning and I put in my username and I put in my password and a multi-factor in and all that fun stuff, that’s what’s called interactive login. In other words, I’m able to enter the credentials from the command line prompts or from the interface prompts to be able to log in.
When you set an account not to be allowed to log in through that interactive login, it means that even if I knew the username and the password, then I would not be capable of authenticating to the network with those credentials from the prompt, if you will. And the reason for that is those accounts are only supposed to be used by systems. If you allow interactive login and somebody gets a hold of the credentials or over time brute forces the credentials, now you’ve got an account you’re expecting to be a machine-based account masquerading on the network. Oftentimes, these service accounts will have elevated privileges. They need to have the capability to make connections to all the tables within the database as an example to be able to support the web interface. So they often have elevated privileges on the service accounts, but to that end, when you go in and you set up your service account, only set it up with, use your same principle of least privileges. Don’t give it domain admin. If you don’t need domain admin, give it the permissions that are actually needed for the context of that service account. And again, locking it down as best you can, that’s the reason. So yeah, that interactive login part is important because you don’t want any circumstances where somebody can go and be run around on the network, but doing so under a secondary account, no different than the rules and regulations around not sharing your passwords with other users. The same premise would go for the service accounts as well. you
Hmm. All right, now this oughta be juicy. Any fun stories from the trenches of service accounts gone wrong?
service accounts gone right. It sounds like a new show that they should put out. When good service accounts go bad. You know, so there’s a couple of things that I’ve seen folks, you know, kind of do operationally, which led to issues, shall we say, you know.
In one case, there was an organization, basically the person that was going in and setting up the service account, this wasn’t done with any malicious intent, but it’s just the way that it rolled out, right? You know, we use Bob, you know. So Bob, you know, six years ago, went in and set up this service account within this organization. Fast forward, you know, just shy of six years and all of a sudden Bob’s left the organization. And of course, they go out and they trigger, you know, their normal unit determination activities, right? Okay, well, we’re going to go in, we got to pull, you know, all of Bob’s, you know, physical access capabilities, ability to MFA, we’re that they went about disabling Bob, all of a sudden, all their production systems just went boom. Why? Because when Bob was originally going in and doing the testing and whatnot, he was just using his own account to go in and do the testing and the validation of connectivity between the systems, etc., completely forgot about, you know, the notion of going back and resetting it to a true service account. And so, yeah, when they disabled Bob, then all of a sudden, everything just dropped to a screaming halt.
And it was interesting because everybody’s running around trying to figure out like, what the hell happened? What the hell just happened? You know, we got attacked, blah, blah, blah. No, somebody just dialed up Bob’s account and everything went boom. So, you know, in another case, you know, we were going through and, you know, helping an organization and come to find out that in there, the IT group had a password management system for accounts that they were leveraging for their day by day, but they also had all the service accounts were in there. So, theoretically, folks within the organization that would have the capability to truly leverage the power of masquerading as a service account had ready access to all of the credentials for the service account. So, it’s like, oh my God, you know, no, no, no, we, again, go back to the, you know, the break class notion, get them out of there, set them off to the side, whatever you got to go in and do.
I had another case where there was an organization that had, they had hard coded in the service account credentials unencrypted in like text files on the boxes where the service accounts were. Their thought process was, well, hey, you know, we want to, you know, if we ever need to go back in and, you know, go back in and access this information, et cetera, that’s where they chose to leave it. So, you know, again, don’t put the credentials on the actual boxes where the service accounts are being leveraged. Because, I mean, if the worst comes to worst, somebody ends up reaching the environment, getting a hold of that box, et cetera.
Well, guess what? You got the fricking service, the service account credentials are sitting right there and ready to use, you know, by the bad actor. So, yeah, don’t do that.
And then, you know, when I had another organization that was allowing interactive login on their service accounts, and they had named off these service accounts, just happened to name them off with a username that was commonly used in, you know, kind of in generic script kitty type attacks. And in doing so, they basically left this like high powered service account, just swinging in the breeze for, you know, for brute forcing by, you know, by attackers that were actively attempting to brute force the, you know, the service account because it was, you know, it was kind of coming up and available for them to go ahead and hit. So, you know, those are some of the, you know, kind of some of the fun stories about, you know, about service accounts, but, you know, it can definitely get entertaining. You know, a lot of times what I’ve found is that it’s not like the organizations are deliberately trying to do it wrong. They just really haven’t thought through how to do it right. And that’s generally, you know, what I’ll see within organizations is that, you know, it’s just a matter of kind of, you know, upping the game, if you will.
Sure, that makes sense. Anything else you can recommend for service accounts and their management in the environment?
Well, certainly, um, making sure that you’ve got documentation around, you know, uh, documenting everything around the use of your service accounts within the environment, things like, you know, where is it being used? What is it being used for? What devices are connecting to, to what devices? And it, the, that documentation may come in a number of forms. There might be a number of assets and, you know, for internally that can be used, but, you know, there may be pieces of it that are, you know, that are accessible through data flow diagrams, network diagrams, uh, but certainly putting together, uh, you know, a list of the, you know, a list of the, uh, of those service accounts, you know, the one thing that I recommend to folks is, um, when they go in and they’re doing so under a lot of security and compliance standards, there’s a requirement to do kind of periodic reviews of, uh, of inactive, inactive accounts that are on the network, et cetera.
And so one of the things that I’ll recommend to folks is when you go in to do the poll from, you know, from, from your repository of usernames, let’s call it active directory for the sake of this discussion, pull the full, the full list, everything in active directory, um, active deactivated, duh, duh, duh, duh, you know, pull the whole damn thing. And that way when you’re going in, you’re looking at it, you can run down the list. I can start kind of setting things aside. Okay. I’m going to take everything that’s not active. I’m going to set that over here. Um, now with the active accounts, now I can go through, I can do my reviews on users. Um, but in the documentation that you hold, you know, having those notes about, you know, these whatever eight accounts, these are the service accounts that we’ve got, and you’ve got all your documentation for the what’s and why’s and how’s and all that fun stuff, but that way there’s a constant evaluation. And one of the things that, that organizations are run into, especially is when they’re switching out systems, right? Um, you know, if I, if I were to switch from one platform to another reissue new service accounts, et cetera, but forget to go and sundown my old, you know, my old accounts, number one, I got the documentation, you got something there, you know, to, to be able to kind of back it up, uh, the act of updating that documentation when you’re making the new system will oftentimes trigger the, oh crap, we got to go turn that one down. But worst case scenario, when you’re going in and doing your, you know, your 90 day review of, of inactive accounts, now all of a sudden that service accounts going to show up with, Hey, you know, we haven’t seen activity on this thing in 90 days type of a deal. So, you know, there’s a lot of benefits to, you know, going through putting together that documentation, uh, you know, with it, within the environment and integrating it into your kind of day by day, you know, security and compliance life, if you will.
Um, you know, also I’d recommend putting together some detailed, you know, business continuity, disaster recovery type documentation, um, that, you know, get gives out lines of their, of those service accounts, or at least points to where that documentation would exist, you know, things along those of an integrating service accounts into your VCDR, uh, you know, documentation. Um, you know, where, where are the break glass locations that we may need an emergency, uh, you know, type of a deal. The last thing you want when you’ve got some type of a holy moly event going on, um, is everybody kind of looking to their right and wondering what do we do or where is this stuff or how do we block, you know, the, those are the types of things that you can smooth out, uh, with, you know, kind of putting some focus on service accounts as it relates to your, you know, kind of BCDR, you know, style documentation. That way, if you do have a holy moly event that you need to go in and go in and get addressed, excuse me, then you’ve got the ability to, uh, to, to go in and handle that emergency, uh, you know, far more smoothly, uh, as you’re going through it, so it’s a lot less stressful.
That’s for sure. Um, yeah, well, and the other thing is, is that, um, you know, organizations need to, uh, consider some controlled testing of, uh, you know, changing, uh, their service account credentials. Um, you know, I recommend, you know, do it at least once, uh, you know, so that you can go in and have some lessons learned, et cetera, but, you know, it’s a, uh, it’s an interesting exercise that I’ve seen a lot of the, you know, uh, a lot of the times when you go through and you say, okay, we need to reset the, there may be events that happen within the organization that force, um, the service accounts to be changed. So as an example, let’s say that the administrator that, uh, went in and initially set up the service accounts departs the organization. They at one point in the game had knowledge or access of the, of the, the values of the, of the credentials for the service accounts. So guess what, when they go ahead and leave the organization, now I’ve got to go through and switch those, uh, just in case they, they stored that information elsewhere, whatever it may be. And so, you know, there’s, there’s things that you learn. There’s a lot of lessons learned as you go through and do this kind of controlled, uh, you know, controlled, uh, you know, uh, swap over, et cetera. If you have the ability, um, to, you know, kind of set up your service accounts in a like, like fashion in sub environments, you could even use a sub environment, so your test or stage environment, whatever, to go through and exercise, to kind of exercise this test, making sure you have that diligence to have the philosophically, everything set up similarly in the production arena, uh, you can use a sub environment, so it’s quote, less risky. But at some point in the game, something’s going to come up where you have to go through and reset those service accounts.
So you may as well do it to controlled, uh, in a controlled, uh, you know, environment, uh, and do it in a safe space, um, so that you can, you know, just kind of make sure that you’re not in for any, uh, unexpected surprises, shall we say.
Fair enough. Parting shots and thoughts for the folks this week, Adam.
Well, hopefully, as the listeners are kind of listening to this, they’ll realize that this is an area that’s often overlooked. As organizations are making their program more mature, you consider putting some much needed attention into the service accounts within the environment, whether you’re listening in your organization subject to compliance or you’re listening and you are an organization that helps others with their compliance, if you will. These are good points to kind of bring to the table.
When you’re in, you’re doing engagements and trying to operate day by day. You really do not want to find out what you don’t know at the least opportune moment. I’ve watched a couple of organizations go through it previously. Boy, I’ll tell you, it’s not fun and it’s not pretty.
And that right there, that’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow, and I’m Adam Goslin, hope we help to get you fired up to make your compliance suck less.
