Introduction
The SOX Act was created to help improve internal controls for financial reporting in publicly held companies. The Act, however, does not reduce the likelihood of executives facing hefty penalties for not complying. Its primary aim is to improve internal controls for financial reporting by establishing mandatory requirements for assessing risks to information system vulnerabilities that can be easily exploited.SOX sections that have received the most attention are 302, 404, and 409. Section 302 spells out what the CEO and CFO must do to establish, implement, and maintain internal controls. Section 404 indicates what management must do to assess the effectiveness of the internal control structures; to protect assets from unauthorized modification, disclosure, deletion, and usage; and to ensure that the duties are separated. Section 409 mandates disclosures of real-time events within a given timeframe.

As part of complying with the Sarbanes-Oxley Act, executives must provide guidance on the implementation of SOX mandates, particularly Sections 404 and 302. Developers need to build business-logic Web services and link them to a foundation such as IBM DB2 CommonStore.

This article focuses on how developers can build business-logic Web services with DB2 CommonStore. This solution can help organizations capture e-mail, instant messages, and attachments in any media format and convert them into appropriate formats for storage and indexing during retention periods. It also allows them to specify rules on access and audit controls, specify when and how to destruct the retained messages, and search content for investigation.

Build an archive and compliance infrastructureDB2 CommonStore is part of the IBM Enterprise Content Management Portfolio. To build a basic infrastructure upon which you can expand to meet an organization's requirements, start with DB2 CommonStore as the foundation (see Figure 1) for use with the Assentor Enterprise suite from the IBM Business Partner iLumin Software. The range of data and media types you can use to comply, store, and archive is broad -- including print, audio, video, and digital.

Figure 1. DB2 CommonStore infrastructure
As depicted in Figure 1, DB2 CommonStore wears two hats: it focuses on compliance solution interfaces as well as mail archive or records management repository. DB2 CommonStore provides user-specified or built-in policy to drive archive and compliance management of messages for IBM Lotus® Domino® and Microsoft® Exchange Server users. DB2 CommonStore for SAP does more than support the e-mail archive management system; it also provides access to non-SAP objects that are stored in the enterprise content repositories or provides access to SAP objects from non-SAP applications. You choose the IBM DB2 Content Manager application to manage the contents of the mail archive or record repository, or choose the IBM DB2 Content Manager OnDemand application to manage high-volume print output data. The third option is IBM Tivoli® Storage Manager for backup and recovery management. If you have a lot of streaming multimedia to manage, consider IBM DB2 Content Manager VideoCharger.

You need the IBM Tivoli Storage Management Extended Edition for disaster preparation, planning, and recovery. Plan for various options to recover from a disaster. The option you choose depends on the type of disaster that could occur. You need to back up your mail, messages, and records at an off-site facility. It's not a good idea to back up data and records and to run applications in the same building -- or even in a different building in close proximity on the same site. You can integrate Tivoli Storage Management Extended Edition with DB2 Content Manager to provide heterogeneous storage device access in a single or multitiered storage environment.

Work with IBM DB2 Records Manager
Figure 1 shows that we have two ways of meeting e-mail regulatory compliance. The first is DB2 Records Manager integrated with DB2 CommonStore, which is covered below. The second is iLumin Assentor software integrated with DB2 CommonStore, discussed in the next section.DB2 Records Manager is a records management engine, not a repository. It processes each record according to a retention rule. If a record is subject to a conflict with retention rules, DB2 Records Manager notifies the administrator and suggests a remedy. To convert an e-mail message into a record, activate the DB2 Records Manager enabler to declare e-mail records from directly within the clients, such as Microsoft Outlook®. These clients communicate directly with the records management engine to file, retain, and secure a declared e-mail message.

Work with Assentor Enterprise
Assentor Enterprise suite manages, discovers, and archives messages and provides compliance and litigation support. It resides inside a firm's firewall, scanning and archiving all messages and monitors all e-mail communications to check that they follow corporate and regulatory requirements. Both Assentor Discovery and Assentor Compliance interact with DB2 Content Manager.

Customers are responsible for their compliance with laws and regulations, including SOX. These solutions are tools that can help them address the various requirements for internal controls and reporting. Assentor Compliance manages content policies on workflow processes by monitoring and retaining e-mail messages, attachments, and instant messages. It uses natural language technology to intelligently scan what's inside the content of every message and then to analyze it. If the analysis shows that a message looks or acts suspicious, the technology routes it to a quarantined queue for review by an appropriate supervisor or administrator. If the message is already sent, a supervisor also gets it.

Assentor File System Manager creates policies on the process of retaining messages and attachments as well as optimizes and allocates resources across diverse platforms. In addition, the policies spell out how messages should be retained, migrated, classified, and prioritized.

Model with DB2 Content Manager
To use DB2 Content Manager effectively, you should start with the data model of DB2 Content Manager. With it you can capture structural and relationship information across all types of content (such as audio, video, and text) and integrate structured data with unstructured content. Since the model is XML-ready, you can use an XPath-based query language to find out where you are when you navigate the model. To map XML schema to a model, you need DB2 Content Manager, Version 8 to do the job either automatically or manually.

Building and using the model generates systems administration data. You can use DB2 Content Manager to export data into an XML-readable file that you can import into another system server. Other features of DB2 Content Manager include the usual stuff -- access control, administrative domain creation, logging/auditing, and single-system administration client setup.To manipulate the data for the model, use SQL statements. Be careful how you create SQL statements; otherwise, running them could adversely affect the performance of a large database that might be latency sensitive. If you're unsure, get the opinion of a database expert.

Develop SOX Web services
The SOX Act is heavily dependent on IT systems. One way to reduce the processing and storage load on the IT systems is to develop business-logic SOX Web services for DB2 CommonStore. These Web services can be called when needed and released when not needed. The executives need to make sure their balance sheets bring returns on investment in the long run when they budget money for the development of modularizing SOX Web services.

In this section, you'll learn about developing Web services as middleware between DB2 CommonStore and enterprise applications. As you'll see in Figure 2, I've added Web services in the Service-Oriented Architecture (SOA), a subject that I've covered regularly in my articles in the IBM developerWorks SOA and Web services zone (see Resources for a link). The SOA also includes non-Web services.

Figure 2. Linking Web services with DB2 CommonStore

Executives need to create a strategy for the development of business-logic Web services as SOX modules, such as audit control, enterprise security, change management, workflows, business process management, and project collaboration. Through Web services, you can meet the SOX mandates of reporting requirements while ensuring high availability of data-retention capabilities on DB2 Records Manager or Assentor Enterprise.

It is far easier to develop, modify, test, and run Web services than to make changes to a long-running, huge enterprise legacy system. Most legacy systems are not modularized into identifiable, distinct components that you can test run independently of others. It's a lot cheaper to develop Web services than to redesign a legacy system into modularized parts.

Create SOX module hierarchy
Developers can work with compliance experts and business process analysts to establish a hierarchy of Web services, with the top as the orchestrator of the lower-level Web services. As shown in Figure 3, the top-down hierarchy begins with enterprise security as the parent Web service in the second level, followed by information security, vulnerability management, threat detection and response, and policy management and monitoring as the child Web service in the next level down.

Figure 3. SOX modules in a hierarchy
Talk to external Web services
If the company does not have the internal resources (for example, audit control) it needs to satisfy regulatory requirements, then the executives need to include a gateway to the external organization's enterprise applications in their strategy of establishing requirements for using external Web services. This supplements or closes the gap in the originating company's Web services or enterprise application. Figure 4 shows how the originating Company ABC's Web services can be linked to the external Company XYZ's Web services.When developers compose the new Web service, they should be careful that it does not result in new redundancy. It may be necessary to combine some redundant Web services as a single service to eliminate redundancy.

Figure 4. Linking to external Web servicesWhen Web services (Company XYZ) are outside the control of the originating organization (Company ABC), you need to ensure that they can interoperate externally with one another with respect to shared semantics and contractual obligations. Semantic misunderstandings (such as proprietary) and contractual loopholes (such as multiplatform differences) contribute to interoperability problems between external enterprise Web services. Developers need to resolve them before linking external Web services to the internal SOX Web services with a linkage to DB2 CommonStore.

Conclusion
Developing SOX Web services that call or are called by the DB2 CommonStore infrastructure requires planning ahead of time. You should communicate with a team of systems administrators, developers, and compliance officers on the most cost-effective development techniques while complying with SOX mandates. The CEO, CIO, CFO, and business analysts should be part of the team, because Section 302 addresses their responsibilities. All members in collaboration with one another will find that developing SOX Web services simplifies the task of getting their company to be SOX compliant and SOX efficient.

For more information visit Under Whitepapers and to view this article in its entirety visit Full Article