I've been following Palo Alto as a networking company for a couple of years now. Their claim is that the days of the port-based firewall are dead and that their application-centric approach is a far better way to enforce your access controls. Take the HTTP protocol for example. HTTP typically runs as a service on port 80, but does that mean that everything running on port 80 is HTTP? As an attacker looking for a way to funnel data out of your organization, why not use the standard HTTP port to send data, since I know you leave it wide open in order for your employees to surf the web. There's nothing to say that I actually have to be running an HTTP server on the other end and there's nothing on my classic firewall to tell any differently. At first, I was admittedly a bit skeptical. I didn't think that you could really tell enough about different applications on the web to be able to separate them out like Palo Alto claims to. Fortunately, Palo Alto reached out to me and provided me with a brand new PA-200 in an attempt to change my mind.
When the PA-200 arrived, it came with everything that I would need to get it up and running. That includes the unit itself, a power supply, a D89 to RJ45 console cable, an ethernet cable, and some instructions and warranty information.
On the front of the unit is four ethernet ports for your devices, a management port, a USB port, a console port, and several status indicator LEDs.
By default, the appliance is configured with ethernet ports 1 and 2 paired as a WAN to LAN link as this is the configuration that the majority of the people who buy it will likely use it for. That said, by following the instructions to connect your computer up to the management port, you can quickly access the user interface that allows you to change this assignment.
This shows the ethernet 1 and 2 interfaces as both being a "virtual wire" and here we can see the virtual wire that connects the two.
From here, we can take a look at the "zones" and see that our two interfaces have been defined as an untrusted (ethernet 1) and trusted (ethernet 2) zone.
To think of this a different way, my cable modem WAN connection (ie. the Internet) goes in my "untrust" zone and my local network (ie. LAN) goes in my "trust" zone. Now all that's left is to set our policy and for ease of management to start with, I set it to allow everything out with a default deny all inbound.
With this configuration I had done enough to be up and running on the device and I immediately started to see data populate the dashboard on the top applications running on my network.
It's color coded based on risk level and the dashboard also provides me a similar view of Top High Risk Applications. Any of these boxes can be clicked on in order to provide additional data about the protocol, sources, destinations, countries, and more.
Now, let me say that while I'm running this on my home internet connection, this thing is a hoss and can do way more than I can throw at it. With their App-ID technology enabled you can throw 100 Mbps of throughput at it no problem. In addition to being an application firewall, it also does standard port-based firewalling, VPN, routing, switching, and so much more. It's so extremely versatile that this thing could easily be placed in a smaller branch office and replace multiple other devices on their network such as a firewall, router, and VPN concentrator. More functionality for less money...who wouldn't want that? In addition to these default capabilities, additional licensing can also be obtained to allow you to do URL filtering, malware detection, and more. Having just gotten this up and running, I'm still exploring the ins and outs of all of the functionality, but it's pretty exciting to have all of this capability in a box that is smaller than the cable modem my ISP provides me. More posts to come on this as I get deeper into the guts of running my new Palo Alto PA-200 !
This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project. My notes are below:
WAF Fallacies (at least in regards to OWASP ESAPI WAF)
- WAFs add attack surface
- WAFs can create culture problems
- WAFs can't fix business logic vulnerabilities
- WAFs are way too expensive
- WAFs complicate networks
Why fix in ESAPI WAF vs Fix in code?
- Changing in ESAPI WAF is just a text file
- Shorter gap between time discovered and WAF fix vs code fix
Advantages of WAF
- Performance - Only your rules are checked, plus state is already managed by the app server
- Capability - being closer to the app lets us do more
- Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time
Principle: Make common tasks easy, uncommon tasks possible
General virtual patching functionality is easy to understand
Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy
Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)
Can add "outbound" security as well
- Add anti-clickjacking header
- Set uniform content-type
- Add HttpOnly flag
- Add secure flag
- Detect outbound information
- Replace outbound information
Takes advantage of early failing to make rules as optimized as possible
Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):
- Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
- Unchecked Redirect
- Add HttpOnly
- Add anti-clickjacking header
- Privilege escalation
3 Different WAF Modes
Latency with all of the rules turned on is about 5%. With selected rules is closer to 0%. Basically an order of n magnitude where n is the number of rules enabled. Comes out to milliseconds.
This presentation was by Michael Coates, the AppSensor Project Lead. Michael works as a Senior Application Security Engineer at Aspect Security. AppSensor is a real time defense system with the goal being to protect an application by detecting who is bad and getting rid of them before they do bad things. My notes from this session are below:
- AppSensor Project
- Malicious Attackers
- Application Worms
Detecting Attacks the Right Way
- Detect INSIDE the application
- Understand business logic
- Minimal false positives
- Immediate response
- Automatic detection
- No manual work required
Detection Outside the Application (WAF)
- Application context not available
- No concept of access violations
- Custom application + Generic Solution != success
- Ex: Changing the account ID in /viewAccount?id=1002
Inside the Application is Best
- Understand application & business context
- Integration with authentication & user store
How Does AppSensor Protect the App?
- Take many requests for an attacker to find a vulnerability
- Takes fewer requests by AppSensor to determine that the user is malicious
AppSensor is Faster than Attacker
- User identified as malicious and blocked before a vulnerability is found
Categories of Detection
- Access Control
- Command Injection
- File IO
- User Trend
- System Trend
Attack Detection: Real vs Cyber World
- Why do bank robbers get caught?
- Why don't hackers get caught?
Let's Change Things - Applications Should...
- Detect attacks
- Understand normal use vs suspicious use
- Instantly identify attackers
- Shutdown attackers in real time
- Modify application accessibility for defense
Detecting Malicious Users
- Many malicious attacks are obvious and not "user error"
- POST when expecting GET
- Tampering with headers
- Submissions of XSS attack
Detecting Malicious Users
- Bypassing client side input validation
- Transaction using functionality not visible to user role
- Multiple access control violations
- Change of user agent midsession
- Double encoded data
- Leverages ESAPI!
- 3 lines to setup AppSensor
- 2 lines per AppSensor detection point
Setting up AppSensor
- Configure response action object (log logout, account lock)
- Create AppSensorIntrusionDetector with response action object
- Set ESAPI intrusion detector
Defining Response Policies
- ESAPI.properties file
- Threshold count
- Interval of events
- Response action
- Per exception type or aggregate
2 Lines to Use AppSensor
- Check for "maliciousness"
- Create new AppSensorException
Understanding the Intrusion Exception
new AppSensorIntrusion Exception(
- "User Message",
- "Direct object tampering with ..."
AppSensor vs Scanners
- Tools attempt 10,000s of generic attacks
- AppSensor stops automated scans nearly instantly
AppSensor vs Human Attackers
- Very difficult for attacker
- Requires advanced obfuscation for each attack
- Multiple probes == detection
Application Worms on the Rise
- Twitter Worm
- MySpace Samy WOrm
- Huge damages for site
- Bad PR
- Infected Users
- Leverage XSS and CSRF
Detecting/Preventing an Application Worm
- Can you find/fix all XSS?
- Pattern matching easily foiled
- Block the common factor!
- Worms use XSS and CSRF for propagation
- 1000% usage increase -> problem
- Our example: updateProfile, updateStatus, updateName
Case Study: Samy
- MySpace Application Worm
- XSS worm embedded in User Profile
- Exponential Growth of Samy's friends
Samy vs AppSensor
- AppSensor detects uptick in addFriend usage
- Compares against trended info
- Automatic response initiated
- Alert admin +200% add friend usage
- Alerts admin 2nd time +500% add friend usage
- Automatically shuts down add friend feature
- Worm contained
- Add friend temporarily disabled
- Site stays up
Benefits of Trend Monitoring
- Detection of
- Application worms
- Scripted attacks/probing
- CSRF attacks
- Alerting of excessive activity
- Selective feature shutdown for overall stability
AppSensor in Action
- Demo social networking app
- Defended with AppSensor trend monitoring
What's Under the Hood?
- REST communication between AppSensor & App
- Support Response Actions (warn user, logout user, disable user, etc)
- Drools - Rule Based System
- Support for complex rule sets - much more than just counting feature usage
- Evaluates objects in Drools memory
- XSS infects victim's "Status" with worm
- CSRF adds victim as friend of Charlie
Defend with AppSensor
- AppSensor Policy
- Notify admin if events > 5
- Disable service if events > 10
- AppSensor notices anomaly - alerts admin
- After 10 events AppSensor disables just that feature of the site
- Users protected, worm contained, site stays up
Trend Monitoring Benefits
- Auto detection of attacks
This presentation was by Alexander Meisel and is from a paper that was put together by the Germany OWASP chapter. He began by introducing the problem being online businesses having HTTP as their "weak spot". Then talked about the definition of the term "Web Application Firewall". It's not a network firewall and not only hardware. The targeted audience of the paper is technical decision makers, people responsible for operations and security, and application owners. Next he talked about some of the characteristics of web applicatons with regard to security. Prioritize web applications in regard to their importance (access to personal customer data, access to confidential company information, certifications). Some technical aspects include test and quality assurance, documentaiton, and vendor contracts.
Where do WAFs fit into the web application security field? WAFs are part of a solution. Create a table with wanted functionality (CSRF, session fixation, *-Injection). Do a rating/evaluation with "+" meaning it can be very well implemented using a WAF, "-" meaning it can not be implemented, "!" meaning depends on the WAF/application/requirement, and "=" meaning it can partly be implemented with a WAF.
Looks at the benefits and risks of WAFs. Good baseline security. Compliance. Just-in-time patching of problems. Additional benefits (depending on functionality) could be central reporting and error logging, SSL termination, URL encryption, etc.
Some risks involved in using WAFs are false positives, increased complexity, having yet another proxy, and potential side effects if the WAF terminates the application.
Protection against the OWASP Top 10. App vs WAF vs Policy. Three types of applications: web application in design phase, already productive app which can easily be changed, and productive app which cannot be modified or only with difficulty. Table of OWASP Top 10 in regards to work required with the 3 types of applications to fix the problem in the application itself, using a WAF, and using a policy.
Criteria for deciding whether or not to use WAFs. Company wide criteria includes the importance of the application for the success of the company, number of web applications, complexity, operational costs, and performance and scalability. Criteria with regard to the web application includes changeability of the application, documentation, maintenance contracts, and time required fixing bugs in third-party products. Consideration of financial aspects includes avoidance of financial damage via successful attacks and teh costs of using a WAF (license, update, project costs for eval and WAF introduction, volume of work required/personnel costs).
He started going pretty fast here since he was already running over on time. The gist was a bunch of best practices for introduction and operation of web application firewalls. He talked about technical requirements, job requirements, and an iterative procedure for implementation.
This presentation was mostly just an overview of what is in the paper and he didn't get into too much specifics. Go check out the paper at https://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls to get the details!
This presentation is by Jacob West in the Security Research Group and Taylor McKinsley in Product Marketing from Fortify software. I'd like to note that Fortify is a developer of a source code analysis tool and so this presentation may have a bias towards source code analysis tools.
56% of organizations fail PCI section 6. Poorly coded web applications leading to SQL injection vulnerabilities is one of hte top five reasons for a PCI audit failure. Section 6 is becoming a bigger problem: #9 in 2006 reason for failure, #2 in 2007.
PCI Section 6 has to do with guidelines to "Develop and maintain secure systems and applications". Section 6.6 reads "Ensure that all web-facing applications are protected against known attacks by either of the following methods: Having all custom application code reviwed for common vulnerabilities by an organization that specializes in web application secure" or by using a web application firewall. Further clarifications say that automated tools are acceptable, web application penetration testing is allowed, and vulnerability assessments can be performed by an internal team.
Comparing Apples, Oranges, and Watermelons
- Setup: Source code analysis (+2) is good because it works on existing hardware, but must live where your source code lives. Penetration testing (+3) is good because you only need one to assess everything and works on existing hardware, but needs to talk to a running program. Application firewall (+1)is good because it lives on the network, but you must model program behavior.
- Optimization: Source code analysis (+2) is good because you can specify generic antipatterns in code, but you must understand vulnerability in detail. Penetration testing (+2) is good because tests are attacks, but you must successfully attack your application. Application firewalls (+1) are good because they share configuration across programs, but must differentiate good from bad.
- Performance: Source code analysis (+3) is good because it simulates all application states and is non-production, but scales with build time and not the number of tests. Penetration testing (+2) is good because you get incremental results and is non-production, but you must exercise each application state. Application firewall (+1) is good because it's a stand-alone device and scales with $$$, but impacts production performance and scales with $$$.
- Human resources: Source code analysis (+1) is good because it enables security in development and reports a root cause, but makes auditors better and does not replace them. Penetration testing (+2) is good because it is highly automatable, but reports symptoms and not the root cause. Application firewall (+2) is good because once it's configured it functions largely unattended, but requires extensive and ongoing configuration.
- Security know-how: Source code analysis (+3) is good because it gives code-level details to an auditor, but you must understand security-relevant behavior of APIs. Penetration testing (+1) is good because it automates hacks, but a hacker is required to measure success and optimize. Application firewall (+2) is good because it identifies common attacks out of the box and is a community effort, but a hacker is required to measure success and customize.
- Development expertise: Source code analysis (+1) is good because it focuses attention on relevant code, but you must understand code-level program behavior. Penetration testing (+2) is good because basic attacks ignore internals, but advanced attacks require internal knowledge. Application firewalls (+2) are good because they live on the network, but you must understand the program to tell good from bad.
- False positives: Source code analysis (+1) is good because it gives auditors details to verify issues, but reports impossible application states. Penetration testing (+2) is good because results come with reproduction steps, but it is difficult to oracle some bugs. Application firewalls (+1) are good because it is attacks instead of vulnerabilities, but there is an evolving definition of valid behavior.
- False negatives: Source code analysis (+3) is good because it simulates all program states and models the full program, but it must be told what to look for. Penetration testing (+1) is good because it is good at finding what hackers find, but is difficult to oracle some bugs and has missed coverage. Application firewalls (+1) are good because it uses attacks instead of vulnerabilities, but there is an evolving attack landscape.
- Technology support: Source code analysis (+2) is good because parsing is separable from the analysis and is interface-neutral, but it must adapt to new program paradigms. Penetration testing (+2) is good because it is independent from program paradigms, but is tied to protocols and is limited to network interfaces. Application firewalls (+2) are good because they are independent from program paradigms, but are tied to protocols and are limited to network interfaces.
Working Towards a Solution
- Assessment: Proving the problem or meeting the regulatory requirement. Recurring cost that does not "fix" anything
- Remediation: Fixing security issues found during assessments. Lowering business risk at a single point in time.
- Prevention: Get security right hte first time. Minimizing business risk systematically.
Do your own comparison and fill out the scorecard yourself (presenters ratings are noted in parentheses above).
Taylor did interviews with three companies to get their experiences deploying each (source code analysis, penetration testing, and application firewall) and had them evaluate based on the nine criteria both before and after buying. Not going to list each company's results in the blog, but it was just a basic table with each criteria and a number rating for both before purchase and after deployment. To sum it up, Source Code Analysis was a 14 rating before purchase and a 17 rating after deployment. Penetration testing was a 21 rating before purchase and a 21 rating after deployment. Application firewalls were a 21 rating before purchase and a 16 rating after deployment. It seems like the first organization had a large amount of developers and that factored into their decision to purchase a source code analysis tool. The second organization had a far fewer number of developers and was more of an IT shop and chose the penetration testing tool. The last organization was a smaller shop in general (still fairly large) and went with the WAF because they wanted something they could just put in place and manage.
Analysis: All three solutions required more effort than expected. All three solutions produce reasonably accurate results. Varying levels of expertise needed.
How do you demonstrate that your application is protected against known attacks?
- Verification that the application was analyzed
- A report showing no critical security issues identified
- Document showing how the tool fits into your architecture
How do you show that the user is appropriately trained?
- Document explaining prior experience or an informal interview
How do you show that you have configured the tool appropriately?
- Document explaining how the tool was configured and what new rules had to be added.
Summary: PCI section 6 is evolving to become increasingly precise. Compare technologies in your environment along nine criteria. Demonstrating compliance is an art, not a science.
I went to a Lunch n Learn last week sponsored by PaloAlto Networks and Fishnet Security talking about what PaloAlto calls the "next generation firewalls". PaloAlto boasts having Nir Zuk, principal engineer at Check Point and one of the developers of stateful inspection technology, as it's founder and CTO. Their product, the PA-4000, Series Firewall, takes an application centric approach to traffic classification and they claim that this helps it to more accurately identify both traditional and emerging applications. This enables it to facilitate true application access control and broad threat prevention. They claim that it is:
- The only firewall to classify traffic based on the accurate identification of the application, not just port/protocol information.
- The only firewall to identify, control and inspect SSL encrypted traffic and applications.
- The only firewall to provide graphical visualization of applications on the network with detailed user, group, and network-level categorization by sessions, bytes, ports, threats and time.
- The only firewall with real-time (line-rate, low latency) protection against viruses, spyware and application vulnerabilities based on a stream-based threat prevention engine.
- The only firewall with line-rate, low latency performance for all services, even under load.
- The only firewall to offer a true in-line transparent deployment option for seamless integration into an existing network infrastructure.
While the presentation itself tended to focus more on analyzing internal user's connections outbound toward the internet and it seems to do that fairly well, it didn't cover external users connecting inbound to web applications and things like that so I started asking questions about the firewall's ability to act as a WAF (Web Application Firewall). I was told that it will do some things like inspection for XSS and SQL Injection, it does not function as a true WAF. I wasn't even expecting that much so kudos to them.
All-in-all, I tend to believe the hype that this is the next generation of firewalls and while PaloAlto is the first player in the field, I'm sure others will soon follow. The firewall is one of the oldest network security devices out there and PaloAlto has definitely put forth a product that changes the way people will look at them. We think about protecting our networks on an application level and not on a port level so why should our firewalls do things any differently? That said, with this being such a new technology, I'm skeptical of how it works in the real world and am quite certain that it won't be long before hackers find creative ways in and users find even more creative ways out.