Fundamental Segregation of Duties 320



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • That’s easy. If you read section 404 in SOX (this is the section that supposedly impacts IT the most) it states that you must have documentation of internal controls. Loosely described, an internal control is any repeated process used for business reasons. Hence, the process for something as simple as moving a computer from one desk to another can be described as an internal control. Audit companies are using this ridiculously vague wording to their advantage by applying it to everything. The same goes for segragation of duties. Do you really think the Sarbanes-Oxley act, created to stop future Enron situations, was intended to stop software developers from troubleshooting production issues? I know. Im going to hear from some moron who would tell me that this is the way they can ensure that IT is not spending money for nothing and all changes and the like are requested and approved and blah blah blah. Ive heard all that crap before. So in this way, the company will end up pissing away god knows how much money on idiotic unnecessary processes instead of just fixing the problem.
    Now that I am off my soap-box, why auditors are coming up with all this is 2 fold:

    1. Due to the vagueness of the Act, they and/or the SEC can apply it to anything.
    2. It’s a great way to rake in a TON of money if you’re an audit company.


  • I’ll come back to you on this as I don’t have the time to give your question the attention it deserves. It appears that you understand most of the risk/control issues but disagree on the practicalities/realities. That’s fine, I can understand where you’re coming from.
    Generally my experience has been that this ‘gap’ is not insurmountable but the problem is often one of communication. Auditors do speak a different language to developers and sometimes do not understand IT.
    For the record, I’ve been on both sides of the fence on this one. I’ve been an auditor but have also been responsible for systems development projects.



  • OK, here’s my more detailed answer. Let me start by saying that in security and control there is always a trade-off between security and useability - the only completely secure system is the one that’s still in the box and therefore completely unusable. With that in mind there are always areas for debate and there is not always a ‘right’ answer. That said, with my auditor hat on we are basically looking to rely on controls over and within certain systems to support the validity of the financial statements.%0AIn very simple terms this boils down to two questions.%0A1. How do we know that the system works%0A2. How do we know that it continues to work%0AThe first is mostly answered through either the systems development lifecycle or systems selectionprocess being controlled and ultimately being subject to UAT and approval.%0AThe second relies on their being ‘good’ controls over systems development and/or system upgrades. Focussing on the development side of things auditors are taught that the ideal scenario is that an IT shop will have 3 environments - development, test/intermediate and production. Programmers will work predominantly/only in development and on completing a change will have it transferred into test. Within test the UAT will be perfromed and on approval the change can be transferred into production - by an operator. %0AObviously the ideal world rarely exists and the challenge is how do we deal with this whilst keeping the control principles intact? This is usually a resources issue - both people and kit - and there is no simple answer to that. %0AThe question of a fundamental segregation of duties was just my chjoice of words in response to a previous poster, however auditors are/should be guided by frameworks such as CobIT which documents control principles and practices in relation to systems development.%0AFrom a control point of view let me ask you a question. If a programmer can make changes directly in the production environment how can we assure the integrity of that environment? What stops you making unauthorised or untested changes? What stops the disgruntled employee from completely messing up the system out of spite?%0AIn relation to your example%0A ust this week I implemented a data fix in financial system. It was tested in DEV and QA and approved by users. Logged in change tracking system. If I would be allowed to put it to UAT and PROD it would be already fixed in prod. Now we have to go over all this SAX circus and write installation doc for DBAs, write more robust setup script for uninformed DBA, explain them what are we doing, and the list can go on. I am not sure how they will act if something goes wrong in prod. How will they judge the situation or improvise. The QA is one week out of sync from prod so I cannot 100% guarantee nothing. I estimate it will be done next month and it will cost us much more person hours %0ATo me this is the correct way of doing things even if it is a pain. If there is an issue it is that your DBAs are insufficiently skilled. If you had access to prod what stops you from implementing a different change?%0AThere is always an exception to the rule as well - emergency changes. This normally means that if production gets completely messed up then the operators should be able to allow access for the developers to solve the problem with documentation being done after the event.%0AHope this helps.



  • If a programmer can make changes directly in the production environment how can we assure the integrity of that environment?’
    By change management process: peer code reviews, QA, UAT, approvals, audit logs, seniority and certification of personal, etc.
    ‘What stops you making unauthorized or untested changes?’
    And what stops DBA of doing these changes?
    ‘What stops the disgruntled employee from completely messing up the system out of spite?’
    Somebody has access to the system anyway. What stops other person better then me?
    ‘If you had access to prod what stops you from implementing a different change?’
    And what stops DBA from implementing different change?
    At major US corp I implemented system which was promoting code over environments by pressing a button. But it still can handle just simple cases. For complex one you still need a surgeon.
    Some changes you can really compare to surgery. Why would surgeon let nurse to perform a complex surgery just to assure director that he will not screw the patient?
    J.



  • ‘If a programmer can make changes directly in the production environment how can we assure the integrity of that environment?’
    By change management process: peer code reviews, QA, UAT, approvals, audit logs, seniority and certification of personal, etc.

    Not good enough. If you can make changes or promte changes into production then you can circumvent all of these.
    ‘What stops you making unauthorized or untested changes?’
    And what stops DBA of doing these changes?
    DBA or operator should not have access to development environment. Change management process should only allow them to promote QA’d, tested and approved changes from test.
    Somebody has access to the system anyway. What stops other person better then me?
    It’s not a case of them being better than you it’s a case of them being different from you. You have responsibility for making the changes they have responsibility for the live environment.



  • In the end of the day you might not agree with me but this is where your auditors are coming from. And they are not going to go away.



  • This issue is important to me right now, since I’m supposed to be figuring out exactly the same thing: how can we release code to production in a small group (5 people) without having app developers able to touch production systems? We don’t have enough bodies to segregate things that well.
    You can answer it should be the DBA putting code into place. But as was already pointed out, the DBA can mess with the code just as easily.
    The answer of:
    DBA or operator should not have access to development environment. Change management process should only allow them to promote QA’d, tested and approved changes from test.
    is problematic. I don’t know of a system that can enforce this when the DBA has full access to the database.
    And even worse, SQL Server doesn’t even seem to allow sufficient auditing to determine when the DB has been changed by sa in the general case.
    Also, who is doing the release to production of non-DB code? It doesn’t really make sense for a DBA to be doing this, as they have no knowledge about (for example) web programming.
    Any more thoughts on this will be greatly appreciated.



  • I can agree that if you are limited to only 5 people in a shop you are going to have problems establishing adequate segrgation of duties as in a shop that small every one has to be able to do just about every role when one or the other is on vacation, is ill, leaves or what have you.
    In this case, your challenge wil be in coming up with adequate compensating controls to provide assurance that what is in production is in fact complete, accurate and authorised. The only thing that comes to mind would be to maintain a complete, tamper proof audit trail of all changes made to production (data and software) and have an independent party (supervisor / business owner?) charged with reviewing it on a regular basis and following up on any changes that had not followed proper change control processes.
    If SQL Server does not have the capability to maintain such an audit trail (unfortunately I have no direct experience with it so cannot comment on whether it does or not) then you have yet another challenge and of course changes to non DB apps is another challenge for which there is no easy answer.
    I hope you find this answer useful as a starting point at least. Keep us posted on your progress. I for one am always interested in how others address challenges that we all may face from time to time .



  • Hm - it would be fine if you guys could establish a proper segregation of duties environment. If it’s not possibile, because resource constrains you should be aware of that sox’s ‘only’ talking of reasonable assura nce. So if you could persuade your CEO/CFO and your ext. Auditor that you have mitigating controls - maybe not in the IT environment but in the business line - that provide you with the resonable assurance your’re fine.



  • Thanks for the responses. My current proposal is that all code and object modules will be checked into the version control system by developers. It will then be released to the testing system by a developer, but the procedures will say that the only way to release it is to check it out from version control.
    Once the version on the test system is validated and the business owner signs off on the testing, the code will be released from version control to the production system, again by a developer.
    The mitigating control I’m proposing is that the code in production can be automatically compared at any time against the code in version control, and can be validated as being identical to the code that was tested. If it is changed in any way, the comparison process will show the exact file and lines that were changed. Since there is a record of which developer had access to perform the installation, it will be clear that it was either that developer or a non-developer user with access to the system (like a network admin).
    Since the code in version control has records of exactly what changed, when, and who checked in a change, I would think this would meet auditability requirements.
    I’m hoping that is sufficient to be compliant.



  • Sounds reasonable Brett.



  • I would agree. I would consider that as sufficient.



  • Brett;
    Sounds reasonable, a few questions come to mind though.

    1. What mechanism prevents a developer from moving code or executables to production outside of your version control?
    2. How often would the automatic comparison of code and executables be run? And what would be the procedure followed in the event a difference was discovered?
    3. How solid is your record of who actually accessed the production system to implement a change? Can the audit trail be erased or altered by anyone?
      A few things to think about.


  • Sounds reasonable, a few questions come to mind though.

    1. What mechanism prevents a developer from moving code or executables to production outside of your version control?

    Nothing. Of course, nothing would prevent whoever does the move to production from substituting different code. That’s why it would seem to be a good solution to be able to verify at any point that the production code matches the test code and matches the dev code. I think this solution is would be desirable even if we had separate developer and application release roles.

    1. How often would the automatic comparison of code and executables be run? And what would be the procedure followed in the event a difference was discovered?

    Good point, I’ll need to make sure the procedures cover that.

    1. How solid is your record of who actually accessed the production system to implement a change? Can the audit trail be erased or altered by anyone?

    We will have event logs of who logged in (this is a Win2K server). If we configure security properly, the person releasing to production should not be able to modify or erase the event log. Of course, the hardware/OS administrator can always erase the event log, but there is no way to avoid this possibility on a Windows server, as far as I know.
    Thanks for pointing this out, I’ll need to make sure this is the way it is configured.



  • All,
    I’ve been following the thread and have some questions/comments. I’m in a small shop of two, manager and myself. I’ve been requested to make my documentation SOX compliant. I’ve been visiting site like this one to get an idea of what that means. For example I have written several commission systems. How do I make documentation SOX compliant?
    From read this thread and others I’m getting the understanding that the end user of the system would need to add verbiage to the document stating how they tested the application and the level of accuracy.
    Would appreciate any insight
    Thanks,
    RC



  • I just left a client that had the same issue with segregation of duties as regards the implementing and making changes to production systems.
    Due to the small size of the IT staff we all agreed that if the business puts in place a mitagation that will consist of the review of any changes that are made by anyone in the IT department then they would pass. The IT department then created a daily exception report that list anyone who had made a change to any of the production code. The report is generated each day and is forwarded to the VP of IT and the CFO for review.
    Let’s face it not all IT departments are going to have 100 people running the operations. Sometimes as an auditor you have to work with the client in finding solutions. Not nail them and force them to make changes that will reduce the overall revenue of the client.



  • Sarboxian05,
    Due to the small size of the IT staff we all agreed that if the business puts in place a mitigation that will consist of the review of any changes that are made by anyone in the IT department then they would pass.
    Does that mean creating an online document that the IT Director would look at everyday and approve or not the production modifications? Lets say the IT modification/solution is what the end user wants but for what ever reason it doesn’t pass the IT director smell test for SOX (what will he be looking for?).
    What is the ultimate goal in being SOX compliant from an IT perspective?
    Any insight would be greatly appreciatated


Log in to reply