Security as a Service

Why web application firewalls make sense in a service-oriented world

When architects begin designing their organizational SOA one of the first tasks they need to undertake is to discover and document myriad services that can be shared across applications. While many architects are aware of - and even address - the need for common identity services, most still overlook application security as one of the logical sets of common code that can be abstracted into a service and shared for optimal reuse and efficiency. This makes very little sense from a SOA perspective, as these services are often more obviously a fit for a shared service than many pieces of logic that will become services across the organization.

Web application firewalls (WAFs) are inherently service-oriented; offloading shared security services such as threat defense into a single, reusable service that is loosely coupled with the rest of the infrastructure.

While some types of security should remain in the service or application, implemented by developers, there are common, shared security services that make more sense to deploy in a single location in all environments but especially in an SOA. Preventing buffer overflow-based exploits and ensuring the validity of application data in terms of data integrity should be the responsibility of the service or application developer as these are often specific to the application and not necessarily common across all applications.

But the prevention of SQL and command injection attacks, addressing the possibility of cookie and schema poisoning, and stopping cross site scripting (XSS) attacks are common to all applications and services and therefore should be abstracted into shared services and preferably hosted at the edge of the network.  

WAFs provide service-oriented threat defense against a wide variety of attack vectors including application, web, and database specific exploits. WAFs also align perfectly with the goals of SOA in all three core categories: agility, reuse, and risk mitigation.

Agility

WAFs are, in general, loosely coupled with the services they are protecting. Upgrading or changing the security services therefore does not adversely affect protected services. This is not true when security is hard-coded into the application, because changes to the code that provide the security necessarily requires that not only the affected service be retested and redeployed but all dependent services to ensure no adverse effects.

WAFs are also, in general, loosely coupled themselves. While many rely on signature databases across a number of areas, these databases can be updated at any time without requiring changes to the WAF interface presented to the client.

WAFs are also agile in their extensibility. By providing administrators with the capability to utilize regular expressions and pattern matching techniques to dynamically extend the threat defense capabilities they remove the need to make changes to the code as would be necessary if security is implemented within each service. The ability to extend security in a shared service reduces the time to push out security responses to new threats and decreases the overall cost of addressing new vulnerabilities as they appear.

Reuse

Many of the security services provided by WAFs would need to be duplicated if deployed in each service requiring defense. Scanning for SQL injection or malicious data, for example, would certainly be required in every service if it was not provided by a centralized, WAF service. By using a WAF to provide this and other threat defense services you reduce the time and effort required to update shared code that would otherwise by required.

Mitigating Risk

While both centralized and distributed models of threat defense mitigate risk by attempting to detect and prevent attacks, doing so at the edge of the network using a WAF has added advantages not only in the security arena but also in performance management. Given the inherent compute intense nature of processing SOA and XML-related data, it makes sense to prevent invalid requests from reaching services and tying up resources only to be rejected by the service. Rejecting malicious requests at the edge keeps services available to process valid requests and increases performance in general by reducing the load on services.

WAFs are a natural fit for providing Security as a Service within the enterprise; as a platform for providing threat defense services as a first-class citizen of the organizational SOA ecosystem. Service-enabling security where it makes sense - signature scanning, SQL and command injection scanning, cookie and schema poisoning, and cross-site scripting prevention - should be part of your SOA discovery and design.

If it's not, then you're missing out on the opportunity to provide better security for all services as well as increasing the overall performance and security of your SOA infrastructure.

Imbibing: Coffee