1 / 26

Patterns for Application Firewalls

Patterns for Application Firewalls. Eduardo B. Fernandez Nelly A. Delessy Gassant. Agenda. Introduction The Application Firewall Pattern The XML Firewall Pattern. Introduction.

ulf
Télécharger la présentation

Patterns for Application Firewalls

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related