Application Security—A SOX perspective

Jaspreet Singh, Senior Consultant, Risk and Business Solutions, Ernst and Young examines security risks in the context of SOX and other compliance issues.

Jaspreet Singh

Rapid access to current information is essential for any competitive business. Organisations worldwide are under constant pressure to provide the latest data to authorised users, regardless of where those users may be located. And thanks to the World Wide Web, global information access can be as easy as connecting to the Internet. Unfortunately, easy access also includes risk; the possibility that unauthorised users may gain access to confidential information. If they do, whether the unauthorised user is viewing or changing the data, it is likely that such a breach of confidentiality also results in failure to comply with SOX integrity and control requirements.

Section 404 of the Sarbanes-Oxley Act (SOX) mandates that the executive management of publicly held companies must evaluate and report on the effectiveness of their internal controls over financial reporting, and have independent auditors substantiate the effectiveness of these controls. These controls also encompass the IT operational processes and application software that support a company’s business.

Four sections of the SOX hold particular relevance for compliance managers concerned with the impact of the act on enterprise applications. They are:

• Section 302—Certification of Internal Controls
• Section 906—Certification of Financial Statement Accuracy
• Section 404—Management Assessment of Internal Controls
• Section 409—“Real-Time” Disclosures of Material Events

The provisions of Sections 302 and 906 have already been implemented—CEOs and CFOs subject to these certification requirements who have not implemented adequate controls management programmes do so at some corporate and personal risk. Although the implementation time table has recently been relaxed, the bulk of managers are now grappling with the mandates of Section 404 of the Act, while Section 409’s reporting requirements remain in the future. Each section affects controls management in enterprise applications in distinct ways.

SOX follows the COSO (The Committee of Sponsoring Organisations of the Treadway Commission) framework for regulatory and risk management, which standardises the definition of internal controls as referenced in Section 404. It also provides a framework for risk management and regulatory compliance, which requires risk assessments and related policies, a control-based environment, control-based activities, information and communication procedures, and a monitoring mechanism for the control environment.

While not required by COSO, COBIT or Control Objectives for Information and related Technology was developed and issued by the IT Governance Institute as a standard that provides effective governance for good IT security and control practices. COBIT is an internationally accepted de facto standard and formally accepted by the Information Systems Audit and Control Association (ISACA) as being a good practice for control over information, IT and related risks. COBIT contains a framework for control and measurability of IT by providing tools to assess and measure the enterprise’s IT capability for the 34 COBIT IT processes. COBIT makes COSO real for systems by defining

• General Controls—information systems
• Application Controls—complete and accurate processing of authorised business transactions

Lastly, COSO and COBIT require the assessment of quality and performance of internal controls over time.

Application Audit

An application audit is a specific audit of one application. For example, an audit of an Excel spreadsheet with embedded macros used to analyse data and generate reports could be considered an application audit. Application audits can also pertain to a business process that heavily relies on various information technology systems. An example would be the manufacturing process of a company, which may span across several different servers, databases, operating systems, and applications. Application audits can also be of a more technical nature like of a single data warehouse.

These audits can be done as the system is developed, at post-implementation, or on a regularly scheduled basis (annually, every 2 years, etc.). Whichever stage of audit review is being carried out, the IS Auditor is looking for assurance that the application provides an adequate degree of control over the data being processed. The level of control expected for a particular application is dependent on the degree of risk involved in the incorrect or unauthorised processing of that data. The greater the financial nature of an application, the greater the level of control that is expected.

Effective Application Internal Controls

Internal controls seek to prevent fraudulent activities and detect potentially fraudulent activities after the fact, based on suspicious situations or inferences. Internal controls can also be used to identify and prevent unintentional errors by honest people. Some of the key elements to effective application controls consist of the following:

SOD: Transactions and the “Need to Know”

A focus on segregation of duties (SOD) reduces risks by providing an internal control on performance through the separation of custody of assets from accounting personnel, separation of authorisation of transactions from custody of related assets, and separation of operational responsibilities from record-keeping responsibilities. Consequently, access to functions, and even to information down to the field level, must be controlled in the application to accomplish this. Some well-known generic SOD controls are

• Receiving Segregated from Purchasing and Supplier Master Data
• Requisitioning Segregated from Purchasing
• Purchasing Segregated from Accounts Payable and Supplier Master
• Item Master Segregation from Most Supply Chain Activities
• Inventory Control Segregation from Accounts Payable / Settlement
• Segregation of Purchasing from Supplier Returns / Debit Memos. Segregation of duties applies to IT personnel as well as the users of software applications. As part of application internal controls, professional practice demands that functions, such as programming, operating, controlling and using are performed by different people in order to enhance mutual control. Of course, everyone has experienced system and application bugs or operational problems that have required granting one IT person broad powers to be able to diagnose and fix the problem under tight deadlines, in spite of the significant risks, and been relieved about the outcome

Implementing segregation of duties, for e.g. removing the conflicts, can often have an adverse impact on operational performance and introduce delays or errors in a process by involving multiple people. Based on the risk and operational factors, a spectrum of capabilities is needed in this area to address day-to-day realities:

• Forbid the transaction under all circumstances
• Forbid the transaction except with high-level authority
• Permit the transaction based on rules, such as dollar value approval levels
• Permit the transaction with “reason codes” to justify the action for subsequent review and / or attaching supporting calculations, such as Excel spreadsheets or application reports
• Permit the transaction with subsequent approval. With the need for function- and field-level SOD rules, an enterprise with tens of thousands of users could easily have thousands of conflicts. Enterprises with multiple, heterogeneous applications or with multiple organisations operating within their applications, e.g. Oracle Applications “multi-org,” can increase this SOD conflict matrix exponentially. Automated management and enforcement of these complex segregation of duties policies becomes essential

Authorisations / Approval Automation

In order to manage SOD policies, which allow for approvals, it is important to provide automation for the authorisations and approvals. This approval functionality should also provide for escalation in the event of delayed approvals or suspended / incomplete transactions. A list of each application responsibility / role and the titles of all related employees can help eliminate clerical errors related to assigning access to the right person, even in the case of duplicate names.

In the shadow of world terrorism and corporate scandals, IS auditors are fast becoming a mainstay in the IT department. New legislation and competitive global economics almost guarantee that organisations will want to be sure that they have the controls in place to mitigate internal and external risks. Information security professionals can readily understand that the application audit presented in this paper simply outlines the controls that they are themselves attempting through security. It is essential that IT and audits work together in organisations to better understand the concepts of risk and control and ensure that the business objectives are met in an effective and appropriate manner.

COSO was formed in 1985 in the United States to sponsor the National Commission on Fraudulent Financial Reporting, an independent private sector initiative, which studied the causal factors that can lead to fraudulent financial reporting and developed recommendations for public companies and their independent auditors, for the SEC and other regulators, and for educational institutions.

It is apparent that compliance efforts will not be a one-time leap, but will be ongoing and will need to address evolving standards, including new global regulations. Appropriately, governmental bodies have to comply as well.