A higher level of structural and operational endurance and ruggedness can be achieved in software systems by strategically introducing crumple zones (CZs) in the system architecture. Analogous to the crumple zone in an automobile, a CZ stands before critical components and “absorbs” the effects of attacks by localizing or eliminating the damage they can cause and leaving the critical components intact and unaffected. The concept of software CZs is broadly applicable; this work focuses on CZs for SOA.
SOA is an architecture paradigm gaining popularity in military and civilian information systems, many of which play important roles in national security. Mission-critical systems face a highly contested and hostile environment in realworld operations, and must endure and withstand malicious attacks. Potential threats against critical SOA-based systems range from automated network worms targeting SOA platform and supporting services, to individual vandals, to wellmotivated and expert foreign intelligence apparatus that aim to subvert operations in the DoD enterprise and critical missions. The adversary objective may range from denying access to the system, to using the system without authorization, to tampering with or fabricating data in storage or in transit.
As a technology, SOA is still maturing and various aspects of SOA, including security features, are still being standardized. Furthermore, available SOA infrastructure and platforms do not always implement all of the available and specified standards. The complexity of SOA platforms combined with their rapid evolution can lead to implementers under-using or misusing available security features due to lack of expertise. Security of SOA systems is often limited to perimeter and network-level security.
The CZ is, in basic terms, a layer of intelligent service proxies that work together to present a high barrier to entry to the adversary, to increase the chance of detection of malicious activities, and to contain and recover from failures and undesired conditions caused by malicious attacks. These proxies collectively implement the service’s consumer-facing application programming interface. Different proxies help contain malicious activity by applying security checks and controls, then approving data for release if it passes those checks. A key principle of the CZ’s design is that only data that has been inspected and approved by one or more proxies is passed along to the service.
Because the CZ inspects and processes untrusted data, it is expected to fail occasionally. Automatic monitoring and re-start of the proxies inside the CZ is another key design feature. Effective ness of the CZ depends on three requirements:
• The CZ must be non-bypassable. All consumer requests to the service must be mediated through the CZ.
• The CZ must cover both known and unknown attacks. It should be configurable so defenses can be tailored to the system’s operational requirements and the potential threat environment.
• The CZ must preserve the integrity of data that flows through it to prevent man-in-the-middle scenarios run by corrupted CZ components.
To meet the first requirement, making the CZ non-bypassable, conventional network-level protections such as firewalls and routers can be used. To make it difficult for adversaries to discover and access protected services, the CZ presents a very small ex ploitable surface to untrusted service consumers. This is accomplished by placing the CZ behind a firewall that uses single packet authorization (SPA). On the CZ’s side of the firewall, termination proxies (TPs) are used as the entry point for all incoming client connections.
The second requirement, varied and configurable defenses, is achieved through a set of proxies that implement specific checks and are organized in a mechanism proxy cloud (MPC). The MPC monitors observable behavior of requests. Proxies check assertions on application data, e.g., by checking serialization fields, and canary proxies consume application data and thereby absorb attacks, e.g., by crashing or getting corrupted.
The third requirement, preserving data integrity within the CZ, is achieved by service layer virtual private groups (slVPG). The Splitter component replicates Secure Sockets Layer (SSL) streams between clients and TPs to the MPC without breaking cryptographic envelopes. Key management components that are also part of the slVPG selectively share keys from the TPs to the MPC so that the new streams can be decrypted for inspection.
This work was done by Asher Sinclair of the Air Force Research Laboratory; Michael Atighetchi, Partha Pal, Aaron Adler, Andrew Gronosky, Fusun Yaman, Jonathan Webb, and Joe Loyall of Raytheon BBN Technologies; and Charles Payne of Adventium Labs. AFRL-0200
This Brief includes a Technical Support Package (TSP).
Crumple Zone Software Absorbs Attack Effects Before System Failures
(reference AFRL-0200) is currently available for download from the TSP library.
Don't have an account? Sign up here.