Sarbanes-Oxley Compliance

How do you auditing and reporting on machine-to-machine interactions in a SOA?

The Problem: Knowing Which Machine Accessed What, When

The financial controls and reporting required by the Sarbanes-Oxley Act of 2002 (SOX), forces 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 requires identity and access infrastructure that can both control and validate user-machine interactions as well as SOA-based machine-machine interactions. Because SOA transactions can span multiple intermediaries, transports and identity domains this is difficult to implement in practice.

Solution: SOA Auditing and Reporting

Section 404 requires 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 insuring financial information is not compromised during transmission.
Controlling machine to machine access requires an ability to provision identities for machines, certify those identities with some non-reputable credentialing mechanism like PKI and establish an evidence trail for authentications even when those authentications span identity domains. Similarly, the problem of controlling what information is accessed in a SOA, requires an ability to manage entitlements at a service or operation level. And since SOA transactions can span multiple intermediaries this also requires an ability to enforce authorization decisions consistently across multiple interconnected services. Transmission integrity must similarly be rethought because of the multi-hop nature of SOA - transport mechanisms like SSL won’t be enough.

Layer 7 Value: SOA Governance

Through the SecureSpan Firewall and VPN, Layer 7 can uniquely satisfy Sarbanes-Oxley requirements for SOA. The SecureSpan Firewall can extend existing identity systems to Web services including identity information for machines. The SecureSpan Firewall and VPN working in concert can provision and manage PKI to SOA consumers and provide an extensive evidence trail for distributed cross-domain authentications.

For managing and auditing access decisions in a SOA, the SecureSpan Firewall can be deployed as either hardware or software, managing any number of cascading SOAP and non-SOAP Web services. Access decisions can be based on URL, URI, SOAPAction or user defined XML element and can be orchestrated with other policy instructions defined inside the SecureSpan Firewall or an external policy store.

To protect the integrity of financial information passed across a multi-hop SOA transaction, the SecureSpan Firewall and VPN product line provides the seamless definition, application and enforcement of XML / SOAP encryption and signing using a simple graphical user interface. To protect against compromises including message spoofing (man-in-the-middle attacks) or session hijacking (replay attacks), the SecureSpan Firewall automatically negotiates cryptographic keys each security session with the SecureSpan XML VPN Client or any WS-SecureConversation compliant client application.

Share: | More

Resources

White Paper:
Sarbanes-Oxley in SOA  

Download PDF |  6Kb

Datasheet:
XML Firewall 

Download PDF | 196Kb

Solution Brief:
Identity Based XML Firewalling 

Download PDF | 208Kb

Datasheet:
XML VPN Client

Download PDF | 196 Kb

Solution Brief:
XML VPN Solutions 

Download PDF | 208 Kb