|
|
|
Features
< Back
Sarbanes Oxley : Technology : Sarbanes Oxley
Making Sure the SOX on your SOA Match
SOA is transforming IT
By
Dr. Toufic Boubez (and Jonathan Rosenberg)
|
|
Dr. Toufic Boubez (and Jonathan Rosenberg)
Co-Founder
Layer 7 Technologies
|
Business processes no longer just involve humans using machines to access applications and data. Where business processes stretch across many cooperating and coordinated computers, technologies like XML and Web services are making machine-to-machine interactions commonplace.
Service-Oriented Architecture (SOA) ? an integration framework for connecting loosely coupled software components into on-demand business processes ? is the basis for this transformation. SOA allows software functionality to be delivered as network callable services that can be composed into processes in a flexible, agile manner. One software system can be programmed to call another by sending XML messages, usually via Web services technology.
While SOA makes IT-enabled business processes more efficient, it complicates identity and access management. This is an issue for companies that must comply with financial controls and reporting regulations required by the Sarbanes-Oxley Act (SOX) of 2002.
The new rules are forcing companies to rethink how they govern their IT processes. In particular, section 404 requires every publicly registered company to demonstrate the effectiveness of their internal control structures and reporting procedures. This means businesses need identity and access infrastructure that can both control and validate human-machine interactions, as well as SOA-based machine-to-machine interactions.
An example of a SOA based business service 401k delivery. A 401k provider will push the functionality in their consumer-facing application in the form of a Web service out to their employer-customers. This allows that employer to treat the Web services interface as an API allowing them to integrate that service into their internal benefits portal. Essentially, the 401k provider has ?pushed? the 401k functionality inside the ?internal? application of their employer-customer inside their corporate environment. Employees can access all benefits information including their 401k through this portal even though only the regulated 401k provider can actually handle investment requests.
The Challenge of SOA Compliance
In the post-Enron era, many regulations have been put in place to ensure transparency and accountability for financial, personal and confidential information. These compliance regulations (HIPAA, Basel II, USA Patriot Act and others) have elevated the need for companies to know and control who has access to confidential or sensitive data, and to know when unusual activities occur. In all cases, these new control and disclosure requirements create new demands for IT governance.
Sarbanes-Oxley is no different. Section 404 of SOX demands effective and demonstrable internal control structures and reporting procedures for financial information in all publicly registered companies. This requires:
? A framework for controlling and auditing who accesses financial information
? A framework for controlling and auditing what financial information is accessed
? A framework for ensuring financial information is not compromised during transmission
In the client-server or Web environment, this can be addressed by a user-centric identity and access-control infrastructure, plus some kind of point-to-point SSL tunneling between client Web browsers and servers.
The situation in SOA, however, is more complex. Identities belong to machines, and SOA interactions are not just point to point. In fact, machines in an SOA can act as intermediaries for other service requestors, creating challenges for managing and tracing identity across long-lived, multi-hop transactions. For the same reason, ensuring message integrity across a multi-hop transmission is complicated. Point-to-point SSL will not be enough.
Identity Management Requirements for SOA
The problem of controlling who accesses financial information can be addressed through identity management. Several vendors offer products specifically designed to manage user identities and their associated credentials. However all the products are human-centric. Extending identity infrastructure to SOA requires an ability to provision identities for machines, certify those identities with a credentialing mechanism like PKI, and establish an evidence trail for authentications even when the authentications span identity domains.
Access Control Requirements for SOA
Similarly, the problem of controlling what information is accessed when can be solved by managing an identity?s access entitlements. In the client/server world this is addressed by an access management system that can control admission to a specific server or file resource. In the Web world this is typically addressed by a Web single sign-on solution that restricts access by URL.
However, managing access entitlements for SOA is more complex. Access needs to be controlled at a fine-grained service or sub-service operation level. This requires an ability to inspect every XML and SOAP message to resolve a service or operation address, and then perform an authorization decision based on the requestor?s identity (or identity membership in a group), or request?s time of day, IP range, metering parameter, content, or security policy conformance (for instance, whether or not the requestor?s message includes a signature).
Transmission Control Requirements for SOA
In the Web world, protecting content from compromise during transmission can be easily handled by SSL, which is natively supported by all Web servers and browsers. SSL provides confidentiality, integrity and protection against transmission threats like man-in-the-middle and replay attacks.
However, protecting content during transmission in SOA is more problematic. As discussed previously, SOA security cannot be handled by point-to-point transport security like SSL (in the case of HTTP), because Web services can transact across multiple intermediaries and transports. Consequently, privacy and integrity must be rolled into a Web services message.
This requires an ability to selectively apply and enforce encryption (for confidentiality) and digital signature (for integrity) to a whole message (SOAP envelope), message part (SOAP element / XML field), or message attachment, depending on where the financial information is carried in a Web services transmission. To protect against transmission compromise from things like message spoofing (man-in-the-middle attacks) or session hijacking (replay attacks), there needs to be a way of negotiating cryptography keys ahead of each security session.
The Need for SOA Governance
SOA governance is predicated on an ability to establish, control and verify security between SOA consumers, providers and intermediaries participating in a transaction. This requires an ability to certify and validate SOA consumer identities, even in transactions that span federated departments and partners. It also requires an ability to define, provision and execute policy across SOA consumers and providers in a consistent way. Preserving the fidelity of a policy from definition to execution, while also maintaining architectural flexibility, demands very specific capabilities and features from an SOA governance framework.
An SOA governance framework must result in verifiable behavior between SOA consumers and providers. They must contractually agree on policy terms for their transaction in a way that is both undeniable and verifiable using either real-time policing (monitoring for contracted policy violations) or forensic audit. In an ideal SOA governance framework, violations to contracted policy will result in alerts or fully automated remediation.
Identity and Trust Control Framework
The cornerstone of an effective SOA governance framework is the ability to trust identities ? all secure SOA transactions depend on identity trust between SOA consumers and providers. For an SOA provider to trust an SOA consumer?s identity, every service consumer must clearly establish its identity in a certifiable and undeniable way to every service provider. This also requires every SOA provider to have a reciprocal mechanism for authenticating an SOA consumer?s identity by validating its identity certification credentials.
In scenarios where the SOA consumer and SOA provider lie in the same identity domain, this task is simple because a common identity certification directory will exist. However in scenarios where SOA consumers and providers reside in different identity domains, this task is complicated since no common identity store will exist. In these scenarios, an SOA governance framework must be able to establish trust across identity domains, so that an identity certified in one domain can be trusted in another. This kind of transitive trust depends in practice on the ability of an SOA provider to establish trust with an identity validation intermediate that lies in the consumer?s domain, and for that intermediate to be able to electronically vouch for the identity of the consumer.
Any framework for governing trust between an SOA consumer and provider must include both a mechanism for certifying and authenticating an identity inside a single domain, and also between domains. In practice this requires a facility for establishing trust between identity domains, as well as exchanging evidence for identity authentication (i.e. federating identity authentication) across the resulting trusted domains. Hence a total trust framework for SOA governance includes the ability to:
? Certify identity
? Validate identity certification credentials
? Establish trust between domains
? Federate identity authentication operations
Declarative Policy Definition Environment
Once a mechanism exists to establish trust and validate identity between SOA consumers and services, there needs to be a clear, uncontestable way of defining SOA security policy. Since each SOA business process can have a distinct security relationship between the service consumer and provider, there needs to be a way of defining SOA security policy tailored to each service consumer and provider relationship. This requires an ability to declaratively define identity-specific security policies. However, security policies are not monolithic. They are assembled from atomic security assertions that express security preferences.
Defining security preferences inside an SOA security policy requires an ability to assemble a policy statement from these atomic security assertions. It also requires an ability to prescribe how these policy statements or expressions are to be processed. Variability based on the successful execution of a security assertion, specific message content, or real-time event needs to be accommodated. Adding the ability for a policy to branch or change based on a transaction dependency makes security adaptive and integrations flexible.
An ideal SOA security-policy authoring environment would include a facility for constructing complex policy statements and execution instructions from atomic security assertions. It would test and validate policies to ensure they don?t violate corporate security rules. It would allow policies to be templated and inherited to improve consistency. And it would provide lifecycle controls so that policy statement versions can be shared between multiple authors.
Automated Policy Provisioning, Coordination and Contracting
SOA governance requires the ability to define, provision, execute and verify trust and policy instructions in SOA. However since SOA is fundamentally an integration framework, these trust and policy instructions need to be agreed upon or contracted by service consumers and providers in advance of the first data exchange.
The most straightforward mechanism for accomplishing this involves a service provider publishing a policy contract that can be consumed by a service consumer in some legally verifiable way. Compliance can then be checked against the policy contract. This could be accomplished through out-of-band developer mechanisms or in-band automated mechanisms that allow SOA providers and consumers to dynamically negotiate a service policy contract in-band.
Clearly, the fastest and least error-prone system would involve an in-band automation mechanism. Several products exist to satisfy this need for SOA.
Compliance Verification Framework
Once technologies are in place to control identity and trust, security policies are declaratively defined, and those policies are provisioned and coordinated between SOA consumers and providers, a runtime compliance verification framework must exist to complete the SOA governance picture. This requires an ability to police, audit, alert and potentially update security policy dynamically.
Just as a security camera or security guard is required to maintain compliance to physical security policy, automated monitoring of SOA security policy is required to fully establish SOA policy compliance. Companies need to make sure the security policy they have employed accomplishes the goals they have set to meet their required levels of trust and security. Assets that might be at risk if a breach does happen must be met by an automated response to remedy the problem.
Policing
The central requirement of a compliance verification framework is a system for policing SOA behavior. This requires an ability to monitor how services perform in real-time by inspecting the data entering and leaving an SOA provider. With visibility, a service provider?s behavior can be checked or validated against a predefined policy prescription. Policy violations can then be captured and used to generate remedial events like an alert, service shut-down, or active update to the service provider?s policy.
Audit
SOX rules require organizations to log IT transactions to provide auditing capability and non-repudiation. Audit in an SOA transaction could involve tracking any number of activities and incidents. First and foremost, audit in SOA must provide evidence that a particular identity accessed a specific service resource; the service consumer?s request satisfied the service provider?s security policies (communication integrity, privacy, data cleanliness, etc.); and that the service provider?s response satisfied security and performance contracts established with the service consumer (particularly if an SLA is specified in the policy). Secure logging of what happened, when, by whom and under what terms in an SOA communication underpins any forensic audit of a transaction.
Alerting
Generating notifications or alert events from policy violations is essential for effective compliance. When SOA transactions violate security behavior contracted between an SOA service consumer and provider, some alert notification must occur for compliance verification to be effective.
Alerts can be represented as alarms directed to a human administrator. Alternatively, they can be real-time electronic events that in turn are used to trigger an automated remediation event like service shut-down or policy change.
Remediation
Real-time policing and forensic audit are essential for identifying trust and policy violations in SOA. Violations in contracted behavior between a service consumer and provider necessitate immediate remediation for effective SOA governance.
A facility for generating real-time alerts is clearly the first step toward remediation. Timely alerts mean a human operator can take corrective action once they?ve been notified of a policy violation. Alternatively an alert can be used to trigger an event that can directly affect policy or operation in an SOA transaction, ensuring the transaction is dynamic enough to adapt to trust or policy violations with automated remediation. This should be the ultimate goal in any compliance verification framework, since it most closely adheres to the SOA precept of flexible, just-in-time integration.
Verification mechanisms such as the ones described above can be constructed or purchased off the shelf.
Conclusion
SOA is transforming IT. Sarbanes-Oxley is similarly transforming how IT is governed. Ensuring that SOA fits within the new governance imperative requires a rethink of basic concepts around trust, policy creation, policy implementation and policy verification. By piecing together a few key technologies, companies can satisfy compliance requirements set down by SOX legislation while maintaining the flexible, integrated application environments afforded by SOA.
Dr. Toufic Boubez (and Jonathan Rosenberg)
Co-Founder
Layer 7 Technologies
Toufic Boubez is a well-respected Web services visionary. Prior to co-founding Layer 7 Technologies, Toufic was the Chief Web Services Architect for IBM's Software Group and drove their early XML and Web services strategies. He co-authored the original UDDI API specification and participated in several standards bodies, including the UN/CEFACT/OASIS ebXML initiative. Toufic also managed some of IBM Global Services? largest e-business engagements.
Toufic is also actively involved with various standards organizations such as WS-I, OASIS, and ACORD and co-author of WS-Trust and WS-SecureConversation.
Toufic holds a Master of Electrical Engineering degree from McGill University and a Ph.D. in Biomedical Engineering from Rutgers University.
Dr. Jothy Rosenberg is a serial entrepreneur. He is a founder, director and CTO of Service Integrity, a company that helps Web service operators see, measure, understand and fully leverage operational and business information flowing across their Web service networks. Prior to this venture, Jothy co-founded GeoTrust, the world?s second largest certificate authority. As the company?s COO and CTO, Jothy led GeoTrust?s product development initiatives, bringing to market a series of ground breaking security products. Previous to GeoTrust, Jothy served as CEO and CTO of NovaSoft (renamed Factpoint), Inc, a. pioneer in the area of content management and content certification. He also co-founded Webspective, which was later sold to Inktomi for $106M.
Jothy also held various executive positions at Borland International, including Vice President and General Manager of the Enterprise Tools Division. Jothy was head of languages tools development for multiple versions of Borland C++. He guided the shipment of Delphi 1.0 and created the initial JBuilder project. Jothy holds a B.A. in Mathematics from Kalamazoo College and a Ph.D. in Computer Science on VLSI Design algorithms from Duke University. He is the author of ?How Debuggers Work?, ?Securing Web Service with WS-Security? and the holder of several patents.
|
|
|
|
|
