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.orghttps://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