[unisog] Separation of Duties

Trevor Odonnal trevoro at byu.edu
Thu Jul 19 21:56:10 GMT 2007


Thanks for your time and reply.  Actually, I was able to find one
University that was doing things much the way we would like to.  We made
the case based on information you and others sent, and it seems to have
had the desired effect.  This very week there have been some changes
made in the Engineering department that are moves toward tightening up
this type of thing.  All of the responses I received were useful and I
thank everyone for taking the time to respond.

 

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: Tuesday, July 17, 2007 2:34 PM
To: UNIversity Security Operations Group
Subject: Re: [unisog] Separation of Duties

 


Trevor, 

Sorry for the delay, just now catching up with the list. Change control
has been successfully implemented in our academic computing area for
their primary application, which is peoplesoft. I'm sure there are other
areas were miscellaneous servers and applications do not have the same
level of change control. It sounds like you are talking about various
server and application projects, not necessarily an ongoing development
process like with peoplesoft. Regardless, developers having full control
like you say should never be the case, the exception would be a small
mom and pop shop, which I'm sure you are not. 

I might try to communicate to management that looking at what other
universities are doing is fine, but you may not find the verification
you are looking for - everybody's doing things differently. I would
argue that you need to rely on best practices and standards. You need to
take those best practices and standards and apply them to your unique
environment as best possible.  I know that can be a hard sell sometimes.


I'm not sure this reply helps much, let me know If you have any specific
questions. 

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/11/2007 11:49 AM 

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

To

"UNIversity Security Operations Group" <unisog at lists.dshield.org> 

cc

 

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
_______________________________________________
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/20070719/88086f9e/attachment-0001.htm 


More information about the unisog mailing list