Sarbanes-Oxley Compliant Planning Security

Avatar

By
February 2nd, 2016


Section 404 of the Sarbanes-Oxley Act (SOX) requires public companies to maintain a system of internal controls to ensure that financial reports will be reliable. For many companies these regulations do not apply to their Planning system. These companies load Actual data from their general ledger (GL) system to Essbase to enable them to conveniently pair it with Forecast or Plan data for internal reports. The GL system, in this example, remains the system of record subject to SOX regulations. Other firms elect to generate their public financial reports with their Planning system, shifting regulatory controls from the GL system to the Planning system. This post describes one way to set up Planning security to minimize audit risk.

For companies that use Oracle’s EPM suite of products to publicly report their financial performance, security controls that will pass an audit are important. One technique to accomplish this is to require the use of groups and users created and maintained in the Microsoft Active Directory (MSAD) system and prohibit the use of Native Directory groups and users.

Gregs_1

Many Planning systems are set up with directories that use MSAD to authenticate users. In most cases the security groups those users are added to are created in the Native Directory to allow the Planning administrator to both add users to groups and provision groups in the system. Having the ability to do both tasks simplifies security maintenance but creates audit risk for any SOX compliant system. The Planning Administrator would have the ability to add unauthorized users to the system and/or grant unauthorized permission. Using MSAD groups separates Planning security into two steps that would reduce the ability of an individual to compromise security. The first step of adding users to groups would be performed by the Network Security administrator. The second step of provisioning groups would be done by the Planning Administrator.

The Network Security administrator in this example will not have any administrative permissions for the Planning system, but possess administrative permissions for MSAD. Their responsibility will be to add (move or delete) approved users to Active Directory security groups set up for use by the Shared Services application.

The Planning Administrator in this example will not have any administrative permissions for the MSAD, but possess administrative permissions for the EPM system. Their responsibility will be to provision MSAD groups in Shared Services with Planning roles and to assign groups to dimension members in Planning applications. Process guidelines for the Planning Administrator would prohibit any user level provisioning, creating any Native users or groups, and use of the Native “admin” user ID.

Processes to support this arrangement are important to their successful implementation:

  • Initial setup
    • MSAD groups for every role would need to be setup and provisioned. Going forward, new users would be added to one or more of these groups by the Network Security admin. The Planning admin would need to get involved only if a new group was needed or if changes to group provisioning were necessary.
    • A Native user named “admin” is created during installation of the EPM system. The password for this user should not be shared with the Planning admin.
  • Essbase Filter and/or Planning Entity Matrix
    • Documentation with each MSAD group and its associated permissions would need to be maintained by the Planning administrator. This matrix could include the Essbase filters generated by Planning for each group.
  • Access request process
    • Authorizations for access to the Planning system should be administered by finance and include the list of available MSAD groups to add or move a user into. A requestor would select a security group and be routed to an approver in Finance authorized to grant access to the data for that group. If approved, the request would go to the Network Security administrator where the user would be added to their security group. Any new groups or changes to group security would require the request to go to the Planning admin to complete those tasks.
  • Random security audits
    • Security reports from Shared Services can be run by a third party (ideally someone responsible for SOX compliance) to validate that no new native users or groups have been created in the system and that access has only been granted through MSAD groups. Reports are also available to generate lists of users and their group membership. Security log files can also be reviewed to track changes to permissions.

With this separation of MSAD user and group maintenance tasks from Planning provisioning, a robust control for access to the system is in place to protect the integrity of the Planning data and provide an internal control structure that an auditor will be comfortable approving.

 


Avatar

About Greg Strunk

Greg Strunk has over 15 years of experience implementing and administering Essbase and Planning applications. He has a background in finance that crosses multiple industries and broad technical expertise in security, automation, scripting, process improvements, reporting, and compliance.

Leave a Reply

Your email address will not be published. Required fields are marked *