Application security needs service firewalls

Open standards such as XML and Web services hold the promise of greatly simplified application integration. They offer a more flexible application infrastructure, reduced development time and cost, faster time to deployment, increased collaboration with partners and suppliers and the potential for increased customer retention and satisfaction. But while the benefits are many, XML and Web services also introduce significant security risks because they require companies to selectively expose pieces of their enterprise applications to partners, customers and others to enable real-time interactions.

As a result, security must be a critical concern for any company considering these methods of simplified application integration. Achieving the required application-level security represents a major hurdle in realizing the promises these technologies embody.

A new concept in application security — the service firewall — holds the promise of providing the protection XML and Web services applications require. Service firewalls reduce the risks associated with integrating applications by systematically securing and monitoring bi-directional messages between business partners, customers and others while removing the burden of hard-wiring such security into each application.

With XML already being widely adopted by businesses to integrate applications both inside and between enterprises — and expose business functionality — security is not a problem that can be put off until tomorrow.

XML is already being used to replace EDI systems, eliminating expensive VAN fees, and XML is the de facto standard for exchanging business information between systems for new enterprise portal solutions. XML is simple and easy to understand, and businesses are making use of it today.

But the application-level security risks of using XML are many, including unauthorized access to critical application logic, system crashes by "flooding" applications with denial of service requests and data theft by hackers impersonating trusted machines.

Applications must be built with the highest degree of security to protect data integrity and valuable corporate resources. They must also be designed to accommodate quick modifications to meet changing market demands and scale to grow with the business.

At the same time, enterprise architectures are increasingly heterogeneous, meaning no single standard and no single proprietary platform can solve the interoperability problems of application security.

Application architects, attempting to meet business demands for more integrated applications, have emphatically complained about the lack of products that quickly and systematically secure XML-based integration and Web services.

Although several solutions provide "Internet security" or "application security," they focus on the human-to-machine problem, and secure applications by authenticating user identities.

They were not designed to secure machine-to-machine interactions. Single sign-on (SSO) technologies, for example, make it easier for one user to access multiple applications within or across organizations through a portal, but do not address the security requirements between the applications at the back end where the data is accessed. SSO solutions do not offer a single enforcement point to authenticate, authorize and validate XML integration or Web services.

To get around these limitations, it has been necessary to rely on the costly, time-consuming and difficult to manage process of custom coding of security into each application.

Coding security from low-level APIs often leads to security holes as buffer lengths go unchecked and implementation mistakes are made. Using higher-level class libraries results in applications with multiple, proprietary security enforcement policies.

A "service" is a function within an application called upon by another application to perform some task or transaction. Each time a service is accessed, it becomes vulnerable to attack. As a result, even the most basic interactions between services need to be secured, and this need will escalate rapidly as services proliferate within and across organizations. Each service will need to be secured in multiple places and managed centrally. A service firewall is designed to do just that.

Doubling up security

A service firewall secures applications at the service level, and is very different from what a network firewall provides. In fact, the two should be used together to provide a more complete corporate security solution.

Network traffic is in the form of packets, while application traffic is in the form of messages. A service firewall monitors, secures and controls all XML-based messages flowing between the enterprise, partners, customers and others. A service firewall also offers greater levels of security and message handling functionality than application servers can provide. It does so by separating security, control and management of the service from the business logic in each application. This reduces the opportunity for developers to introduce errors or backdoors, and allows administrators to independently define and audit security policies.

Every architect and application security developer should be asking themselves the following questions: How can I deploy services into my environment using open standards while maintaining the security of my application, and would my application pass the high security requirements of my trading partners, shareholders and peers?"

To answer these questions, it helps to explore three concepts for addressing XML and Web services security: prevention, detection and correction.

When using XML and other open standards, application architects need to prevent fraudulent and improper access attempts. Specifically, access should be granted only to authorized clients who have been properly identified by the correct syntax and semantics.

All other attempts, which can include everything from poorly constructed messages from legitimate partners to malicious attacks by would-be intruders, should be blocked. The challenge here is to be able to detect the presence of a valid, authentic and authorized request without being susceptible to one form of attack or another.

In practice, hard-wiring this defensive security logic into every application requires very specialized knowledge, and has proven difficult to master. Experience has shown it is much more effective to centralize all security measures in a single, well-architected system. Further, by deploying the security functionality in a service firewall on a different server from the application, the system gains an added layer of protection.

The foundation of any good security system is well-designed monitoring that can detect and report on both the normal and abnormal operation of a service and generate a log of all activity. A service firewall can use logs to determine when an intrusion attempt occurs, and what the intruder has done.

A log includes all aspects of the client request, including the associated headers, envelope and client certificate. The same goes for any response that is received in reply. Without a robust log, anyone who bypassed the security and gained access would be able to complete transactions unnoticed, and, therefore, could not be stopped.

Services are by design decentralized, but significant returns in efficiency and monitoring capability can be gained by centralizing logging. If the log is centralized, it can show patterns of access that are played out across multiple systems, something that would be significantly more difficult if each system did its own logging and the logs had to be manually aggregated.

Both the state of the security system and the application must be corrected any time security is compromised. The inefficiencies of the security solution must be corrected before the application can be restored to its previous state.

A security system should be flexible and easy to reconfigure after the nature of a security breach has been determined to keep all systems up and running. Simple information retrieval will likely not require any manual intervention. The security system needs to keep a complete log of all messages that have been sent or received. This single log allows application administrators to determine what parts of a distributed application may have received erroneous messages and will need to be examined.