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

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

3. 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. 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. 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. 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. 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. 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. 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. 10 The Application Firewall Pattern checkAccess 11 * * * communicatesThrough Application * Service serviceId executeService() Client id credentials PoliciesDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() PolicyBaseIdentityBase PoliciesEnforcementPoint interceptMessage() controlAccess(url, id, credentials) Identity id credentials roles Policy serviceId role predicate 1 accessService ** Application Firewall 1 * 11 * Role ** memberOf * Application Level Implementation Level requestService Message

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

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

13. 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. 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. 15 The Application Firewall Pattern Implementation 1.Define users. 2.Define policies for the institution and hold policy base (Use Case 2). 3.Add/Remove policies when needed

16. 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. 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. 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. 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. 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. 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. 22 The XML Firewall Pattern * * * communicatesThrough Application * Service uri executeService() Client id credentials PolicyBaseIdentityBase Identity id credentials roles Policy serviceId role predicate 1 accessService ** 1 * 11 * Role ** memberOf * 1 PolicyEnforcementPoint interceptMessage() controlAccess(url, id, credentials) ContentInspector PolicyDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() SchemaDatabase addSchema() removeSchema() updateSchema() XMLSchema Validator HarmfulDataD etector 11 XMLMessage Application Level Implementation Level checkAccess 11 1 XML Firewall requestService

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

24. 24 The XML Firewall Pattern Consequences –Additional advantage 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. 25 The XML Firewall Pattern Known Uses –Reactivity’s XML Firewall –Vordel’s XML Security Server –Netegrity’s TransactionMinder

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