SOD and developer access to production 1596



  • I am currently working at a Financial company where SOD is a big issue and budget is not 😉 . Previously developers had access to production and could actually make changes on the live environment with hardly any accountability. All that is being fixed based on the recommendations from an external auditor.
    My background is in IT auditing (primarily for Pharma) and I am helping them in the remediation process (not as an internal auditor but as an Analyst so my powers are somewhat limited).
    They have decided to split up what used to be a ops and support group into 2 groups…one the development group which will include the application developers and they will have no access to production and a separate support group (that will support all the production applications) with a different set of developers, admins, dbas etc. This also means that no one from the dev team can install anymore in production. I agree that having different Dev. and Support teams is consistent with SOD.
    However, what I feel is key is that developers or anyone for that matter (be it from the support team or the dev team) should not be able to change production code, that code should be under version control and in a lock-down state, any changes should be routed through the proper change control procedures. I think in principle they accept this but I am yet to see any policies and procedures around the CM process. They are planning to implement this SOD policy in the first week of july and my fear is that they might not have gotten it right and this will eventually affect production support. I mean it is a significant culture shift. I am more in favor of a staggered approach instead of just flipping the switch one fine day.
    My question is while having separate dev and support is consistent with best practices and SOD where does it say that the application developer (or someone from the dev team) cannot make app installs in production if the whole process is well documented and privileges are revoked after the fact? I feel to be able to truly segregate the duties and roles of what used to be one big group where each sub group was a specialist of their app and supported is right from dev to prod will require good installation procedures, training and most importantly time. I just have an issue with them trying to implement this overnight (primarily based on some pre-set milestones).
    All their new policies (in draft) have this in bold ‘Developers are not allowed to install in production’…it should really read ‘Developers are not allowed to MAKE CHANGES in production’. I am trying to fight it but my clout is limited so I am trying to dig up any info that would back my case (i.e., a staggered implementation of SOD and Yes a developer can install in production if proper policies and procedures are followed). BTW, they are following COBIT and I have been trying to explain to them it is just a framework and there are no specifics about SOD it is just about implementing industry best practices. As far as I know Cobit just says SOD is an effective control there is nothing more specific.
    I would appreciate your input/thoughts/help. TIA



  • I’ll share some quick thoughts on this:

    1. COBIT 4.0 represents the latest recommended version of standards with 3.0 being the minimal acceptance level currently.
      isaca.org/Template.cfm?Section=COBIT6
    2. I also favor gradual implementations of change with pilot testing 1st and a good communications / training approach for all involved.
    3. Developers should be restricted, but if they need sensitive production info to solve problems in a read-only mode, then logging can be employed.
    4. Good policies, standards, and procedures help define the ground rules and are worth bringing up-to-date as needed.
    5. You might consider ‘Fire IDs’ or special libraries for emergency fixes to production (with extensive logging). You can then use Change Management controls for routine promotions to production.
    6. Most folks are ethical, and better controls are primarily to prevent accidential changes or to keep the rare unethical person from succeeding if they attempted to do something wrong.
    7. To answer your question, it is best to have a separate development and production support areas, so that you employ autonomy controls, separation of duties, and track all changes precisely. Change management software can help facilitate this process well.
    8. The policy might also be need adjustment for the installation of packages or could also read ‘Developers should not install or change the production environment, unless permission is granted by management in writing (email)’ to allow some flexibility as needed


  • Hi,
    I agree with Mr. Waldron. His point noted in number #6, effectively introduces the control environment and anti-fraud aspect of IT developer roles and responsibilities.
    Anti-fraud controls includes effective segregation of duties and it is generally accepted that vulnerability to fraud increases when roles and responsibilities are not adequately segregated.
    Specifically, PwC identifies the following scenario relating to fraud risk and SoD when considering the roles and responsiblities of the IT Developer function:
    ‘Controls over program changes are a common problem area in financial statement fraud. A classic fraud triangle, for example, would include:
    (1) incentive: programmer’s compensation is rewarded by business unit, business unit compensation is rewarded by meeting revenue goals,
    (2) opportunities: weak program change controls allow developer access into production and
    (3) rationale: programmer follows instructions and does not question the ethical merit of the business unit leader’s change request it is not his/her business.’
    Because SoD is an example of an anti-fraud control, covered in the higher level ‘environmental level controls’ or ELC, it might not be specifically addressed in the CobiT resources. However, it is covered under the anti-fraud controls as noted in the example above.
    Hope this further helps,
    Milan



  • Thanks Milan and Mr Waldron. I am not against the separation of dev and support teams… I am just against them trying to implement this overnight without having piloted it. I just want to be able to convince them that its ok to have the developers do installs in prod while support ramps up and gets trained as long as the process is controlled.
    To give you an example of how they are trying to implement controls on the pretext of SOX…Most of the teams use Quality Center for managing the testing cycle right from reqs. to scripts to defect logging…now on the pretext of SOX they want the teams to start Req Pro and Clearquest for requirement and defects…the rationale…they provide better sequrity (i.e., a developer cannot close or delete a defect). Also to facilitate all this they have built custom links between Req Pro and Quality Center and back to Clearquest. Most teams now have a dedicated resource just for ensuring/managing the flow of info between the different systems. I ask where in the world did SOX suggest this. I have audited/worked for companies that use excel sheets for requirement and defect tracking…not even auditable excel sheets but simple excel sheets and they have procedures around who opens a defect and closes them. If it works for other SOx compliant companies why are they unnecessarily creating extra work and complicating processes that dont need to be…I just joined this place 3 weeks ago and am still trying to find out who the drivers of these utterly ridiculous policies are.



  • Hi Val - You share good points, as introducing ‘too much change’ at one time can create confusion and inefficiencies. You can still make major changes, as long as there’s good communications, training, and a solid support system to help in the transition.
    As I stated earlier, I’m a firm believer in pilot testing and maybe the approach should have been to pilot this for one system for a few weeks to ensure security, software, linkages and other components are all ready for prime time.
    It looks like it may be too late to adjust now, as you’re going live very soon. However, if you run into difficulties with the new system, you can always fall back on your current approaches in an emergency mode (e.g., where developers could be granted temporary access on an emergency basis to move items to PROD). So, I would keep that idea in reserve in case Murphy’s Law surfaces 😉
    Rational’s ReqPro and Clearquest appear to be good tools for work flow and change management controls. These tools might offer collaborative and communication benefits among team members and management in the new process. Although, as noted sometimes the ‘Keep it Simple’ approach will do the job just as well and be understood better by all.
    Hopefully the designs will hold up and that implementation will go smoothly. Good luck to you all - Harry 🙂


Log in to reply