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

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


• 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


• 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


• 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


checkAccess1 1

*

*

*communicatesThrough

Application

*Service

serviceIdexecuteService()

Client

id

credentials

PoliciesDefinitionPoint

authenticate()

grantAccess()

log()

definePolicy()

defineUser()

defineRole()

removeUser()

removeRole()

PolicyBaseIdentityBase

PoliciesEnforcementPointinterceptMessage()

controlAccess(url, id, credentials)

Identity

id

credentials

roles

Policy

serviceId

role

predicate

1

accessService* *

ApplicationFirewall

1 *

11

*

Role* *memberOf

*

Application Level

Implementation Level

requestServiceMessage

11

The Application Firewall Pattern• Dynamics: Filtering a Client’s Request

:Client: Policies

EnforcementPoint: Policies

DefinitionPoint: IdentityBase : PolicyBase :Application

interceptMessage()interceptMessage()

checkAccess(uri, id, credentials)checkAccess(uri, id, credentials)

requestService(uri, id, credentials)requestService(uri, id, credentials)

authenticate(id, credentials)authenticate(id, credentials)

userAuthenticateduserAuthenticated

grantAccess(uri, roles)grantAccess(uri, roles)

getRoles(id)getRoles(id)

rolesroles

accessGrantedaccessGrantedaccessGrantedaccessGranted

accessServiceaccessService

log()log()

:ApplicationFirewall

requestService(uri, id, credentials)

requestService(uri, id, credentials)

requestAcceptedrequestAccepted

12


• Dynamics: Adding a new Policy

addPolicy(policy)addPolicy(policy)

: PolicyBase:ApplicationFirewall

: Administrator

checkDuplicate(policy)checkDuplicate(policy)

CheckDuplicate == TrueCheckDuplicate == True

addPolicy(policy)addPolicy(policy)

PolicyAddedPolicyAddedPolicyAddedPolicyAdded

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


• 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


• Implementation1.Define users.

2.Define policies for the institution and hold policy base (Use Case 2).

3.Add/Remove policies when needed

16


• Known Uses– Cerebit innerGuard – Netegrity SiteMinder – Reactivity XML Firewall – Vordel XML security server – Westbridge XML Message Server – Netegrity TransactionMinder

17


• 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


• 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

uriexecuteService()

Client

id

credentials

PolicyBaseIdentityBase

Identity

id

credentials

roles

PolicyserviceId

role

predicate

1

accessService* *

1

*

11

*

Role* *memberOf

*

1

PolicyEnforcementPointinterceptMessage()

controlAccess(url, id, credentials) ContentInspector

PolicyDefinitionPoint

authenticate()

grantAccess()

log()

definePolicy()

defineUser()

defineRole()

removeUser()

removeRole()

SchemaDatabase

addSchema()

removeSchema()

updateSchema()

XMLSchemaValidator

HarmfulDataDetector

11

XMLMessage

Application Level

Implementation Level

checkAccess

1 1

1

XMLFirewall

requestService

23


• Dynamics: Filtering a Client’s Request:Client

: PoliciesEnforcementPoint

: PoliciesDefinitionPoint

:Application

controlAccesscontrolAccess

requestServicerequestService

accessGrantedaccessGranted

accessServiceaccessService

:XMLApplicationFirewall

checkContentcheckContent

requestAcceptedrequestAccepted

: ContentInspector

: XMLSchemaValidator

: HarmfulDataDetector

validateSchemavalidateSchema

schemaValidatedschemaValidated

checkDatacheckData

dataCheckeddataChecked

contentCheckedcontentChecked

checkAccesscheckAccess

24


• 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


• Known Uses– Reactivity’s XML Firewall – Vordel’s XML Security Server – Netegrity’s TransactionMinder

26


• Related Patterns– Application Firewall

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

Documents

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