I’d made the statement in my earlier blog that SOX is a lot about good, old fashioned security. Well, this is the beginning of reinforcing that statement, and illustrating how a SOX audit results can show you what needs to be fixed.
In a nut shell, a service does something. It can be as mundane and simple as executing a small program, or it can be as monumental as running a huge program. The service requires two things, a user name (often times self-generated or often times recommended in the install manual) and a password (usually anything we want). Often times it’s an active directory user accounts, sometimes it’s strictly a local account.
Point number two on the Bride of Dracula’s hit parade was the plethora of service accounts we had. We had one to run Exchange, another to run backups, one for this, one for that, and all in all it amounted to some 167 accounts. From where she sat, this was 147 too many.
And that was the tip of ice berg. Service accounts, whenever they’re generated almost always have elevated permissions and privileges. They need to be able to reach into systems, especially remote systems, and do whatever they need to do. Even local services will often times have elevated privileges. And this is what makes them so appealing to an attacker.
Here’s how this works. The attacker is more often than not, someone who has an ax to grind with the company (know anyone like that)? Now usually what they do is something like this, it begins in the mind. This individual, usually a systems admin with some really serious permission gets it in his or her head that they’ll be axed from the company sooner or later. So, what they do is go out and they identify an account, usually a service account, and then they elevate the privileges. What do they do? Oh maybe give it VPN access for instance or whatever the case might be. They do this because it gives them an advantage. First, it’s an ID that isn’t going to go away (after all, we need to that account). Second, the password probably isn’t going to change. Thirdly, no one’s watching. So right there we’ve a recipe for terrible things to happen.
So, his/her worst nightmare comes true, they’re indeed let go, and so in a fit of rightful vengeance (translation – stupidity), they come in and do something nasty to the network like dump data and etc.
What out auditor was really saying was that we were flirting with disaster. We had so many service accounts, they were all but impossible to police, some of them were local service accounts (and we had no clue in most cases what they did or even where they were). There was no formalized way to change passwords, and if someone did something with one, no one knew it.
So, how do you find the service accounts? First, someplace, somewhere, they need to be listed. A lot of folks use nothing more than a simple spreadsheet to do this. Word of advice her if this applies to you. This should be encrypted, the password to decrypt it should be given to only a handful of people, and you need to audit it as well. It might even be a worthwhile idea to maintain a couple of lists, those that the regular everyday sys admin might need, and then the super secret stuff we don’t want floating about.
A lot of people seem to have an issue or two with locking some of the people out of certain stuff. They say it’s about trust. And it should be. I’m not saying every sys admin out there is waiting to put the screws to you. What I am saying is there are some things you just don’t want everyone to know. As Spock told Harry Mudd, “The problem is I do trust you. But only to a point”.
OK, let me get off my soap box, and back to reality.
Before we dive into how to identify a service account, one thing you should know. Each and every service account should be IDed as such. There’s nothing wrong with putting in the description that this is a service account. Other times, some outfits will go out and construct a bogus user account, one that is in truth a sort of “Master” service account. Again nothing wrong with that, so long as you know it and have it annotated someplace, somewhere.
Also, it’s not unusual to have Active Directory Service accounts stashed away in their own OU. This makes administration a bit easier, not to mention just makes things look better from the general housekeeping perspective.
But if you don’t know where they are, Local Service accounts are really easy to find. One way is to use powershell. The command is really easy.
Your command is get-wmiobject win32_Service | format-table name, startname, startmode
You run this of course on a local system.
Now right about now, someone is asking how to find an Active Directory managed service account. Well, there’s the gag. You really can’t. The only way you’ll find them is going to your servers, and running the command I listed above. It’s a process of elimination, but one that works.
So, since these things are easy to subvert, how do we keep an eye on them?
Well, there’s a lot of ways. One is to keep an eye on things in Active Directory. Netwrix offers a great solution for AD audit, and one that will have your auditors falling in love with you. If you set this up right (in short it counts off for typos), every morning you’ll get an email report showing whatever changes that happened the day before.
The idea is this. Every change reported SHOULD be backed up by a corresponding Change Management request. Print the reports off as a PDF and tuck them away for your auditors. Do realize any gaps in coverage will have to be explained, so try not to lose any. If you do lose something, better draft up a Memorandum for Record (MFR). It’s one more piece of the eternal quest to cover our backsides.
Some folks will no doubt wonder if they could automate this process so they get printed off without human interference. OF course there is, but that kind of defeats the purpose of having the software in the first place. The idea is we have to look at it, and evaluate what the heck is going on before we ever file it away.
Next time, we look at events you might want to know about. Till then, have a great day.
