October 2006

Can a Service-oriented Architecture Hinder Sarbanes-Oxley Compliance Efforts?

Although SOA platforms can enhance the use of software applications, auditors need to understand how their use may affect the organization's internal controls structure and Sarbanes-Oxley Section 404 compliance efforts.

Sonia Luna, CPA
Founder
SOX Solutions

Hugh Taylor
Vice President Marketing Communications
SOA Software

Perhaps your company's chief executive officer (CEO) thinks that making the change to a service-oriented architecture (SOA) — a paradigm that simplifies the connection of pieces of software with one another — only requires the use of a new system. The truth, however, is quite different. Organizations that rely on their old governance models to oversee the use of new SOA platforms may find that they are putting their compliance to Section 404 of the U.S. Sarbanes-Oxley Act of 2002 at risk. In fact, the openness of SOA creates vulnerabilities that have the potential to disrupt the internal controls over financial reporting required by Section 404. To identify whether established internal controls under the new SOA platform meet Section 404 compliance requirements, internal auditors need to understand how SOA platforms work and the underlying internal controls issues involved with any SOA.

HOW SOA WORKS

SOA platforms ease the connectivity of software programs by making every application residing within an IT environment available as a service using Web protocols. In an SOA, software functionality is accessed or used on demand by virtually any program in the world regardless of its location, network protocols, operating system, or programming language. Known SOA platforms used today include Microsoft .NET, IBM's WebSphere Enterprise Service Bus, BEA AquaLogic, SAP NetWeaver, and Oracle Fusion Middleware.

SOA takes advantage of extensible markup language (XML) and Internet communication protocols, thus enabling multiple applications to share data openly without the need for proprietary middleware. This open sharing of data leads to faster and cheaper application integration projects and an easier reuse of software applications. However, appropriate internal controls are needed to ensure implemented SOA frameworks meet Section 404 compliance requirements. The following example of a manufacturing organization using a conventional enterprise software architecture will help to illustrate the effect of SOA on internal controls once an SOA platform is established.

Figure 1

 

Figure 1. A company's enterprise architecture for outbound transactions including revenue

The illustration shows the company's architecture prior to the switch to SOA. Under this architecture, customers — identified as individual users (i.e., Human User on Browser in Figure 1) — place orders, pay their bills, and check the status of orders using a Web-based portal that connects them to the general ledger software application and the warehouse's inventory, shipping, or receiving application via a proprietary application integration interface. This is a point-to-point setup, where the Internet provides a communication vehicle and the browser provides a common client that enables individuals on the user side to access the company's back-end systems.

In the company depicted in Figure 1, a typical financial reporting control might mitigate the risk of misstating revenue due to inadequate physical or electronic security over sales documents and electronic files. As shown in Table 1, the control objective is to safeguard sales documents and related accounting files, including those in electronic form. The control practice involves segregating the role of sales personnel from credit and billing staff. In other words, a sales person cannot approve a customer's credit, issue an invoice, or modify an existing invoice. If the salesperson had this type of access, the company would run the risk of relying on data of low integrity to state its revenues.

Control Objective

Risks

Control Practice

Safeguard sales
documents and related
accounting files, including
those in electronic form.

Inadequate physical or
electronic security over
sales documents and
electronic files.

Sales department is
independent of credit and
billing departments, and
access to accounts
receivable records is
restricted.

 


Table 1. Control objective, risk, and control practice pairing for enterprise architecture prior to SOA transition.
Source: Karl Nagel & Co.

Given the company's networked application architecture, the preventive control necessary to ensure compliance with this internal control objective would probably rely on an access control and identity management system. For example, under this enterprise structure a sales person has a network login identification (ID) that is given to staff with a sales user role only, while a billing clerk has a login ID that is specific to a billing role. Each ID role:

  • Restricts access to the appropriate application module only as specified in the application controls.
  • Prevents access to areas not specified by the application controls.
  • Does not permit unauthorized users to be on the network by locking them out.

Customers who entered the enterprise architecture through the Web portal also would have unique user IDs and access rights that are based on their customer roles. A customer, for example, might have the ability to initiate a sale, but not modify an order after it is initiated, void an existing invoice, or approve their own credit. Assuming password rules, network security infrastructure controls, and other IT general control components are working properly, access restrictions that support proper segregation of duties will be sufficient to pass an internal control assessment related to Sarbanes-Oxley Section 404 compliance.

TRANSITIONING TO AN SOA

Now, let's see what happens to the company's financial reporting controls once an SOA framework is implemented. Figure 2 shows the same company after its transition to an SOA. In this scenario, the general ledger is now exposed as a set of Web services — software functions that can be used over the Internet through XML and http protocols. For a company like this, an SOA has several business advantages. For instance, an SOA can enable the company to make sales input forms available for sales representatives on their personal digital assistants and simplify the direct integration of financial applications or the warehouse system with customer enterprise resource planning (ERP) suites — applications that integrate a company's data and processes into a single unified system.

Therefore, instead of a specific customer acting as an individual system user, an SOA would enable the customer's entire ERP system to act as a Web service user and access the company's general ledger functionality over the Internet. In this machine-to-machine setup, a developer on the customer side inserts a URL into the ERP system's code that provides the Web address of the Web service the company is exposing.

Figure 2

Figure 2. Transition to a service-oriented architecture.

Although this new SOA framework has the potential for tremendous business value, its openness may have negative consequences that affect the integrity and effectiveness of security and internal controls. To illustrate this point, imagine the following possible scenario. A company decides to expose its general ledger as a Web service in an SOA platform without any security or access control restrictions. As a result, any software in the world can interact directly with the general ledger using Web protocols, which travel right through the firewall using port 80. Port 80 is designated for Web traffic and is usually left open so companies can communicate to the outside world via the Internet. However, when port 80 remains open, the general ledger, which could contain sensitive and confidential data, is exposed to the outside world. From an internal control assessment perspective, this could be identified as a material weakness due to insufficient firewall security.

Although this may sound far-fetched, some SOA deployments today exhibit these vulnerabilities even when the company uses strong perimeter security and network access controls. Understanding these possible vulnerabilities and their effects on financial reporting activities can help internal auditors recommend the use of internal controls that rely on segregation of roles and implementation of access controls for key financial applications.

ENHANCING INTERNAL CONTROLS

SOA is based on machine-to-machine, or application-to-application, interactions. As a result, internal controls that segregate duties by assigning user roles to individuals may not work well within the SOA. The user of the exposed Web service's general ledger system is actually another piece of software. Therefore, when the sales representative's PDA uses the general ledger's Web service, the user is the PDA software and not the person pushing the buttons. When the customer's ERP system accesses the general ledger's Web service, the general ledger sees the ERP system as the user and not the person placing the order.

During Section 404 compliance reviews, internal auditors need to identify whether the internal control structure makes this critical distinction by assigning a role to the software that is accessing and using the general ledger's Web services. In addition, it may be necessary to map the role of the software that is accessing the Web service to the identity of the specific person using that Web service. This will ensure that appropriate segregation of duty controls are established and in compliance with Section 404 requirements. For example, if a company's SOA is not well governed, it may be possible for the sales representative to use his or her PDA to access a credit approval Web service on the general ledger and approve a customer's order, breaching the internal control that is meant to forbid this activity.

Control Objective

Risks

Control Practice

Sales invoices are accurate
and complete.

Data integrity security
risks will prevent sales
invoices from being
accurate or complete.

Proper restricted access is
provided throughout the
sales department.


Table 2. Control objective, risk, and control practice pairing for SOA.
(Source: Karl Nagel & Co.)

In addition, the customer's ERP system that is using the general ledger's Web service could access the invoice modification functionality, thus enabling the customer to void an invoice he or she didn't want to pay. As shown in Table 2, one of the control objectives in an SOA environment is to ensure invoices are accurate and complete. Because the customer can void his or her invoice — an internal control breach — the general ledger now shows inaccurate information about the invoice. If the SOA cannot map the use of the Web service back to a specific person or provide a means to assign roles to applications and restrict access accordingly, then the controls established in the conventional architecture will be deficient. And, because user access restrictions are a core component of internal controls that enforce segregation of duties, the SOA in use will not be in compliance with Sarbanes-Oxley financial reporting requirements.

MOVING FORWARD

When making changes to an IT environment, organizations should identify any new risks and internal controls that might be associated with the new changes. For instance, because Web services expose applications to the outside world though port 80, the move to SOA places a greater emphasis on application-level controls for compliance to take place than the degree of control required in a conventional IT architecture. Auditors can recommend that companies implementing this new paradigm do so in stages across key business functions. This will enable companies to detect the risks of using an SOA platform more effectively.

Furthermore, because SOA operates in a machine-to-machine fashion, its move should prompt security and compliance professionals to seek assurance that users can be assigned roles, which should be mapped to human users who are also subject to access rules. Although mitigating the internal controls disruption of SOA should not be a challenge for well-informed IT professionals, internal auditors should recommend that organizations evaluate the security risks of implementing an SOA platform, given its ability to make company transactions available to the outside world. Although SOA is certainly not a revolution from a controls perspective, it does change a few assumptions about the way companies view security and compliance. One thing should be clear: A poorly governed SOA could easily result in deficient internal controls and problems with Sarbanes-Oxley compliance.

Sonia Luna, CPA, is the founder and CEO of SOX Solutions, a global Sarbanes-Oxley solutions provider for private and public companies of all sizes. SOX Solutions has affiliate office locally and internationally.

Hugh Taylor is the vice president of marketing communications for SOA Software, a provider of enterprise service-oriented architecture management, security, and governance solutions. Taylor is the author of The Joy of SOX: Why Sarbanes-Oxley and Service-Oriented Architecture May Be the Best Thing That Ever Happened to You and Understanding Enterprise SOA.


COMMENT ON THIS ARTICLE

Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.

Name:

Email:

Subject:

Comment:


To make something bold:
<strong>Text to bold</strong>

To make something italic:
<em>Text to italicize</em>

To make a hyperlink:
<a href="URL">Text to link</a>

 

April 2014IaCover 

 IPPF_Ap42014

IIA Academic_Nov 2013

IIA SmartBrief

 Write for FSA Times

 

 Twitter

facebook IAO 

IA APP