1. Field Systems Engineer F5 Networks Central Europe
This presentation provides a short overview of the F5 FirePass controller.
Traffic Shield
Rainer Singer
Field Systems Engineer
F5 Networks Central Europe

2. TrafficShield™ Web application security gateway
Protects Web site servers and Web applications against known and unknown security threats
Advanced application security policy generation and management
Appliance-based approach
Acts as an application firewall by offloading application servers
Provides high-performance and high-availability
Proxy-based, positive security model
True Layer 7 security
Goes beyond “packet inspection” to “application content and context” inspection
Protects against “Zero-Day” attacks
Examines application requests and replies and verifies that they conform to the application’s security policy
No need for signature databases and patching

3. TrafficShield Solution
Web Servers
Intranet/
Extranet
Legitimate Traffic
Malicious Application Activity
Application Floods
Network Attacks & Floods
Unsupported Services
Internet
Application Servers
Databases

4. The challenge: Ensuring Web application security and availability
Web servers and Web applications are the prime targets for attacks
The challenge: Ensuring Web application security and availability

5. What are the Risks ? Brand and reputation damage
Financial loss as a result of fraud, transaction losses, attack clean-up costs
Theft of sensitive corporate information
Violation of customer privacy and theft of customer data
Example: Code Red estimated cost $2.6B (Computer Economics)

6. Reasons for Web Application Vulnerabilities
Applications were written according to client-server security standards
Complexity of platforms and environments makes secure coding very difficult
Web developers focus on functionality and performance, not on security, they’re not trained for secure programming
Bugs in OS, web platforms and web applications
Web sites are changed and updated frequently
Threat is exacerbated by the availability of:
Web application client-side source code (hackers gain information for planning attacks)
Widely available, free, easy to use hacking tools

7. Attacks on Web Applications
Known and Unknown Web Worms
Known and Unknown Web Vulnerabilities
Illegal Access to Web-server files
Forceful Browsing
File/Directory Enumerations
Brute Force attacks
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
Hidden-Field Manipulation
Parameter Tampering
Flood attacks (GET, 404)
SSL Flooding

8. Traditional Security Solutions Don’t Protect Web Applications
Firewalls:
“Firewalls offer little protection at the application layer because ports within the firewall have to be left open for communication” (IDC 2002)
Network IDS:
“Intrusion detection systems are a market failure, and vendors are now hyping intrusion prevention systems, which have also stalled." (Gartner, 2003)

9. The Fundamental Problem with IPS/IDS
Negative security logic
Lets everything through, except what can be identified as malicious traffic
Based on attack signatures and traffic characteristics
Problems
Protects only against known attacks
Requires constant updating of signatures and characteristics
Doesn’t protect against “Zero Day” attacks
Doesn’t protect against attacks based on illegal user input
Cookie poisoning and hidden-field manipulation
Parameter (form-field) tampering
Forceful browsing
Backdoors and debug-option exploitation

10. Current Approach: Scan-and-Fix
Scanning HTML code for known breaches and then rewriting it
Ineffective and costly
Time-consuming due to high rate of false positives
Doesn’t find all vulnerabilities, requiring manual code review
Requires expensive code rewrites
Slows down product development
Defenseless against new threats, since it only looks for known vulnerabilities

11. Positive Security Logic: A Better Way
All traffic is illegal unless known to be legal
Verifies that the user interacts with the Web application in exactly the way designed by the developer
Like a firewall; minimal ongoing policy management since it does not need to look for specific attack patterns

12. Every Web Application is Exposed
Source code is in browser – can be tampered with!
Firewalls can’t stop them
IPS can’t detect them
Scanning can’t patch them
Current Network Perimeter Security
(Firewall, Virus Scan, IDS, etc.)
Web Browser
Applications
at Risk

13. Example: Parameter Tampering
Here is a simple – but common - example.
When you are in a web application, you often see “user=1234” in the URL. It’s there because the application server needs a way to remember who you are after it serves you the page. (Sometimes this unique identifier is in the URL, sometimes it’s in a hidden field on the page, sometimes it’s in a cookie, but there is always something like this.)
Well, it turns out you can change this URL (or hidden field, or whatever) and often you can access other people’s information in the application! You could guess at the number or run a script to try different ones…
Transition: … or you could get really clever, as assume that this user ID is being passed back to a SQL database, asking for that user’s information. So instead of putting in another user, you substitute a *star* which is the SQL wildcard for anything…

14. Example: Parameter Tampering
…and I get a dump of the entire database!
As far-fetched an example as this seems, we have actually seen this vulnerability at a client.
OPTIONAL EXAMPLE:
Another simple example: whenever you have a web-based form that you are filling out, consider this: they are letting you write to a database, probably the same database that contains other customer information and maybe even other sensitive data. You can often take those fields for “name” and “address” and insert SQL commands – unless the application is checking for them, they will execute when you post the page!
NOTE:
If customer is interested in these examples, offer to give them the “Ten Hacks” presentation.
Transition: so what do we do to protect against this?

15. Traditional Security Solutions Don’t Protect Web Applications
Firewall
Network Firewall
IPS
Known Web Worms
Unknown Web Worms
Known Web Vulnerabilities
Unknown Web Vulnerabilities
Illegal Access to Web-server files
Forceful Browsing
File/Directory Enumerations
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
Hidden-Field Manipulation
Parameter Tampering  
Limited X
Limited
Limited
Partial X
Limited
These are the names of the attacks people generally refer to when they talk about Application Security. Note that it’s all just jargon; everyone has the same list and will claim that they can prevent it all. The real question is: HOW do they prevent it, and can they really prevent these things from happening in real life, in the ways that your applications are vulnerable to?
Transition: Let me give you a specific example…
Limited X X X X
Limited
Limited
Limited
Limited
Limited X
Limited X X X X X X

16. TrafficShield Application Firewall

17. TrafficShield Application Firewall
Web application firewall
Protect web applications against known & unknown attacks
Uses positive security logic – All traffic is illegal unless known to be legal
Content scrubbing
Prohibit delivery of sensitive data
Application cloaking
Hide the identity of web applications from outside probing

18. Protecting Web-based Applications
Scrubbed
Patient Health ePHI
Account Numbers
Any other identifiable text pattern
Credit Card Numbers
Social Security Numbers
Phone Numbers
CONTENT SCRUBBING
Blocked
SQL/OS Injection
Cookie Poisoning
Unknown Worms and Vulnerabilities
Cross-Site Scripting
Buffer Overflow
Broken Access Control
(Forceful Browsing)
Unvalidated Input Manipulation
APPLICATION FIREWALL
Blocked
Non-RFC-Compliant Traffic
Requests for Restricted Object and File Types
Script Kiddies, Known Worms & Vulnerabilities
Included
Out-of-box Protection
15 min
Set-Up Time
Illegal HTTP Format, Method
ATTACK FILTERING
Blocked
Application Error Messages
Leakage of Server Code
HTTP Error Messages
OS and Web Server Fingerprinting
CLOAKING
SSL ACCELERATION & KEY MANAGEMENT
Included
Key Management & Failover Handling
SSL Accelerator
SSL Termination and Re-encryption to Servers
Included
Securing TCP/IP Session
IP/Port Filtering
Reverse Proxy
NETWORK FIREWALL

19. TrafficShield™ Web Application Firewall
Targeted Attacks
Unvalidated Input Manipulation
Broken Access Control (Forceful Browsing)
Buffer Overflow
Cross-Site Scripting
SQL/OS Injection
Cookie Poisoning
[first click]
The core functionality is the ability to tell good requests from bad ones. The jargon people use for this are things like cross-site scripting, cookie poisoning, and SQL injection, among others.
Because we sit at such a crucial point in the infrastructure, customers have asked us to combine some other functionality that it makes sense to so here…
[second click]
For instance,. We have just added Content Scrubbing, which gives you the ability to strip out any recognizable text string from the web pages you are serving. For instance, you might decide that there is no situation in which a user should be served a page with social security numbers on it. Or credit card numbers, or anything with a pre-defined format.
[third click]
Also, customers have told us that, for some applications, they just want to so some basic filters against known attacks. Script kiddies, known worms, and so on. So we created these Attack Fileters which provide basic protection right out of the box. You can literally have this up and running in a few minutes.
[fourth click]
Another new feature is Cloaking. This hides your Web infrastructure so that hackers can’t tell what servers you are running. It strips out any identifying footprints or fingerprints, and also checks to make sure no server code leaks out onto web pages.
[fifth click]
we have best-in-class SSL Acceleration and key management
[sixth click]
We also built in basic firewall capabilities, so customers don’t have to rely on network firewalls for their DMZ’s
BUT the real core to TrafficShield is the Application Security, so let’s focus on that.
Transition: How do we actually know the difference between a good request and a bad request?
Random Attacks
Script Kiddies
Known Worms & Vulnerabilities
Requests for Restricted Object and File Types
Non-RFC-Compliant Traffic
Illegal HTTP format, method
Application Servers

20. TrafficShield™ Content Scrubbing
Sensitive Data
Social Security Numbers
Credit Card Numbers
Account Numbers
Patient Health ePHI
Phone Numbers
Any other identifiable text pattern
[first click]
The core functionality is the ability to tell good requests from bad ones. The jargon people use for this are things like cross-site scripting, cookie poisoning, and SQL injection, among others.
Because we sit at such a crucial point in the infrastructure, customers have asked us to combine some other functionality that it makes sense to so here…
[second click]
For instance,. We have just added Content Scrubbing, which gives you the ability to strip out any recognizable text string from the web pages you are serving. For instance, you might decide that there is no situation in which a user should be served a page with social security numbers on it. Or credit card numbers, or anything with a pre-defined format.
[third click]
Also, customers have told us that, for some applications, they just want to so some basic filters against known attacks. Script kiddies, known worms, and so on. So we created these Attack Fileters which provide basic protection right out of the box. You can literally have this up and running in a few minutes.
[fourth click]
Another new feature is Cloaking. This hides your Web infrastructure so that hackers can’t tell what servers you are running. It strips out any identifying footprints or fingerprints, and also checks to make sure no server code leaks out onto web pages.
[fifth click]
we have best-in-class SSL Acceleration and key management
[sixth click]
We also built in basic firewall capabilities, so customers don’t have to rely on network firewalls for their DMZ’s
BUT the real core to TrafficShield is the Application Security, so let’s focus on that.
Transition: How do we actually know the difference between a good request and a bad request?
Application Servers

21. TrafficShield™ Cloaking And Security Services
SSL
HTTP
[first click]
The core functionality is the ability to tell good requests from bad ones. The jargon people use for this are things like cross-site scripting, cookie poisoning, and SQL injection, among others.
Because we sit at such a crucial point in the infrastructure, customers have asked us to combine some other functionality that it makes sense to so here…
[second click]
For instance,. We have just added Content Scrubbing, which gives you the ability to strip out any recognizable text string from the web pages you are serving. For instance, you might decide that there is no situation in which a user should be served a page with social security numbers on it. Or credit card numbers, or anything with a pre-defined format.
[third click]
Also, customers have told us that, for some applications, they just want to so some basic filters against known attacks. Script kiddies, known worms, and so on. So we created these Attack Fileters which provide basic protection right out of the box. You can literally have this up and running in a few minutes.
[fourth click]
Another new feature is Cloaking. This hides your Web infrastructure so that hackers can’t tell what servers you are running. It strips out any identifying footprints or fingerprints, and also checks to make sure no server code leaks out onto web pages.
[fifth click]
we have best-in-class SSL Acceleration and key management
[sixth click]
We also built in basic firewall capabilities, so customers don’t have to rely on network firewalls for their DMZ’s
BUT the real core to TrafficShield is the Application Security, so let’s focus on that.
Transition: How do we actually know the difference between a good request and a bad request?
Application Servers
Security Services
SSL Accelerator
Key Management & Failover Handling
SSL Termination and Re-encryption
IP/Port filtering
Reverse proxy
Application Cloaking
OS and Web Server Fingerprinting
HTTP error messages
Application Error Messages
Leakage of server code

22. The Application Flow Model
Web Application
Application Flow Model
Application Flow
CHANGE
USER ID
Actions not known to be legal can now be blocked.
- wrong page order
- invalid parameter
- invalid value
- etc.
Take a simple web application like this one.
[click]
From each page there are a limited number of requests you can make. Starting on the login page, you can only get to the pages with links served on the page, or – more technically – to the objects requests by the parameters on the page. This is the ‘application flow’
We capture this information and store it on TrafficShield. We call it the Application Flow Model – it’s just a map of the application. We can now use this to enforce a security policy.
If a user tries to do anything that’s not part of that Application Flow Model, we can deny it, whether it’s an attempt to go from page A to page C without going through page B, or leaving page A as one user and arriving at page B as another user.
Transition to slide 8: (If customer is technical and wants to know how they will build the policy) So how do you build a policy?
Transition to slide 9: (standard) What does TrafficShield actually look like?

23. The Application Flow Model
The only way to provide total security in front of Web applications (the only way to replace embedded security code)
Stateful - Tracks which pages a user is coming from, and the specific permissions associated with that context.
A request which is perfectly legal within the context of one page might be inappropriate for a user on another page
Bidirectional - Looks at server responses to the client as well as client requests to the server.
Essential to verify that the user hasn’t attempted to tamper with the credentials sent to him in his response
Granular – Complete logical rendering of the transitions between every page, including every object, every parameter of each object, and every legal value within each object parameter.

24. Building a Security Policy: How Does It Work?
Significantly increases policy accuracy
Parameter value ranges, dynamic parameters
Trusted IP
Provides confidence that no legal traffic is blocked
LEARNING
Recommends
policy updates
based on traffic
CRAWLER
‘Maps the App’
HTML
JavaScript
In order to build a policy, TrafficShield provides three tools, which together we call the Hybrid Policy Generator.
[click]
The most important tool by far is the Crawler. This crawls the application to create the initial map (Application Flow Model), which can be up to 99% accurate. Of course, 99% accurate is not enough in the security world, so we provide two additional tools to “fine tune” the policy.
Once the initial policy is built, TrafficShield can be put into a non-blocking Learning mode. This allows you to see the traffic that isn’t part of the map, and decide whether or not is should be. For instance, you might run live traffic through TrafficShield and find an object or parameter that the crawler missed. The Learning engine will automatically recommend an update to the policy which will make that action and all subsequent actions like it legal. In this wasy you can “tune out” any potential false positives in a few days.
Finally, this policy is not a “black box” or set of arcane rule-sets. Our Visual Policy Auditing gives a graphical display of the entire policy – that is, a graphical display of the application map. This map allows security administrators to communicate effectively with application owners to understand exactly how a policy should be set.
Transition: So how is this product delivered?
Intuitive map of each application
Delegated approval support
Policy auditing at parameter level
VISUAL POLICY AUDITING
Granular control
80-99% Mapping of:
Accessible objects
Flows between objects
Request structure (GET/POST)
Parameter characteristics

25. Single Unit Deployment
Web Servers
TrafficShield
Firewall
LB Switch
Management Access
(browser)

26. Redundant Deployment TrafficShield Management Access (browser)
Web Servers
TrafficShield
Firewall
LB Switch
Active
Backup
Management Access
(browser)

27. Load Balanced Deployment
Web Servers
TrafficShield
Firewall
LB Switch
LB Switch
Management Access
(browser)

28. New Enterprise Hardware Platform
Manageability:
• LCD for Simplified
Management
• Hot-Swappable Power
and Cooling
• Redundant Power/Fans
Performance:
• Unique Hardware
Acceleration Support
• 4x Performance Increase
• Dual Processor
Secure:
Hardened Appliance
Secure O/S
Tested for Vulnerabilities
Avoids Configuration/ Compatibility Issues
TrafficShield™ 4100
Best in Class Security, Performance and Management

29. Summary Web Applications leave sensitive data exposed
TrafficShield provides comprehensive protection for Web Applications
Granular
Manageable
Flexible deployment options ensure low TCO