Post to Twitter
A new whitepaper describing the XML firewall features available in NetScaler version 9.x is available here.
It includes a concise summary of the feature capabilities and the types of applications that the Application firewall can secure. Security is a core component of the Application Delivery Controller (ADC) platform. For a broad overview of the security related features available in the NetScaler, get Citrix NetScaler - A Comprehensive Application Security Solution.
Ever got frustrated with how long it takes to email a large report or presentation after incorporating your manager's feedback? Or found yourself in a plane wishing the email downloaded faster when the flight attendant asks you to turn off your 3G-equipped laptop? Or wished for a solution that could deliver email 50 times faster?
Did you know our WAN optimization solution, Citrix Branch Repeater, delivers superior user experience and application performance not only for branch office users but also for remote and teleworkers?
No one feels the need for speed more than a remote user or a teleworker with a low-bandwidth or a high- latency network connection. These users typically use an SSL VPN, such as Citrix Access Gateway, to connect to their corporate network and access email, intranet portals, other applications and data. When your IT augments secure remote access (Access Gateway) infrastructure with Branch Repeater, you can benefit from both secure and accelerated remote access.
Well, now we have two reports that demonstrate ways to use Branch Repeater to augment your Access Gateway infrastructure and the resulting benefits of accelerating secure remote access.
You can download the Turbocharge Access Gateway Performance Report - CTX121034 from the Citrix Knowledge Center. The report explores the benefits of using Access Gateway and Repeater plug-ins for Citrix Receiver together:
• 50x faster Microsoft Outlook and Exchange (MAPI) workflows
• 50x faster Microsoft SharePoint (HTTP) workflows
• 30x faster Windows File Shares (CIFS) workflows
I think you will want to try out the benefits of turbocharged remote access. Check out the Turbocharge Access Gateway Deployment Guide and Reference Architecture - CTX121035 if you want to conduct a POC (proof of concept) or a demo to convince your IT or other decision makers. You will be your end-users hero for providing them with an accelerated yet secure remote access.
Securing Web Applications with an Application Firewall
I have been working with Application Firewalls for quite a few years - many times to protect web applications published in languages and character sets that I didn't understand. Frequently, I have seen these Application Firewall deployment projects get bogged down in pursuit of the perfect policy set.
I have also seen many situations in which this process and application changes actually break these applications.
The NetScaler Application Firewall deployment can also be subject to these issues since the appliance provides extensive application firewall features. Even with the learning capabilities, creating the ideal set of security policies for any application can be a trial and error process that can take significant time.
In this blog, I would like to share an implementation methodology that shortens the deployment, and helps avoid breaking the applications to be protected. Experience has shown that approaching the configuration of the Application Firewall in stages is the key to timely success. This methodology is effective for all types of applications and their needs.
To alleviate the time and risk of varying degrees of policy complexity, break the task into stages. That is, separate the policy configuration into groups of ascending risk. While some may raise the point that a simplified protection policy set is not complete, it must be remembered that protection stages will build upon each other, and will be better than allowing unfiltered access while all policies are in learning or logging/warning mode.
The benefit of staging is that a basic set of policies are made operational. Then, the following stages will consist of conducting a repeatable process of "policy tightening" procedures as required by the application.
Stage I
When configuring the NetScaler Application firewall policies, start with some of the basic protections. Activating the simple, generic policies almost never produce false positives. These typically include: 
- Protect against Cross Site Scripting (XSS) attacks
- Protect against SQL Injection attacks
- Protect against Buffer Overflow attacks
- Prevent Credit Card Leakage
- Prevent access to system files
- Alter the contents of the server headers
Activating these policies will typically not break applications. As such, a small user community - with etc/hosts overrides - can be used to validate the configuration over a fairly brief validation period.
More importantly, this is a great start. These policies create security effectiveness that can typically be rated as a level seven on scale of zero though nine (you can never get to a perfect "10" in security).
Stage II
The next stage will include applying policies that require more application validation to determine the application specific relaxation adjustments ("policy overrides").
But first, don't forget to ask yourself if this application actually requires tightened policies.
If so, Stage II protections should be sequenced - Cookie Tampering prevention should be blocked first. Then, move on to blocking tampering with the values of parameter and/or hidden form fields.
Start with cookie poisoning prevention ("Cookie Consistency"). It will be likely require the least number of relaxations. This will build on the Stage I successes most rapidly.
To do this, use the learning process to identify the cookies that are legitimately altered between the response and request process. Minimally, relaxations will be required for cookies that are set and modified by third party monitoring services. Again, because of the staging, this learning can happen while the basic policies are in place and actively applying their protection mechanisms.
If further tightening is required, focus on creating policies that prevent users from tampering with the values of parameter and hidden form fields. This is achieved by activating "Field Consistency" learning in the NetScaler application firewall. Depending on the architecture of the application or a frequent use of client side scripting, these policies carry a higher risk of blocking legitimate requests. These policies thus require a more extensive learning period and associated relaxation overrides.
It should also be noted that these Stage II policies and their relaxations do have a tendency to be susceptible to producing false positives as applications change, and should be re-evaluated in conjunction with major application changes.
Stage III and Beyond
If the application is contains super sensitive information, and undergoes frequent changes, further security configuration may be required.
Stage III typically involves enforcing field formats and enforcing user navigation paths. Adding restrictions to field input types, such as date formats, and more, will require further time for learning these application attributes. Be aware that these policies will also be more likely to be sensitive to application changes.
Enabling the "Start URL" facility allows users to access only the specifically stated URL types. Due to the flexibility inherent in application architectures, however, these restrictions may require modification to include additional request types present in a particular application.
Lastly, carefully consider activating "URL Closure" to control 
the flow of access by users. Enforcement of this policy set disallows users from navigating to locations not previously offered by an application response. These policies may require significant application validation if client side scripts modify URLs, or if FLASH objects contain links.
The above policies tend to bend the needle towards the nine level and will be more likely to cause false positives during policy refinement or when the application changes. Leaving these to Stage III, however, allows continued protection afforded by the policies of Level I and Level II during the refinement, however.
Summary
Personally, when I plan my application firewall deployments, I always attack 
the assignment in the phases outlined above. I focus on the quick return policies first. Then I take time to consider if the sensitivities of the specific application even warrant the extra effort of going all the way to Stage III. This last question can produce some interesting answers that pit my application security ideals against the practicalities driven by the depth of my current to-do list.
And then, of course, this staged approach may be completely ignored in situations in which a specific application just suffered from an attack through a specific Level III vulnerability. Such situations may warrant overriding the staged approach and focusing on addressing the impacted vulnerability immediately.
Also, don't forget to sign on to MyCitrix and download the Application Hacking Kit and actually try some of the most common application attacks on the BadStore application!
Integrating IWSVA 3.1 with Citrix NetScaler
Trend Micro InterScan Web Security Virtual Appliance 3.1 (IWSVA 3.1) is both a horizontally scalable (increasing capacity through additional servers) and vertically scalable (increasing capacity through CPU / memory or disk improvements) product and thus has clear options for increasing capacity and lowering latency.
However, IWSVA 3.1 does not offer built-in load balancing or high availability functionality in the standalone product. Customers desiring this functionality in the standalone IWSVA 3.1 solution must incorporate a third-party product to meet these needs.
The Citrix NetScaler is a powerful solution that matches the performance capabilities of the IWSVA 3.1 application while providing the key business continuity and load distribution functionality that enterprise environments require. Here are some recommended configurations when using IWSVA 3.1 with Citrix NetScaler:
- Citrix NetScaler placed in Transparent mode. This configuration does not require any endpoint browser modifications. This simplifies deployments.
- Trend Micro IWSVA 3.1 in Forward Proxy Mode. Although Citrix NetScaler in transparent mode provides endpoint transparency, you must still place IWSVA 3.1 in forward proxy mode for this functionality to work. This means that all upstream devices will see the MAC and IP addresses of the scanning IWSVA 3.1, not those of the endpoint. This may affect some gateway firewall rules or other applications. Citrix requires an identifying path to distribute load and so cannot aggregate traffic across multiple IWSVA 3.1s while the IWSVA 3.1 cluster is in Forward Proxy mode.
- Citrix NetScaler using "Source IP" persistence. Persistence takes precedence over a configured Load Balancing policy. This ensures that specific endpoints pass through to the same IWSVA when state information is available.
- Citrix NetScaler using the "Least Connections with LRTM" load balancing algorithm. If your environment does not require specific state continuity (in other words, it is acceptable to allow endpoints to pass through any available IWSVA 3.1 for scanning), this algorithm monitors the current number of connections on all IWSVA instances and forwards the incoming requests to the IWSVA with the fewest busy connections.
Its powerful AppExpert!