[unisog] Separation of Duties

Phillip Maddux II phillip at fiu.edu
Wed Jul 11 13:17:52 GMT 2007


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/c6083fb8/attachment.htm 


More information about the unisog mailing list