Patterns for content firewalls
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Patterns for content firewalls

on

  • 1,827 views

 

Statistics

Views

Total Views
1,827
Views on SlideShare
1,827
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Patterns for content firewalls 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. The Application Firewall Pattern checkAccess 1 1 * * * communicatesThrough Application * Service serviceId executeService() Client id credentials PoliciesDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() PolicyBase IdentityBase PoliciesEnforcementPoint interceptMessage() controlAccess(url, id, credentials) Identity id credentials roles Policy serviceId role predicate 1 accessService * * Application Firewall 1 * 1 1 * Role * * memberOf * Application Level Implementation Level requestService Message
  • 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 accessGranted accessService log() :ApplicationFirewall requestService(uri, id, credentials) requestAccepted
  • 12. The Application Firewall Pattern
    • Dynamics: Adding a new Policy
    addPolicy(policy) : PolicyBase :ApplicationFirewall : Administrator checkDuplicate(policy) CheckDuplicate == True addPolicy(policy) PolicyAdded PolicyAdded
  • 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. The XML Firewall Pattern * * * communicatesThrough Application * Service uri executeService() Client id credentials PolicyBase IdentityBase Identity id credentials roles Policy serviceId role predicate 1 accessService * * 1 * 1 1 * Role * * memberOf * 1 PolicyEnforcementPoint interceptMessage() controlAccess(url, id, credentials) ContentInspector PolicyDefinitionPoint authenticate() grantAccess() log() definePolicy() defineUser() defineRole() removeUser() removeRole() SchemaDatabase addSchema() removeSchema() updateSchema() XMLSchemaValidator HarmfulDataDetector 1 1 XMLMessage Application Level Implementation Level checkAccess 1 1 1 XML Firewall requestService
  • 23. The XML Firewall Pattern
    • Dynamics: Filtering a Client’s Request
    :Client : Policies EnforcementPoint : Policies DefinitionPoint :Application controlAccess requestService accessGranted accessService :XMLApplicationFirewall checkContent requestAccepted : Content Inspector : XMLSchema Validator : Harmful DataDetector validateSchema schemaValidated checkData dataChecked contentChecked checkAccess
  • 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. 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