[unisog] Separation of Duties

Chris Green cmgreen at uab.edu
Wed Jul 11 21:20:30 GMT 2007


For our main administrative systems:

 

Developer -> QA -> Production

 

Development areas are pretty much self-coordinated with the development
group.

 

Code is moved into QA by a separate change control group, per
development instructions.   When testers have signed off on the QA
instance via, code from QA is migrated to Production.  In order to
facilitate troubleshooting, we allow read-only access to developers on
an as-needed basis.

 

System administration and DBA roles are more trusted currently.   One
our DBAs has worked in an environment where every production change was
scripted by a DBA and run by an independent person so there would be a
strong log of changes. 

 

From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of Trevor Odonnal
Sent: Wednesday, July 11, 2007 10:50 AM
To: UNIversity Security Operations Group
Subject: Re: [unisog] Separation of Duties

 

Phillip,

 

Thank you so much for your reply.  We have a change control process in
place.  Basically, the developers create the project in the development
environment.  Once the product is ready for testing, it is moved to the
staging environment.  There is no production level data permitted in
either development or staging.  (Of course, policy and reality are
always two different things as I'm sure you've experienced.)  Once the
product is ready for production, a change request is made to install the
new server if there is one, and install the software product.  As part
of the change order, developers are given the necessary rights to
accomplish the installation.  Once the installation is complete, only
the rights necessary for maintenance of the system are retained.  At
least that's the plan.  Right now, the developers (engineers) handle all
of the rights assignments for all three environments and have a history
of not relinquishing their privileges once the install is complete.  At
this point, the developers control all account management, logging,
access control, and server administration.  This has created a situation
where there is no accountability because we can't trust the log data and
any audit information we receive comes directly from the developers
since they are the only ones with access to obtain it.  We are totally
at their mercy.

 

So, this leads me back to my primary need.  Upper management is open to
change and even wants to implement it.  However, they would feel more
comfortable if we could find another university that has implemented
similar procedures successfully.  Based upon your reply, it almost
sounds to me like you have.  Is this a correct assumption?  Thanks again
for your time and help.

 

Trevor O'Donnal CISSP, CCFE

Network Security Analyst

Brigham Young University

(801) 422-1477

trevoro at byu.edu

________________________________

From: unisog-bounces at lists.dshield.org
[mailto:unisog-bounces at lists.dshield.org] On Behalf Of Phillip Maddux II
Sent: Wednesday, July 11, 2007 7:18 AM
To: UNIversity Security Operations Group
Subject: Re: [unisog] Separation of Duties

 


Hello Trevor, 

Have you considered implementing a change management solution for
applications? In our environment, with few exceptions, no developers
have access above the development environment. Above development we have
testing, staging, and production. The developer's code is distributed to
the environments via the change management software, so they don't need
direct access. A system like this plus audits are the ideal situation. 

As for your suggestions: 

1. I agree 
2. I agree 
3. Not so sure; who will ensure sensitive production data is not used in
those environments. If there is sensitive production data in development
and staging, then you have to consider them to be production equivalent
systems. Another point, you may want security team involved at these
levels so when it does hit production they already know the system and
understand its security requirements. 
4. I agree 

fyi: The change control system we implemented is CA's Allfusion harvest
(if that is still what they call it). 

Phillip Maddux II
Information Systems Auditor
FIU - Office Of Internal Audit
http://www.eng.fiu.edu/oia/
305-348-6969
phillip.maddux at fiu.edu 

While there is little disagreement as to the productivity benefits
emanating from this amazing transformation and more readily available
information processing technology, the necessary controls to manage and
protect the assets associated with the new environment have not been so
readily agreed upon, or for that matter, even considered. 

This situation makes the need for the IT audit function more critical
than ever, and at the same time more difficult than ever. 

- http://www.dof.ca.gov/FISA/OSAE/AudtGuid.asp 

"Trevor Odonnal" <trevoro at byu.edu> 
Sent by: unisog-bounces at lists.dshield.org 

07/09/2007 01:23 PM 

Please respond to
UNIversity Security Operations Group <unisog at lists.dshield.org>

To

<unisog at lists.dshield.org> 

cc

 

Subject

[unisog] Separation of Duties

 

 

 




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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sans.org/pipermail/unisog/attachments/20070711/6786b787/attachment.htm 


More information about the unisog mailing list