Fundamental Segregation of Duties 320



  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • This post is deleted!


  • 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.


Log in to reply