joeware - never stop exploring... :)

Information about joeware mixed with wild and crazy opinions...

Do we need a "Read-Only Administrator" Security Group?

by @ 6:21 pm on 6/9/2007. Filed under tech

It seems the last couple of weeks have been heavy security weeks for me. Dealing with all sorts of security issues that quite frankly, never should have been issues to begin with but I think the knowledge level of Windows Security and how Windows works[1] is so poor in general that stupid things that never should be an issue grow to be huge issues. Hearing about the issues in the first place can be bad. It can be absolutely disheartening when you dig in and start getting a real feel for how bad it really is and realize it is industry wide. There are few people who are truly good with Windows core functionality understanding and security.

So anyway, through all of the stupidity and lack of true understanding of how things work I thought once again how nice it would be to have a “read-only administrator” group. I used that name only to give a quick functional understanding of what I am trying to describe. Basically a group that when you are placed in it, you get all of the ability to SEE/QUERY/VIEW/BROWSE anything an administrator of that machine would be able to SEE/QUERY/VIEW/BROWSE but no opportunity at all to make a change. Maybe call the group something like “Auditor Admin” or something like that. I really don’t care a whole lot about the name, I just need that functionality. In some places it may be more fitting for that to be several groups so you can granularly assign it but I don’t mind just starting out with a quick basic do everything an admin can do but change things to get started.

Some things right now you can set up this sort of access, say you want to look at service status or settings or you want to look at but not be able to muck with event logs, these things you can do with delegation. Depending on how the delegation is done, you may or may not be able to use standard tools to look at the info. Also I guess it depends on the tool, any tool that assumes that if you want to do that you also need to be able to change something so tries to grab that right or just tries to do it and then fails wouldn’t be much help in this situation. Not everything can be delegated this way though, there are various API calls that just won’t work unless you are an admin. Even if it could, I would still like this one stop shopping group so I could quickly throw someone in it and not have to think, ok so how do I delegate every one of these single individual things because this person truly just should be an admin without the ability to make changes…..

Why would this capability be good? Well I would hope it would be self obvious but if it isn’t, it is so you can give the group membership to someone who needs to be able to see anything an admin can see (like an auditor or maybe a senior level consultant/troubleshooter) but you absolutely, positively, don’t want them changing a thing. Auditors are a good thing, auditors who actually have a clue about Windows when they are auditing Windows is an even better, actually a great thing. In general though, I think you are asking for a lot if you expect them to know Windows but they still think they need to be able to look at everything on a system to make sure that “the admins” are being good even though even if they do look at anything they can’t properly judge what it all means since they don’t actually truly understand the environment and how it works.

Additionally, the only way many of these auditors feel this can be done is to put them in the admins group because that is all they know. First off, there is a huge issue there… They are no longer an independent arms length variable in the equation… now that they are in the admins group, they are just like the other admins who need to be watched, having auditor in their title doesn’t alleviate that and in fact, I would argue they need to be watched closer because they aren’t responsible for the server they have the rights on and almost certainly don’t have the knowledge or understanding to fix anything they accidentally break and are, IMO, more likely to break something given their lack of understanding. Giving auditors admin access to a server is not only a bad idea, it is a terrible idea from this standpoint. If someone says I need to be able to see something, the answer shouldn’t be, “all right then, I will make you an admin, cheers!”. Anyone who goes straight to that answer probably needs to be off in another job.

I mentioned this problem space when I was out in Redmond at the MVP summit to the folks in charge of monitoring and writing up the Service Modeling Language as I think that would be a good angle to attack it. Monitoring in large orgs has the same type of issue, for instance you want to use one standard monitoring group to save money, but you don’t want them having admin rights on every single server do you??? They are people who are supposed to be watching for problems, not the people who should be configuring the servers and causing their own problems. If you have a large org with thousands of servers you could have 3,4,5 or more entirely unconnected different server support groups responsible for different groups of servers. To do it safely/securely right now, you need a separate monitoring infrastructure for each group that is run by that group. Otherwise you bite the bullet and say well the monitoring people have admin rights across all of those servers. That means a screwup in monitoring could hit all servers or a virus on a monitor server could hit all servers… When was the last time you saw a dedicated monitoring group who truly understood the platforms they were monitoring. I haven’t met someone like that yet for Windows. At best they understand their monitoring software, everything outside of that is up for grabs. And you just made them admins on all of your servers…

When I spoke to the Dev teams in Redmond I said this would be great for Longhorn, LHR2, etc. But the more I think about it and the more pain I feel because of it not existing already the more I think this would be a great Security Initiative thing for MSFT to work on and get into the current products as well as future products ASAP. Say XP SP2, K3 SP2, Vista and anything newer should all be able to have this capability. Primarily I want it on the server OS but I know a lot of folks who would likely want it on the client OS as well. That being said, I have little faith something like this could be done in any short period of time and I think we would be lucky to see something by LH R2.

 

Now don’t go away disgusted and thinking, well if we can’t do it that way, well we just aren’t going to do anything right, we will just assume full admin rights and write everything around doing it that way. Way bad idea. How about instead trying to do everything with as minimal rights as possible and then fully documenting the things you find that you can’t do with a normal user ID and then work with others to see what can be done about fixing that. Any security team or auditing team or developer group that thinks, “well we will be running as administrator or LocalSystem so we don’t have to worry about how we gather the info” is someone who should strongly reconsider their stand or someone that management should strongly consider repurposing.

 

So what do you think?

 

   joe

 

[1] Knowledge of which, IMO, is a prerequisite for having any ability to say you understand security for the platform.

Rating 3.00 out of 5

Comments are closed.

[joeware – never stop exploring… :) is proudly powered by WordPress.]