[unisog] Separation of Duties

Trevor Odonnal trevoro at byu.edu
Mon Jul 9 20:06:58 GMT 2007

Perhaps I should clarify #4.  This isn't meant to be a removal of
privileges to the server or application.  Rather, it is a removal of the
right to GRANT or REVOKE privileges on production systems.  The right to
grant or revoke privileges is a job function that has been assigned to
the Operations Account Management group.  Once the proper privilege
level is determined for the engineers, those privileges are granted by
the Account Management group when the server is placed in production.
If an engineer needs higher than usual privileges in order to handle an
emergency, our 24/7 on-site operations team has the ability to grant the
privileges in a matter of seconds using a documented procedure to
maintain accountability.

Thanks to all for your responses so far.

Trevor O'Donnal CISSP, CCFE
Network Security Analyst
Brigham Young University
(801) 422-1477
trevoro at byu.edu
-----Original Message-----
From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of paul wehner
Sent: Monday, July 09, 2007 1:01 PM
To: UNIversity Security Operations Group
Subject: Re: [unisog] Separation of Duties

1 through 3 are prudent and reasonable, in my opinion.
Implementing #4 as stated, will remove efficiency and will likely cause 
needless polarization.
Applications engineers need elevated access to maintain services and 
resolve issues.
If you deny that you'll have multiple problems with unclear resolution 

Taking this into my area- #4 seems to be saying that whenever a user 
wants access to a calendar or departmental mailbox they will contact the

application person (me), usually via the helpdesk, and I must then 
forward the request to a security person who may not have any idea on 
how to permission in oracle,sendmail, exchange, etc.
So a simple request hits three groups and winds up in a work queue of a 
person who may or may not know how to resolve and who may or may not see

the request as a first priority job requirement. (I assume a university 
IT security person has more important time constraints than making sure 
a calendar is visable to someone).

I think a better approach would be to focus more on auditing access 
rather than removing privileges.

Paul Wehner, Email Administrator
OIT Messaging Services Team
University of Notre Dame 

Trevor Odonnal wrote:
> Hello all,
> Here at BYU we are looking at a possible solution to an issue that has

> been a problem for some time.  Currently our development, staging 
> (testing), and production environments are more or less mixed 
> together.  This means that the engineers (server, software, and 
> database) have the same authority and access to production systems as 
> they do to development and staging systems.  This has led to an 
> ongoing problem with separation of duties.  Lately there has been an 
> issue with Engineers handling access control and security functions 
> instead of the Operations Security team (of which I am a part).  We 
> have suggested to upper management the following:
>    1. Separate Development, Staging, and Production environments into
>       separate subnets.
>    2. Separate Development and Staging authentication trees from the
>       Production authentication tree.
>    3. Allow Engineers the right to maintain and manage security
>       functions in the development and staging environments as they
>       see fit.
>    4. Once a server, platform, or application has been fully tested
>       and placed into production, all security functions and access
>       control will be managed solely by the Operations Security and
>       Account Management groups.
> The idea here is to maintain a level of accountability and separation 
> of duties in the production environment.  I have been given the task 
> of locating any other universities that may have put such a strategy 
> in place and open a dialogue with them to determine how this change 
> might affect us here at BYU.  Is there anyone on this list who has 
> implemented a similar strategy to the one I have described above that 
> would be willing to share their experiences with us?  Thanks in 
> advance to all who respond.
> Trevor O'Donnal CISSP, CCFE
> Network Security Analyst
> Brigham Young University
> (801) 422-1477
> trevoro at byu.edu
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

unisog mailing list
unisog at lists.dshield.org

More information about the unisog mailing list