[unisog] Separation of Duties

paul wehner pwehner at nd.edu
Mon Jul 9 19:00:30 GMT 2007


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 
responsibilities.

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



More information about the unisog mailing list