integrity. Logs, in contrast, have immediate relevancy for diagnostic purposes, but less long-term value for forensics. As a result, logs commonly rotate automatically over old entries to keep the collection size within reasonable bounds.

Persistence of logs and audits in cloud providers is problematic. Audits (and optionally logs) must stream to long-term resilient storage instead of local disks that will be lost on instance termination. Syslog is one accepted mechanism to do this. Audits, however, should also be cryptographically secure to prevent disclosure of sensitive message contents (such as security credentials), and to guard against alteration. This can be computationally expensive to apply at run time.

Audit volumes can be very large. Data transfer costs between cloud providers on-premise faculties can be very high [1], making streaming or export of audit and log data to existing tools impractical.

Metrics collection may also produce very large data volumes. It is often necessary to record historical transaction rates for purposes of future load planning, so most SOA PEPs maintain sliding counters describing each service under their management. Depending on the time granularity of the bin, these data structures can become extremely large. Regular transfer to on-premise storage can incur considerable cost. Leveraging inexpensive local cloud storage can offset this, as evaluation of this data generally involves a rollup inside a reporting engine that can reside in the cloud.

Other existing SOA PEP alerting mechanisms may also be infeasible in the cloud. Policy-driven alerts that use SNMP to communicate with on-premise management infrastructure may be impractical because of security risks and latency. SMTP-based altering, common in on-premise SOA, may not be feasible to implement in the cloud. Cloud providers do not want their platforms to become a launching pad for spam traffic, so may block outgoing SMTP traffic. Furthermore, there are anecdotal reports of organizations blacklisting mail from Amazon AWS IP ranges because of the threat of spam [25].

A final issue is event correlation between infrastructure elements during forensic investigation. In traditional on-premise SOA, logs from routers, load balancers, and conventional firewalls provide extremely valuable data to operators investigating issues, such as an attack or transaction failure. These data are not available to customers in the cloud.

18.4.14  Repositories

One of the challenges of virtualized cloud environments is the ephemeral nature of the operating environment. Centralized policy and configuration repositories provide an important service in cloud environments to manage this. They function as the system of record – that is, the central authoritative source for policy and configuration that can be pushed to PEP enforcement points. Repositories must leverage long-term, scalable storage in cloud environments to mitigate potential loss of data on instance termination.

Commercial SOA registry/repository offerings, such as those from SoftwareAG, HP, and IBM, take on management of all the metadata associated with services. These incorporate workflow around asset creation and authorization, environment migration, and deployment of policy and service into production. At present, these are not cloud-centric. Turnkey cloud management and security solutions, such as RightScale and Symplified, implicitly have some of these capabilities in their offerings, but these are not general cloud registry/repositories. The generalized cloud policy registry/ repository will become an important infrastructure component for cloud-based PEPs, but at present, there are no commercially successful implementations of this.

18.4.15  Provisioning and Distribution

Policy naturally assimilates dependencies on local information that may change as the policy moves between environments. Consider a migration from development, to QA, and finally into production environments: the IP addresses change, as do dependencies on external systems such as PDPs, representations of identity, etc.

Elastic computing exacerbates the dependency problem. Policy content may change in response to variation in traffic volume. Some of these changes are deterministic and thus solvable using simple mappings applied to policy documents. At present, there is no comprehensive and standardized solution to this challenge.

18.4.16  Policy Synchronization and Views

Synchronization of policy between PEPs in the on-premise DMZ and PEPs deployed in the cloud is an open issue. The existing protocols address some simple aspects of security. SSL/TLS, for example, incorporates a negotiation mechanism that converges on a cipher suite common to both parties. A similar approach is required for other aspects of policy.

WS-Security Policy (Nadalin et al. 2007) provides a means for a service provider to declare a means to secure a transaction using either SSL or WS-S messagebased security. Its scope includes confidentiality, integrity, and security tokens.

This approach provided the much-needed declarative policy around security, but much work remains. There is a need for a standardized approach to negotiate a reciprocal policy contract (like SSL does), as well as declaration of traditionally out-of-band parameters of policy such as transport compression. In the absence of this, synchronization of policy remains largely a manual operation.

The determination of appropriate policy views for a client, based on factors such as identity and entitlements, is an open area of research. All policies contain elements not intended for client consumption, such as authorization rules or internal routing. Accurate and secure resolution of suitable externally facing views of policy is an unresolved problem in need of further investigation.