Compliance in the Era of Service-oriented Architecture

As with everything today, you can?t escape the need to bring yourself into compliance with whatever regulations pertain to your organization.

If you?re involved in enterprise IT, by now you have probably either heard that service-oriented architecture SOA- is headed your way or you may already be involved in designing and deploying this new IT architectural paradigm. If your role also encompasses Sarbanes Oxley compliance, then you may be confronting a new set of challenges in an already complex situation. This article is intended to highlight some of the compliance issues you might face as your organization embraces SOA. What is SOA? Briefly, it?s an approach to IT architecture that uses open standards, such as XML and Web services, to enable software applications to exchange data and operating instructions using non-proprietary languages and communication protocols. Applications become available as ?services,? universally accessible, discoverable, and understandable to virtually any other application?whether it is housed in the same server blade or halfway around the world. Though long a goal of the IT industry, the advent of Internet protocols and XML have finally brought about the real thing. From a pure IT perspective, SOA has great potential to simplify integration between applications and business partners. The technology also enables significant reuse of IT assets because the universal nature of XML allows a developer to write an application one time and expose it to numerous other applications that can access it without the need for proprietary middleware. Major challenges exist, of course, but SOA has gained in credibility and adoption throughout the Fortune 1000. Compliance and SOA From the perspective of compliance, though, SOA is a mixed proposition. SOA?s promise of simple, rapid-cycling, and cost-effective integration of applications can help with detective controls such as exception monitoring. Improved integration of heterogeneous ERP and general ledger systems can also facilitate the implementation of internal controls. At the same time, there is a definite downside to exposing one?s critical business applications to the world so openly. For instance, take just one of the IT General Controls that an IT manager must document and implement in order to comply with Section 404 of the Sarbanes Oxley Act. The IT Governance Institute?s Control Guidance document recommends that, ?The SDLC [System Development Life Cycle] methodology ensures that information systems are designed to include application controls that support complete, accurate, authorized, and valid transaction processing.? ITGI ? IT Control Objectives for Sarbanes Oxley, April 2004- What is the impact of SOA on this internal control? There are several, but the main one to focus on is how a system that is open for interaction with virtually any other system in the world can ensure ?complete, accurate, authorized, and valid transaction processing.? If you have a robust security and governance plan for your SOA, this internal control will not cause you to lose much sleep. However, if you have not considered fully the compliance ramifications of deploying an application based on open standards, you should. Here?s the catch: SOA involves ?machine to machine? or ?application to application? interactions. In contrast, most security solutions today emphasize ?human to machine? interactions. For example, you might expose a Web service to a portal. Even though the user of the portal is a person, from the viewpoint of the Web service, the ?user? is the portal software. Therefore, to meet the SOX 404 IT General Control Objective described above, you would need to make sure your Web service can authorize, authenticate both human and machine users, and provide an audit log of their activities. This might entail mapping an identity repository to the Web service consuming applications, such as the portal. Compliance, SOA, and DM In the world of electronic document management, SOA?s security and governance issues raise a number of critical points for compliance. While many corporate documents are extraneous when it comes to compliance, those documents that are used for financial reporting may be bound by the data integrity and auditability requirements mandated by SOX. According to Sonia Luna, CPA and president of SOX Solutions, ?Document management pertaining to SOX is primarily related to supporting the financial impact of the company?s significant account balances. Document retention to critical reports, which supported the findings of a ?key control? are necessary to retain for at least seven years. For example, if a company authorized a vendor payment using email, then those emails would have to be retained for seven years.? Document management processes whose compliance requirements are affected by SOA might also include the storage and access rules for pharmaceutical chemical compounds or petroleum reserves. These kinds of documents bear on financial reporting because their contents may appear as footnotes to explain the valuation of assets on a balance sheet. According to Luna, ?The SEC would like some evidence that companies are taking document retention seriously as it affects their SOX internal controls assessments. If the document retention or the integrity of supporting documents were in question e.g., not reliable- an auditor would have to create a series of tests to conclude that the current SOX testing period as well as past audit periods were in fact valid to substantiate their audit opinion. It?s one more reason why data recovery is becoming a big deal these days.? To be compliant with this requirement in an SOA setting, then, would require that the security and governance parameters of the SOA affect both preventive and detective controls. It should not be possible for anyone or any machine- to alter documents used in financial reporting. At least, there should be an audit trail. The good news is that if you are in a well-run IT organization, you probably already have the basic control development processes in place to transition to SOA without undue compliance-related aggravation. SOA is an incremental technology shift, so it tends to extend existing security and governance policies. Nonetheless, because of its revolutionary and open nature, SOA should prompt you to think through the governance and security aspects of compliance carefully before exposing major systems as part of an SOA. Source: www.edocmagazine.coma>