[unisog] Separation of Duties
stasinia at msoe.edu
Tue Jul 10 13:05:53 GMT 2007
I have to fully agree with Paul here. The real solution is not to move
management of systems to a different group, it is instead to train the
engineers how to properly do access management.
A simple example, if a user needs a change made (access granted, setting
changed, etc) their first step is to contact the helpdesk. The helpdesk
will take care of documenting the request and verifying the identity of the
requestor. Then a ticket will be send to the group most appropriate to
making the change (for instance the application engineer).
This would ensure proper auditing of all changes. Plus it will lessen the
amount of bureaucracy required to process a request. The same thing can be
done for turnover. When a change needs to be moved from development to
production, the engineer uses an electronic change management system to log
Now (speaking from experience) making application engineers actually follow
procedure is not the easiest thing in the world. It requires that top
management buy into the strategy and enforcement of policy compliance at
each level of management.
But the benefit is very much there. This methodology will greatly cut down
on support request turnaround time and lessen the amount of errors and
Hope that helps,
From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of paul wehner
Sent: Monday, July 09, 2007 2: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
Applications engineers need elevated access to maintain services and
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
unisog mailing list
unisog at lists.dshield.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3192 bytes
Desc: not available
Url : http://lists.sans.org/pipermail/unisog/attachments/20070710/262f380e/attachment.bin
More information about the unisog