Segregation of Duties and User Empowerment 386



  • I’m still reading through the various threads, so apologies if something similar has been addressed. I found this site today and this appears to be exactly the forum I’ve been looking for.
    Situation:
    I work in an IT shop where we’re evaluating our current costs and looking at what we can do to reduce those costs. In our environment, we have disabled user accounts which are mailbox enabled and are used for team communications.
    Current process - a listed owner of those accounts can request that people be granted rights on those accounts (full mailbox access or ‘send as’ rights on those mailboxes.) If an owner requests it, the permissions are granted by an administrator. If the owner is not making the request, the owner must agree to this in writing. Each request generates a ‘ticket’ for the IT support group in charge, which is how the cost is tracked per request.
    Planned process change - IT wants to put in place an application (web page) which, through a read-only account to the authoritate database of accounts and owners, will display a list of accounts that an individual is an owner for. The owner will then have the ability to enter individuals that they wish to grant access to (full mailbox, send as) and submit the changes themselves through this tool. When the tool commits its actions, it will generate an entry in a database which will be backed up daily.
    Edit: While an account with read-only access would query the ownership data from an authoritative source, another account would be used to make the necessary writes to the Active Directory on the object itself, which is where the administrators make all changes anyway.
    My questions - Our SOX control group inside the company have denied similar tool suggestions in the past under SOX 404 and specifically Segregation of Duties (control 6?) but have never provided an explanation as to why this is a violation. What I’m looking to understand from folks who are more knowledgeable than I (read: you) is this:
    Based on the above, does our IT shop sound like it would be in violation of these aspects of SOX in a broad sense (or even a specific sense?) The tool itself is required to go through a security review process with internal security groups before it could be put in production anyway to make sure that proper logging and security protocols are provided.
    If I’m not asking the right questions or providing enough detail, please let me know as I’d really value any and all feedback on this.
    Cheers,
    ~John



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


  • You need to have a general IT control called User Management (Cobit and IT Control Objectives for Sarbanes Oxley; isaca.org). It sounds to me, that you have something like it.
    What you described looks like an IT application to simplify the use of ‘functional user accounts’ e.g. info_at_insurance.com.
    The question is: Does this have any impact on your financial statements or disclosures? If the answer is no you most likely won’t have a sox issue.



  • To be honest, I’m not really sure the full details of the controls we have. Our experience is that the team responsible for SOX frequently will deny similar applications without detail - the canned answer is that it violates Control 6. Segregation of Duties, etc., etc.
    To answer your question with regard to disclosure of financial impact: No, there is absolutely no modification to any enabled user accounts or data - only permissions on the mailboxes.
    That leads me to another question, though (randomizing my own thread, no less) - are the internal authors of SOX controls for a company required to keep the details of the controls secret, or are they allowed to share the controls and what they document? What our experience is is that we are denied when we try similar approvals above and are not given any detail as to the SOX controls themselves. We’ve asked specifically for the details of the controls so we can adhere to them (if they even impact us at all) and we receive silence.
    If they’re daft in their handling of this, it’d do my mind good to know 🙂
    Thanks for your response, holger, and I appreciate any others that might be able to chime in.
    Cheers,
    John



  • Control 6 must be something specific to your organisation - although Segregation of Duties is a key concept.
    Your controls do not need to be kept secret. other than in line with whatever your Company policy on data is.
    If there is no financial impact then it does sound like they are being daft.



  • Thanks. Again, I appreciate the feedback.
    It should be interesting as we’re having a separate discussion today, and I plan to ask for the details of the controls written. As long as we have SOX upon us in IT, I’d like to do what we can to meet our goals (reduce costs, better service offering) and adhere to what’s applied to us currently via SOX.
    I have no issues documenting processes and adhering to them (a la ISO but with real teeth) - it would just be helpful to actually get guidance from those responsible for it in our company.
    Cheers,
    John



  • OMG,
    Tell those auditors to get a clue, based on what you have described there is absolutely NO SoX implications whatsoever.
    ALthough I don’t understand why you would even need a web base program to do what u need. I’m sure in outlook you can just delegate rights to users. Ie. if i delegate rights to my secretary to view my emails,calendar etc. I’m sure the same functionality is possible in most email systems these days.
    Yoda404.



  • It’s mainly administrative. Users want a single interface to set up Send As and Full mailbox access. Outlook is still somewhat limited in granting all the explicit rights.
    Plus users are lazy 🙂


Log in to reply