patterns for content firewalls
TRANSCRIPT
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
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
The Application Firewall Pattern
• 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
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
• Implementation1.Define users.
2.Define policies for the institution and hold policy base (Use Case 2).
3.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
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
The XML Firewall Pattern
• 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
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