F5 Networks’ ASM: Secure Your Applications, Don’t Give Away Your Kingdom

It occurred to me while I was writing another blog that we need to talk about Web Application Firewalls (WAF). We think everyone should use one. Your current network and security infrastructure is the castle and drawbridge, whereas WAF is your portcullis. Not securing your applications is like giving away the keys to your kingdom.

What is a WAF?

WAFs are the first and last line of defense for your application. A WAF takes over at layer 4 of the Open Systems Interconnection (OSI) model, moves up to layer 7, and looks at the request, response, and payload. It validates data and the package it’s carried in, and its authenticity. In essence, a WAF applies a set of security rules to all aspects of an HTTP conversation.

The difference from your next-generation firewalls (NGFW) and IDS/IPS units, which only inspect packet-by-packet, is that a WAF digs into HTTP content and conversations, and validates the content request, response, and payload against white and black lists. Using predefined signatures or behavioral baselines, the WAF takes appropriate countermeasures based on configured policy elements. WAFs also include enhanced logging, alerting, connection intermediation, and even content manipulation to mitigate the impacts of attacks, mislead attackers, or inject content designed to raise confidence levels for WAF detection mechanisms.

A WAF validates traffic and payloads by learning the way the application should work, prevents bad input or manipulations, and prevents dangerous query/responses. A WAF maintains HTTP RFC compliance on all aspects of the session, and enforces session rules and session flows. It is a multifaceted tool.

F5 Networks Application Security Manager (ASM), in my opinion, is the right tool for the job. It is a tool that complements the F5 Global Traffic Manager (GTM) and Local Traffic Manager (LTM) devices you already use. To illustrate this, let us look at the traffic flow.

First, the GTM picks up the DNS request. Utilizing GTM, you can create a high-speed query frontend with DNS Express and can secure that zone with DNSSEC. GTM also evaluates your DNS request and traffic-shapes your response based on a host of criteria and settings, sending your session on to the network.

Sure, you have a firewall at your internet edge. It might even be next-gen, performs packet inspection, and has some signatures to eliminate some bad traffic. The same might also be true of your IPS/IDS, but these are packet-by-packet inspections and not the whole HTTP conversation (for the most part) and bad traffic gets by.

Here is where the F5 picks up and starts defending. LTM gets the traffic first and blocks malicious IPs, sorts out countries you may or may not want, defends against DDoS, and mitigates ciphers that are too weak or broken, all while restricting IP/port/landing page. LTM also traffic shapes it handoff to the next level, ASM.

ASM starts slow and builds in levels based on policy. It receives that traffic and checks if it matches the defined site. Then it checks to see if it is a new session. From there, it starts checking everything. It checks against signatures, RFC compliance, session-tracking info, methods, request timing, number of requests, header information, etc. And this is only the initial request. We haven’t even gotten to response!

ASM comes with quick-start policy templates for a ton of popular application templates like Exchange, Sharepoint, PeopleSoft, SAP, etc. If one of those doesn’t fit your build, ASM ships with an auto-policy builder. Fire this up and you turn your ASM device into Sherlock Holmes. It watches traffic pass through and automatically starts writing its own suggestions. When those suggestions get enough hits, ASM makes them into policy. The longer it runs, the better the policy.

If you change the application or add to it, it automatically picks that up and starts the building piece again. You can even build policy without affecting users. By keeping it out of blocking mode, you can mature the policy and reduce the likelihood that false alarms will create negative impact for users.

The ASM comes with other cool features, too, such as preventing forceful browsing, where attackers try to gain access to pages not part of the site that might have admin access. You can keep users from bookmarking deep into the app and redirect them to login pages you defined first to define flow. This keeps the application more secure and enables the organization to track sessions to support security, problem resolution, and compliance use-cases.

With this information, you can restrict application access to secondary login pages or other admin-related content by enforcing application flows and protect against webscraping. Brute force protection will even keep those login pages safe by adding a layer of protection including limiting login attempts, identifying automated attacks and more for these critical security entry points for the application.

DataGuard is an awesome feature as well. It protects sensitive fields like credit card numbers, Social Security numbers, and other administrator-defined sensitive data from passing through clear text. Instead, it utilizes masking to overwrite these values in responses with ‘****’. ASM will also mask these in the logs so you don’t have to worry about admins having access to that info as well.

There are so many other features, including signatures and security responses for common web application security threats such as cross-site request forgery (CSRF), cross-site scripting (XSS), clickjacking, cookie manipulation, etc. Any of these topics, as well as the mechanisms ASM utilizes to protect against them, would be worthy of their own blog post.  

I hope this blog has sparked a little more interest in your traffic and maybe even a hard look into the available security measures you can take. If you are already a Guidepoint Security customer, reach out to your representative to learn more. If you are not a customer and would like to learn more, please feel free to reach out to us. We have several ASM certified engineers to answer your questions. For more information, email info@guidepointsecurity.com.

About GuidePoint Security
GuidePoint Security LLC provides innovative and valuable cyber security solutions and expertise that enable organizations to successfully achieve their mission. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification is with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.

Does RASP Spell the Death of WAF?

RASP, or Runtime Application Self Protection, has been around since at least 2012 as coined by Gartner in this article. The technology essentially seeks to move traditional inline protections such as those provided by a web application firewall (WAF) closer to the application. In addition, RASP provides additional context to make more intelligent decisions about application attacks. This is not unique to web application attacks, as RASP can function for any instrumented application. Depending on who one talks to, RASP is either complementary to or a direct replacement for WAF.

As the marketing around these technologies tends to be a bit confusing, it is important to clarify a few things before we get started with a comparison of the two. There are many ways that WAF can be deployed: either traditionally inline in reverse proxy or transparent bridge mode, passively decrypting out of band, as an embedded on-host solution, and even via hybrid architectures such as cloud-based CDN WAF. Other techniques include a distributed WAF or virtual WAF hosted in a cloud environment. Comparably, RASP products are not all architected in the same manner either. The primary difference between RASP and a traditional WAF is the added context, as the analysis engine is driven by instrumentation, not observed traffic. As a technology, RASP has not matured to the point where WAF is today. Nor is RASP supported by such standards as WAFEC. So much of this is very opaque to potential RASP consumers.

The Argument for WAF

When comparing RASP to WAF, be sure to include all WAF or RASP deployment scenarios in the assessment. In some cases RASP is installed as an agent, or possibly exposed as a SDK that developers must make use of when coding their projects. In some instances, mitigation occurs by throwing exceptions and allowing the application’s exception-handling mechanisms to manage the issue. In other cases, inputs and outputs are scrubbed before they can do too much damage. In early versions, RASP was only protecting against legacy attacks such as XSS and SQLi, much the same as a WAF would. In fact, some of these products still function the same way today. When looking at RASP vendors, make sure they are not simply moving WAF logic inwards inside the runtime environment. Compliance frameworks such as PCI DSS do not recognize RASP as an acceptable application security control and attempts to replace WAF with RASP in 2016 may result in backwards momentum for compliance objectives, regardless of actual security impacts.

RASP brings to the table a very compelling argument; that the protection layer occurs as close to execution of code as possible, inside runtime environments such as .NET or Java JVM, and that it is required to install an agent on the server. RASP proponents stipulate that this makes them better suited to stop attacks that are occurring. But that also means these agent-based protections are not useful for applications based on PHP, Ruby, Python, or other languages that do not utilize a runtime environment. Many RASP technologies require that all or at least some of the functionality requires custom development work if you want to utilize the full benefits of their technology. This means custom development is usually required for all the capabilities that the agent alone will not provide.

However, RASP or WAF are, at best, compensating controls. I’m not comfortable with excessive development time spent on compensating controls when that time could be better utilized simply fixing the application vulnerabilities. This is especially important, considering that you may be locked into a code version that brings with it additional RASP licensing costs. This also increases the attack surface, added application complexity and increases overhead on the application server. By focusing on an external component such as a WAF, this creates a philosophical separation of control that allows for a more layered, yet centrally managed control, as opposed to an integrated approach that has multiple management points, scalability concerns, and a potential for human error to impact the consistency of controls. Additionally, WAF products are generally more configurable, but this also speaks to the maturity of the product space as these capabilities have evolved over time due to customer feature enhancements.

RASP also does not provide the same benefits a WAF brings for virtually patching application architectures. When the next TLS bug gets announced with a trendy new name, you will want the protection of a robust reverse proxy that can mitigate that issue in one place until the backend servers can be patched – RASP will not help there. It is also a very dangerous precedent to set that developers no longer need to write secure code, as you will be virtually patching all of their code with an agent inside the runtime environment or by utilizing this new set of SDKs required by the RASP vendor.

The Argument for RASP

On the other hand, RASP is very good at providing visibility into what a request or database response looks like to the application. WAF is usually several layers removed from the application where the request is destined, and after normalization the application may see a very different version of that same request. The WAF will never see the database response coming back to the application, only the http response that is being delivered to the end user. The WAF will never be able to understand data flows inside the application, unless that application is making additional web requests through the WAF to another application. The WAF has no understanding of how the application actually works. Finally, the WAF has no visibility into unhandled exceptions. This is where RASP starts making a lot more sense.

RASP technologies do not suffer from the same issues with false positives or tuning as they typically identify malicious activities that are occurring in real time. The WAF will see a user input the name “O’Malley” in a contact form and flag the blacklisted ‘ character, while RASP never needs to be tuned to ignore that in the last name variable because it did not result in an actual attack. There was no SQL injection attack, and the RASP will not flood the analyst with false positives that must be reduced. WAF typically has very little context other than what is observed from the actual requests passing through it. WAF has to be heavily tuned to understand what is and what is not acceptable. RASP on the other hand, has full visibility and context for what the application is processing, and can simply focus on what is actually impactful.

RASP is also largely protocol agnostic, as it does not rely on network traffic. It is purely driven by instrumentation and a set of rules that governs what an attack looks like from the standpoint of abuse of library calls, or queries and responses with the database. Inside an application, data flows and functions work largely the same regardless of what network protocols data is sent over. That means, in many instances, RASP technology can be extended outside the traditional web application stack that WAF protects to include AJAX, SQL, SOAP and more.

The other area that makes RASP very interesting is that WAF innovation has largely stalled. WAF vendors are not creating many new detection techniques or mitigation mechanisms, but are instead focused on keeping pace with changing architectures and cloud deployments. This is due to the fact that the WAF product space is relatively mature, but is very dependent on the application deployment architecture to function properly. In contrast, RASP is newer and more focused on integrating with server operating systems and application frameworks and languages. Many of the RASP vendors vying for market dominance are being much more forward thinking in their approach as they seek to differentiate themselves as the market leader.


My contention is that the marketing around RASP is very short-sighted as the vendors know most organizations have a limited security budget and they’d rather you buy their RASP product then continue renewing your WAF maintenance. My personal opinion is that RASP offers a very complementary feature set for traditional WAF deployments. The best of both worlds is to deploy both. But, if you can only afford one, utilize the points made above and decide what makes the most sense for your organization.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.


Top 10 Web Application Firewall Best Practices

Basic CMYKThe headlines are constantly bombarding us with the latest breaches like Ashley Madison, OPM, LastPass, and many others. According to this year’s Verizon Data Breach Investigation Report, there were over 79,000 security incidents in 2014. For the first time ever, the report names organized crime as the most prevalent threat actor for web application attacks. These attacks resulted in the 2nd most common attack category after crimeware.

In the next part of this article we will discuss the Top 10 Web Application Firewall (WAF) Best Practices. These methods are designed to assist organizations in understanding how to maximize the value from investments in web application firewalls and how GuidePoint Security is helping organizations to realize these benefits.

Top 10 WAF Best Practices

  1. Reasonable Expectations for WAF

Organizations should have reasonable expectations as to what attacks WAFs are effective at mitigating. Attacks such as Reflected Cross-Site Scripting (XSS) and SQL injection are trivial for most WAFs to detect. More abstract attacks such as abuse of business logic within an application are harder to detect using default policies and require in-depth understanding of the application in order to create policies to detect. 

  1. Deployment Architecture

There are multiple ways to deploy a WAF. In the cloud, reverse proxy, transparent bridge, sniffing, and on-host embedded deployments are all supported by many of the major WAF vendors. It is important to understand the trade-offs for the various deployment models.

  1. Failure Modes

There may be instances where the WAF fails, but how it fails is as important to understand as preventing the failure in the first place. If and when the WAF fails, what happens? Does it fail open and continue to allow traffic to the web server or does it become a failure point impacting availability? There is no right or wrong answer here, as the organization must understand the risks associated with an unprotected application remaining up versus an interruption of service.

  1. Application Profiling

WAF is not one size fits all. In other words, a single protection profile is probably not sufficient to protect all of an organization’s applications. Applications should be grouped into similar codebases for profiling, and policies should be constructed on an application-by-application basis.

  1. Security Models

Web Application Firewalls use the concept of positive and negative security models. The easiest way to explain this concept is to think of a positive model as a whitelist of allowed requests or responses and a negative model being the blacklist of disallowed values. A WAF can typically be configured with one or the other, or both, but frequently only negative security models are utilized, as they are far easier to implement. The best practice is to use both models when possible, or Positive models only if the WAF does not support both.

  1. Policy Tuning

Policies need to be tuned on a constant basis, and the violations and logged events should be driving this activity. This tuning activity is important to not only prevent detected attacks and upgrade a suspicious event to a blocked event, but also to reduce the noise generated by false positives.

  1. Team Integration

The team that owns your WAF may differ from organization to organization, but especially for Application Delivery Controller (ADC) based WAFs, they are commonly owned and managed by the Network team along with other load balancer technologies. It is important that Network, Security, and Application subject matter experts collaborate on WAF configurations in order to ensure that business, operational, and security requirements are met with minimal impact to the business or to customers. 

  1. Vulnerability Scanning

Vulnerability scanning for applications is an important activity that many WAFs support through automated policy creation based on scan outputs. It is important to make the distinction that scanning through the WAF tests the WAF, while scanning behind the WAF more accurately tests the application. A separate scan through the WAF should be conducted for any WAF tuning activities.

  1. User Training

Any security technology is only as useful as the capabilities of the team managing it. That is why it is so important to have the WAF managing team trained on application security best practices, web attacks, and incident response, as well as the specifics of the WAF technology they have deployed.

  1. Other Use Cases

Virtual patching, which the Open Web Application Security Project (OWASP) defines as “A security policy enforcement layer which prevents the exploitation of a known vulnerability” is the most commonly thought of use case for deployment of a WAF, with the possible exception of Compliance drivers such as PCI DSS. Other use cases that organizations should be considering include:

  • Logging – WAFs commonly employ more robust logging than what may be configured on web servers including full headers, body, and response codes.
  • Content Rewriting – This is an excellent security benefit supporting data leak prevention and cookie anti-tampering measure. However, it may also support business objectives such as use of stream policies to change content returned to a web visitor based on geography, site requested, site redirects, or other required scenarios.
  • SSL Termination/Offload – Most WAFs have the ability to terminate and offload SSL activities, which may reduce load on web servers, but also allows an organization to support different encryption options at the perimeter than what is negotiated by the actual web server.
  • Application Metrics – Since the WAF inspects all of the traffic destined for web applications, it can also provide substantial benefits for the business as well as security for identifying trends, usage statistics, geographic user sources, and other data useful for identifying the success of marketing campaigns or identification of key demographic data.
  • Application Understanding – It is common for organizations to experience turnover or shifting responsibilities. As such, it is not unusual that disparate teams need to understand how applications function but do not have access to the subject matter experts to convey this information. WAFs provide this key capability to help security and the business take a look under the hood and understand how applications actually work.

GuidePoint Security Web Application Firewall Health Check

 With these best practices as driving principles, GuidePoint Security has developed a Health Check offering for Web Application Firewalls. The Web Application Firewall (WAF) Health Check service helps our clients optimize their WAF environment to meet a set of constantly growing security, operational, and compliance needs.   This service examines their needs, evaluates their current WAF environment, and makes a series of recommendations to get the most from their WAF solution, including the use of application specific profile and policy assessment and custom requirements gap analysis.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: www.guidepointsecurity.com.