Financials – General

Get Involved. Join the Conversation.

Topic

    Liam Todd
    SoX - Config changes and logsAnswered
    Topic posted June 3, 2019 by Liam ToddRed Ribbon: 250+ Points, tagged Compliance, Configuration, Financials, Reports, Search, Security, Setup / Administration 
    130 Views, 6 Comments
    Title:
    SoX - Config changes and logs
    Summary:
    SoX requirements Configuration changes and privileged user logging
    Content:

    We've been acquired by a US company, so we now have to comply with SoX. We've got a team of consultants who've identified some gaps in our controls, and some potential remediation, but the requirements are a bit woolly.

    One gap references a review of all configuration changes being able to be tracked to our change management process - the part we don't have covered is the ability to extract a full population of configuration items/configuration changes. Our consultants also haven't defined what 'configuration changes' entails so struggling a bit here too! I was looking at using 'Manage Audit Policies', however have been told that this wont be an effective control due to users with privileged access having access to:

    - switch the audit history off

    - do something bad

    -switch back on 

    Has anybody had experience of having to control this gap in Fusion?

    The second point (which might cover the first) is around logging of privileged user activity. - is it possible to log activity of specified users? I've been able to extract my own activity using 'Manage Audit Policies', but my understanding is that i can only extract this when i've enable the relevant audit trail, which tracks for all users. (eg changes to external bank accounts in AP module - it would only be an issue if I was to perform this, other user will be performing but this is captured by other controls like segregation of duties.)

    Sorry - bit waffly - but if anybody has had experience with either of these gaps and has controlled them in Fusion I'd appreciate if you could let me know how!

    Thanks,

    Liam

    Version:
    R13 (update19B)

    Best Comment

    Neelam Thakur

    Hello Liam,

    Great questions posted in this topic! About your first concern, if you can find the specific privilege/role/duty that gives access to Manage Audit Policies, you should be able to remove it from Implementation Consultant/Administrator roles. I am not sure which specific role gives this access. Once you have removed it from the user role, you can create a custom role to include access only to only "Manage Audit Policies". You can temporarily assign this role to a user to configure audit trails and then take it away.

     

    About your second concern, yes it is a bit waffly :)

    I don't believe that you can turn the audit trail on or off for specific users. Also you are correct, you have to turn the audit on for a particular area for audit train to get captured. Once you have turned it on for a particular area, say for example suppliers (you have to select what columns to be audited. You can select all but I would not advise it. The resulting report will be a nightmare of epic proportions) , the change made to suppliers fields selected for audit, by any users will get recorded.

    There is one exception however, when using the proxy feature. You can set someone to be your proxy from the "Preferences" area. That person then does everything you can do. When a person is acting as proxy, all their activity is recorded, regardless of whether audit has been turned on or not for the activity they perform.

    And lastly, I will point out, in dealing with Auditors, there will have to be some "accepted" risks. Privilege users will always pose a risk, but we cannot do without some users having elevated rights. Some risks have to be documented and signed off by senior management. Hope this helps!

    Neelam

     

    Comment

     

    • Neelam Thakur

      Hello Liam,

      Great questions posted in this topic! About your first concern, if you can find the specific privilege/role/duty that gives access to Manage Audit Policies, you should be able to remove it from Implementation Consultant/Administrator roles. I am not sure which specific role gives this access. Once you have removed it from the user role, you can create a custom role to include access only to only "Manage Audit Policies". You can temporarily assign this role to a user to configure audit trails and then take it away.

       

      About your second concern, yes it is a bit waffly :)

      I don't believe that you can turn the audit trail on or off for specific users. Also you are correct, you have to turn the audit on for a particular area for audit train to get captured. Once you have turned it on for a particular area, say for example suppliers (you have to select what columns to be audited. You can select all but I would not advise it. The resulting report will be a nightmare of epic proportions) , the change made to suppliers fields selected for audit, by any users will get recorded.

      There is one exception however, when using the proxy feature. You can set someone to be your proxy from the "Preferences" area. That person then does everything you can do. When a person is acting as proxy, all their activity is recorded, regardless of whether audit has been turned on or not for the activity they perform.

      And lastly, I will point out, in dealing with Auditors, there will have to be some "accepted" risks. Privilege users will always pose a risk, but we cannot do without some users having elevated rights. Some risks have to be documented and signed off by senior management. Hope this helps!

      Neelam

       

      • Liam Todd

        Hi Neelam,

        thanks very much for the fast response and comprehensive answer! Great idea for managing the audit gap, this will work well with a separate user roles report we use for review of appropriate access.

        I'm interested in the proxy feature, i'll do some investigation and testing on this myself. First thoughts are a locked admin account with all the relevant roles the privileged user would need (no 'Manage Audit Policies' as above!) and proxy set to the actual users account - does that sound realistic from your experience?

        Agreed on the auditors - even worst is that we have auditors in for advisory work on SoX, and then a separate company to do the actual audit - so they are being extra cautious!

        Again, thanks for the response.

        Liam

        • Neelam Thakur

          Hi Liam,

          That's an interesting take on the proxy feature. If I am understanding correctly, you are proposing to distribute access to perform admin tasks using the proxy feature. That is clever, since all admin actions will get audited, without configuring audit.

          I will say though that my impression of the proxy feature was that it is for use during an employee's absence so as such for a short term basis. Not to say that it cannot be used for an extended period of time. I would, however give a consideration to amount of audit data that would be created and consult with Oracle support about the size of your pods and resize if necessary.

          Also, I would review the audit reports that are generated. Please note that "Internal Auditor" Role is needed to review Audit Data. So I would suggest that you review the reports and assess their usefulness. I see no sense in generating a lot of data if we do not know how to use it or do not understand it.

          You may find that a better approach may be to setup audit trails for sensitive areas rather than be auditing everything. Please keep us posted of your findings.

          Hope this helps!

          Neelam

           

           

          • Liam Todd

            Hello,

            Agreed, I think that's the way the feature is intended, I'm doing some testing on the audit logs for proxy vs logging by module. Our systems team is very small and we don't spend much time in production, though I've noticed some issues completing some tasks as a proxy user so it might end up being the audit policies route anyway - but useful to know about the proxies feature!

            In case anybody stumbles on this later, a couple of points for proxy users:

            User who will log in to access the proxy account needs a role with the 'FND_IMPERSONATE_USER_PRIV' privilege, eg standard role 'Channel Account Manager'

            log into the proxy account as normal, Dropdown menu near name in top right>Set Preferences>Proxies>search for user (only users with privilege above will be searchable)

            Log in as user who will be accessing the proxy account, and switch user using drop down menu near name. You’ll need to re-enter your password.

            Cheers for your help Neelam!

      • Ajay Hathiramani

        Hello Neelam, Liam, 

        This is a very interesting and useful topic! Appreciate the insight shared thus far. I have a few questions is anyone is able to answer.

        1) Was wondering if you implemented the solution to segregate "Manage Audit Policies". Some of the seeded roles such as IT security Manager and Application Implementation Consultant have the Manage Audit Policies functionality, hence did you remove the functionality from the seeded role or created a new role and then remove the Manage Audit Policies?

        2) Enabling auditing is vast area in Fusion, is there a best practice when it comes to enabling audit at business object level? What are the critical configurations to enable auditing.

        3) We are a US company and our Auditors have raised concerns regarding the current timing of the SOC-1 review from Oracle which will not meet their needs as part of the year end audit. We close our books on March 31 and the most recent SOC 1 report available from Oracle will be dated 30 June.  The second SOC 1 report we receive is in May 28th which is too late and by this time we would have filed accounts.  However, our auditors have highlighted to us that they cannot rely on a bridging letter that is more than 3 months old. Have you experienced a similar situation?