Patterns for Application Firewalls

1. Patterns for Application Firewalls Eduardo B. Fernandez Nelly A. Delessy Gassant

2. Agenda • Introduction • The Application Firewall Pattern • The XML Firewall Pattern

3. Introduction • Driven by business imperatives, organizations have to open up their systems to a wide variety of partners, customers or mobile employees. • Web applications and web services made it possible to easily access their internal network from the outside, introducing new types of threats: • Increasing number of user categories  misuse more likely • Each application implements access control  Increased complexity  weakens security of the whole system

4. Introduction • New types of threats: • New accesses realized by using or by tunneling into existing protocols (HTTP, SMTP, …) evade access control to services performed by traditional firewalls • Payload of these messages can embed harmful data • Common solution: to add an Application Firewall to the traditional line of defense defined by network-based firewalls. • 2 patterns can be abstracted from current commercial offers: • the Application Firewall (general scheme) • The XML Firewall (firewall specialization)

5. The Application Firewall Pattern • Intent • To filter calls and responses to/from user-defined applications, based on an institution access control policies. • Aka • Content Firewall

6. The Application Firewall Pattern • Context • User-defined applications executing in distributed systems accessed through a local network, from the Internet, or from external networks. • Specific security policies have been defined by the institution, expressed as authorization rules.

7. The Application Firewall Pattern • Problem • User-defined applications in an organization’s internal network are accessed by a broad spectrum of users that may attempt to abuse its resources (leakage, modification or destruction of data). • These applications can be numerous, thus implementing access control independently for each of them may make the system more complex, and thus less secure. • Traditional network firewalls (application layer firewalls or packet filters), do not make it possible to define high level rules (role-based or individual-based rules) that could make the implementation of business security policies easier and simpler.

8. The Application Firewall Pattern • Forces • There may be many users (subjects) that need to access an application in different ways; the firewall must adapt to this variety. • There are many ways to filter, we need to separate the filtering code from the application code. • There may be numerous applications, that may require different levels of security. • The business policies are constantly changing and are constantly updated; hence it should be easy to change the firewall configuration. • The number of users and applications may increase ; adding more users or applications should be done transparently and at low cost.

9. The Application Firewall Pattern • Solution • A client can access a service of an application only if a specific policy authorizes it to do so. • Policies for each application are centralized within the Application Firewall, in a PolicyDefinitionPoint. • Each application is accessed by a client through a PolicyEnforcementPoint, that enforces the access control for the applications. • Enforcement includes authenticating the client through its identity data stored in the PolicyDefinitionPoint and looking for a mapping policy for the request.

10. Application * memberOf Role * * * IdentityBase PolicyBase Application Level accessService checkAccess 1 1 * * Implementation Level * 1 Application Firewall * requestService Message * * Service serviceId executeService() * Client id credentials 1 1 PoliciesDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() PoliciesEnforcementPoint interceptMessage() controlAccess(url, id, credentials) 1 Policy serviceId role predicate Identity id credentials roles communicatesThrough The Application Firewall Pattern

11. : Policies EnforcementPoint :ApplicationFirewall : Policies DefinitionPoint : IdentityBase : PolicyBase :Application :Client requestService(uri, id, credentials) interceptMessage() requestService(uri, id, credentials) checkAccess(uri, id, credentials) authenticate(id, credentials) userAuthenticated getRoles(id) roles grantAccess(uri, roles) accessGranted accessGranted log() requestAccepted accessService The Application Firewall Pattern • Dynamics: Filtering a Client’s Request

12. : Administrator :ApplicationFirewall : PolicyBase addPolicy(policy) checkDuplicate(policy) CheckDuplicate == True addPolicy(policy) PolicyAdded PolicyAdded The Application Firewall Pattern • Dynamics: Adding a new Policy

13. The Application Firewall Pattern • Consequences • Advantages • The institution policies to control access are easily defined and administered, as the policies are centralized. This makes the whole system less complex, and thus more secure. • This facilitates the detection of possible attacks. An Intrusion Detection System can be combined with this firewall. In turn, the IDS can help the firewall block suspicious requests. • The firewall lends itself to a systematic logging of incoming and outgoing messages. • As authentication of Clients is performed, it holds regular users responsible of their actions. • New applications are easily integrated into the system by adding their specific policies. • New clients can de accommodated by adding new policies to the policy base of an application.

14. The Application Firewall Pattern • Consequences • Possible liabilities • The application could affect the performance of the protected system as it is a bottleneck in the network. This can be improved by considering the firewall a virtual concept and using several firewalls for implementation. • The solution is intrusive for existing applications that already implement their own access control. • The application itself must be built in a secure way or normal access to commands could allow attacks through the requests. • We still need the Operating System to be secure.

15. The Application Firewall Pattern • Implementation • Define users. • Define policies for the institution and hold policy base (Use Case 2). • Add/Remove policies when needed

16. The Application Firewall Pattern • Known Uses • Cerebit innerGuard • Netegrity SiteMinder • Reactivity XML Firewall • Vordel XML security server • Westbridge XML Message Server • Netegrity TransactionMinder

17. The Application Firewall Pattern • Related Patterns • The Authorization pattern defines the security model for the Application Firewall. • The Role-Based Access Control pattern, a specialization of the authorization pattern, is applicable if the business policies are respectively defined in terms of roles and rights . • The Application Firewall pattern is a special case of the Single-Point of-Access.

18. The XML Firewall Pattern • Intent • To filter XML messages to/from user-defined applications, based on the business access control policies and the content of the message. • Context • User-defined applications executing in distributed systems accessed through a local network, from the Internet, or from external networks. • These applications communicate through XML messages and could be web services or applications using web services. • Specific security policies have been defined by the institution, expressed as authorization rules.

19. The XML Firewall Pattern • Problem • Some user-defined applications use tunneling into authorized flows (HTTP, SMTP,…) to communicate with the outside. They use higher level protocols such as SOAP and communicate through XML documents. • The XML documents in these messages can contain harmful data and can be used to perform attacks against applications. • Network firewalls provide infrastructure security but become useless when these high level protocols and formats are used.

20. The XML Firewall Pattern • Forces • Document formats are subject to change, some new ones may appear (XML dialects); the firewall must adapt easily to these changes. • New types of harmful data may be used by attackers, the firewall must adapt easily to these new types of attacks. • There are many ways to filter, we need to separate the filtering code from the application code. • There may be numerous applications, that may require different levels of security. • New applications may be integrated into the system after the firewall has been put into operation. This integration should not require additional costs.

21. The XML Firewall Pattern • Solution • A client can access a service of an application only if a specific policy authorizes it to do so and if the content of the message sent is considered to be safe for the applications. • Policies for each application are centralized within the Application Firewall, in a PolicyDefinitionPoint. • Each application is accessed by a client through a PolicyEnforcementPoint, that enforces the access control for the applications, by: • authenticating the client through its identity data stored in the PolicyDefinitionPoint • looking for a mapping policy for the request • checking the content of the message: Its structure is validated through a database of valid XML schemas, and the data it conveys is checked through a HarmfulDataDetector.

22. Application * memberOf Role * * Application Level Implementation Level IdentityBase PolicyBase 1 HarmfulDataDetector XMLSchemaValidator accessService 1 1 * * ContentInspector 1 * 1 * XML Firewall requestService * * Service uri executeService() * Client id credentials 1 1 PolicyDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() PolicyEnforcementPoint interceptMessage() controlAccess(url, id, credentials) checkAccess 1 1 1 Policy serviceId role predicate Identity id credentials roles XMLMessage * SchemaDatabase addSchema() removeSchema() updateSchema() communicatesThrough The XML Firewall Pattern

23. : XMLSchema Validator : Content Inspector : Harmful DataDetector : Policies EnforcementPoint :XMLApplicationFirewall : Policies DefinitionPoint :Application :Client requestService checkContent validateSchema schemaValidated checkData dataChecked contentChecked checkAccess controlAccess accessGranted requestAccepted accessService The XML Firewall Pattern • Dynamics: Filtering a Client’s Request

24. The XML Firewall Pattern • Consequences • Additionaladvantage • Provides a higher level of security than the Application Firewall because it inspects the complete XML message (This only applies to XML messages). • Possible liabilities: • The application could to affect the performance of the protected system as it is a bottleneck in the network, and as the XML content checking may create a large overhead. • The solution is intrusive for existing applications that already implement their own access control.

25. The XML Firewall Pattern • Known Uses • Reactivity’s XML Firewall • Vordel’s XML Security Server • Netegrity’s TransactionMinder

26. The XML Firewall Pattern • Related Patterns • Application Firewall