Protecting from Admins

Question, we have RMS installed, and have no problems where regular users 
are concerned. However, due to new industry regulations, we have to limit IT 
access to any RMS-protected docs. This means prevent them from making 
changes to the RMS config; preventing changes to the membership of the 
SuperUser group; auditing what changes are being made; etc.

Does anyone have info on how to secure RMS SuperUsers access from users who 
are normally Domain Admin or Enterprise Admin? From our review, basically 
any blocks we put in place, they can get around due to the high level of 
admin powers they have.

Thanks in advance for any thoughts/feedback/direction!
Marc 

How do you really limit an Enterprise admin from doing anything?

Let's say we were to lock down the RMS system, ACL the files so that only 
your RMS Admin account could do anything, audit and ACL the group etc.... 
There is nothing stopping the Ent. Admin from changing that users password 
and logging in as that user.

There comes a point where you do your security risk assesment, and say, "If

we can't trust the person we've given Enterprise Admin rights to, he really 
shouldn't be the Enterprise admin."

I can't think of any system that we make (or anyone makes), where if you are 
root, or Ent. Admin you can't do whatever you want, and circumvent anything 
you want to a member server. I suppose you could always use the missle silo 
method, where you have two guys that have to turn the key at the same time 
and both have guns in case the other guy won't turn the key (At least thats 
how it worked in the movie 'War Games', which I always found to be 
ridiculous, because if he shot the other guy..he still wouldn't be able to 
turn the key.), but I don't think there is any ready made solution that has a 
mandatory 'two users to accomplish one task' offering. (and it would have to 
be with smartcards or some other type of physical media (which had its own 
security structure of checks and balances to obtain)).

 

-Jason

"Marc Westbrock" wrote:

> Question, we have RMS installed, and have no problems where regular users 
> are concerned. However, due to new industry regulations, we have to limit
IT 
> access to any RMS-protected docs. This means prevent them from making 
> changes to the RMS config; preventing changes to the membership of the 
> SuperUser group; auditing what changes are being made; etc.
> 
> Does anyone have info on how to secure RMS SuperUsers access from users who

> are normally Domain Admin or Enterprise Admin? From our review, basically 
> any blocks we put in place, they can get around due to the high level of 
> admin powers they have.
> 
> Thanks in advance for any thoughts/feedback/direction!
> Marc 
> 
> 

This was our thought too, and was mentioned many times in our discussions. 
However, due to the regulations and how they define "need to know" and

"approved party" etc., IT does not fit. Any IT staff that could access
these 
files has to get a Secret Clearance from the government, and cannot be a 
'foreign national' by definition of the reg. 

So, even though we know we cannot prevent -everyone- from access, we are 
wanting to cut the list down as much as possible. If it comes down to only 
Enterprise and Domain admins, our list is fairly small and workable. However, 
we also have server admins, OU admins, and our Exchange Admins (since RMS 
relies on email addresses for rights). 

Thank you for your feedback, at least I can go back with an answer from a 
source other than internal, verifying our thoughts.


"Jason Tyler" wrote:

> How do you really limit an Enterprise admin from doing anything?
> 
> Let's say we were to lock down the RMS system, ACL the files so that only 
> your RMS Admin account could do anything, audit and ACL the group etc.... 
> There is nothing stopping the Ent. Admin from changing that users password

> and logging in as that user.
> 
> There comes a point where you do your security risk assesment, and say,
"If 
> we can't trust the person we've given Enterprise Admin rights to, he really

> shouldn't be the Enterprise admin."
> 
> I can't think of any system that we make (or anyone makes), where if you
are 
> root, or Ent. Admin you can't do whatever you want, and circumvent anything

> you want to a member server. I suppose you could always use the missle silo

> method, where you have two guys that have to turn the key at the same time

> and both have guns in case the other guy won't turn the key (At least thats

> how it worked in the movie 'War Games', which I always found to be 
> ridiculous, because if he shot the other guy..he still wouldn't be able to

> turn the key.), but I don't think there is any ready made solution that has
a 
> mandatory 'two users to accomplish one task' offering. (and it would have
to 
> be with smartcards or some other type of physical media (which had its own

> security structure of checks and balances to obtain)).
> 
>  
> 
> -Jason
> 
> "Marc Westbrock" wrote:
> 
> > Question, we have RMS installed, and have no problems where regular
users 
> > are concerned. However, due to new industry regulations, we have to
limit IT 
> > access to any RMS-protected docs. This means prevent them from making

> > changes to the RMS config; preventing changes to the membership of the

> > SuperUser group; auditing what changes are being made; etc.
> > 
> > Does anyone have info on how to secure RMS SuperUsers access from
users who 
> > are normally Domain Admin or Enterprise Admin? From our review,
basically 
> > any blocks we put in place, they can get around due to the high level
of 
> > admin powers they have.
> > 
> > Thanks in advance for any thoughts/feedback/direction!
> > Marc 
> > 
> > 

Protecting the network from the people running it, especially considering 
that the people monitoring the security of the network are the same people 
you are trying to protect it from is a difficult thing to accomplish.

Exchange Admins, and OU admins should have rights to add or remove people 
from this group. Just remove their ACLS from the group if they do. You can 
turn on auditing, but unless you are using 2008 which I hear has some cool 
auditing enhancments, you will get a log telling you X user modified this 
group, but not what they modified...and assuming that they don't go an remove 
the auditing log.

I'm not sure if you are aware of this or not, but everytime a super user 
opens a piece of content as a super user, an event is generated in the 
application event log. If I needed to know who was doing things with any 
level of confidence, I would probably create a mom pack that sent me an 
e-mail everytime a super user opened a piece of content, and then go validate 
those requests.

-Jason



"mwestbrock" wrote:

> This was our thought too, and was mentioned many times in our discussions.

> However, due to the regulations and how they define "need to
know" and 
> "approved party" etc., IT does not fit. Any IT staff that could
access these 
> files has to get a Secret Clearance from the government, and cannot be a 
> 'foreign national' by definition of the reg. 
> 
> So, even though we know we cannot prevent -everyone- from access, we are 
> wanting to cut the list down as much as possible. If it comes down to only

> Enterprise and Domain admins, our list is fairly small and workable.
However, 
> we also have server admins, OU admins, and our Exchange Admins (since RMS 
> relies on email addresses for rights). 
> 
> Thank you for your feedback, at least I can go back with an answer from a 
> source other than internal, verifying our thoughts.
> 
> 
> "Jason Tyler" wrote:
> 
> > How do you really limit an Enterprise admin from doing anything?
> > 
> > Let's say we were to lock down the RMS system, ACL the files so that
only 
> > your RMS Admin account could do anything, audit and ACL the group
etc.... 
> > There is nothing stopping the Ent. Admin from changing that users
password 
> > and logging in as that user.
> > 
> > There comes a point where you do your security risk assesment, and
say, "If 
> > we can't trust the person we've given Enterprise Admin rights to, he
really 
> > shouldn't be the Enterprise admin."
> > 
> > I can't think of any system that we make (or anyone makes), where if
you are 
> > root, or Ent. Admin you can't do whatever you want, and circumvent
anything 
> > you want to a member server. I suppose you could always use the missle
silo 
> > method, where you have two guys that have to turn the key at the same
time 
> > and both have guns in case the other guy won't turn the key (At least
thats 
> > how it worked in the movie 'War Games', which I always found to be 
> > ridiculous, because if he shot the other guy..he still wouldn't be
able to 
> > turn the key.), but I don't think there is any ready made solution
that has a 
> > mandatory 'two users to accomplish one task' offering. (and it would
have to 
> > be with smartcards or some other type of physical media (which had its
own 
> > security structure of checks and balances to obtain)).
> > 
> >  
> > 
> > -Jason
> > 
> > "Marc Westbrock" wrote:
> > 
> > > Question, we have RMS installed, and have no problems where
regular users 
> > > are concerned. However, due to new industry regulations, we have
to limit IT 
> > > access to any RMS-protected docs. This means prevent them from
making 
> > > changes to the RMS config; preventing changes to the membership
of the 
> > > SuperUser group; auditing what changes are being made; etc.
> > > 
> > > Does anyone have info on how to secure RMS SuperUsers access from
users who 
> > > are normally Domain Admin or Enterprise Admin? From our review,
basically 
> > > any blocks we put in place, they can get around due to the high
level of 
> > > admin powers they have.
> > > 
> > > Thanks in advance for any thoughts/feedback/direction!
> > > Marc 
> > > 
> > > 

Correction, Exchange admins and OU admins should *not* be able to add and 
remove users from this group.

"Jason Tyler" wrote:

> Protecting the network from the people running it, especially considering 
> that the people monitoring the security of the network are the same people

> you are trying to protect it from is a difficult thing to accomplish.
> 
> Exchange Admins, and OU admins should have rights to add or remove people 
> from this group. Just remove their ACLS from the group if they do. You can

> turn on auditing, but unless you are using 2008 which I hear has some cool

> auditing enhancments, you will get a log telling you X user modified this 
> group, but not what they modified...and assuming that they don't go an
remove 
> the auditing log.
> 
> I'm not sure if you are aware of this or not, but everytime a super user 
> opens a piece of content as a super user, an event is generated in the 
> application event log. If I needed to know who was doing things with any 
> level of confidence, I would probably create a mom pack that sent me an 
> e-mail everytime a super user opened a piece of content, and then go
validate 
> those requests.
> 
> -Jason
> 
> 
> 
> "mwestbrock" wrote:
> 
> > This was our thought too, and was mentioned many times in our
discussions. 
> > However, due to the regulations and how they define "need to
know" and 
> > "approved party" etc., IT does not fit. Any IT staff that
could access these 
> > files has to get a Secret Clearance from the government, and cannot be
a 
> > 'foreign national' by definition of the reg. 
> > 
> > So, even though we know we cannot prevent -everyone- from access, we
are 
> > wanting to cut the list down as much as possible. If it comes down to
only 
> > Enterprise and Domain admins, our list is fairly small and workable.
However, 
> > we also have server admins, OU admins, and our Exchange Admins (since
RMS 
> > relies on email addresses for rights). 
> > 
> > Thank you for your feedback, at least I can go back with an answer
from a 
> > source other than internal, verifying our thoughts.
> > 
> > 
> > "Jason Tyler" wrote:
> > 
> > > How do you really limit an Enterprise admin from doing anything?
> > > 
> > > Let's say we were to lock down the RMS system, ACL the files so
that only 
> > > your RMS Admin account could do anything, audit and ACL the group
etc.... 
> > > There is nothing stopping the Ent. Admin from changing that users
password 
> > > and logging in as that user.
> > > 
> > > There comes a point where you do your security risk assesment,
and say, "If 
> > > we can't trust the person we've given Enterprise Admin rights to,
he really 
> > > shouldn't be the Enterprise admin."
> > > 
> > > I can't think of any system that we make (or anyone makes), where
if you are 
> > > root, or Ent. Admin you can't do whatever you want, and
circumvent anything 
> > > you want to a member server. I suppose you could always use the
missle silo 
> > > method, where you have two guys that have to turn the key at the
same time 
> > > and both have guns in case the other guy won't turn the key (At
least thats 
> > > how it worked in the movie 'War Games', which I always found to
be 
> > > ridiculous, because if he shot the other guy..he still wouldn't
be able to 
> > > turn the key.), but I don't think there is any ready made
solution that has a 
> > > mandatory 'two users to accomplish one task' offering. (and it
would have to 
> > > be with smartcards or some other type of physical media (which
had its own 
> > > security structure of checks and balances to obtain)).
> > > 
> > >  
> > > 
> > > -Jason
> > > 
> > > "Marc Westbrock" wrote:
> > > 
> > > > Question, we have RMS installed, and have no problems where
regular users 
> > > > are concerned. However, due to new industry regulations, we
have to limit IT 
> > > > access to any RMS-protected docs. This means prevent them
from making 
> > > > changes to the RMS config; preventing changes to the
membership of the 
> > > > SuperUser group; auditing what changes are being made; etc.
> > > > 
> > > > Does anyone have info on how to secure RMS SuperUsers access
from users who 
> > > > are normally Domain Admin or Enterprise Admin? From our
review, basically 
> > > > any blocks we put in place, they can get around due to the
high level of 
> > > > admin powers they have.
> > > > 
> > > > Thanks in advance for any thoughts/feedback/direction!
> > > > Marc 
> > > > 
> > > >