Deprecated: __autoload() is deprecated, use spl_autoload_register() instead in /home/silvanodaros1/public_html/wp-includes/compat.php on line 502

Deprecated: Function create_function() is deprecated in /home/silvanodaros1/public_html/wp-content/plugins/white-label-cms/includes/conditionals.php on line 39
Deploying WAF during the cold & flu season – JustADC

Deploying WAF during the cold & flu season

"An ounce of prevention is worth a pound of cure." -- Benjamin Franklin.

 

With cold and flu season around the corner, we’re inundated with measures to protect ourselves from getting sick – flu shots, better nutrition & exercise, avoiding contact with an infected person’s air space or surfaces they have touched, taking your temperature, going to the doctor, hand sanitizers, hand washing/hygiene techniques, immune system boosting vitamins, and home remedies. There’s no silver bullet, but with effort, you can reduce your chances of getting sick and the effects of the cold and flu using a combination of these preventative measures. Application security is similar – you have many tools, techniques and best practices available to improve your overall security health and help reduce your risk of inbound attacks against your applications.

 

This diagram illustrates a typical placement of various security measures within your cloud or on-premise environment. You can deploy your security measures as physical hardware or virtual instances, and your applications as virtual instances or micro-service containers.  You can also change the ordering of the security measures within your specific environment. Your security concerns remain the same regardless of your underlying deployment methods or the ordering of your security measures,

Each measure complements one another as they address different security concerns, but looking at your overall security strength, each slightly reduces your overall risk of attack. Moreover, like protecting yourself against the cold and flu, no single component is a guaranteed prevention for achieving 100 % confidence in your application security – therefore you should employ as many measures as possible… as soon as possible… and as effectively as possible.

 

Wash Your Hands – Improve Coding Hygiene

Like improving your hand washing hygiene, you should implement secure coding hygiene and best practices for your developers. Secure coding training and automation tools such as Static and Dynamic Application Security Testing (SAST & DAST) can help prevent common OWASP-top 10 style attacks like SQL injection and Cross Site Scripting (CSS). 

 

Use Hand Sanitizers – Layer 4 Protocol Protection

By sanitizing the TCP and UDP layers –  the lower layer protocols that transmit your data between clients and applications – you can protect your applications from connection failures. 

An example of a critical UDP-based protocol to your application security is the DNS system. Prior to initiating requests to your application servers, clients must initiate a DNS resolution to resolve your domain name to an IP address. As such, DNS is a common target of various UDP attacks – after all, bringing down name resolution will prevent you from even knowing where to send your requests. You can employ various mechanisms to protect against DNS attacks, such as DNSSec, cloud based DDoS mitigations, firewall, ADC, and Intrusion Detection and Prevention (IDS / IPS) mechanisms.

The lines are blurring between ADCs (like F5 BIG-IP LTM), firewalls (like F5 BIG-IP Advanced Firewall Manager AFM) and IDS/IPS systems as deployed by some vendors recently – each can help project against TCP and UDP day zero attacks, by monitoring typical connection behavior of your specific application and alarm / block traffic that deviates and doesn’t appear to fit the established normal behavior. For known attacks, such as low bandwidth Denial of Services (DoS) attacks and Slowloris, they use techniques to match known patterns against the malicious behaviors.

For high bandwidth DoS attacks  Distributed Denial of Service (DoS) attacks  you can also utilize F5 BIG-IP iSeries platforms that contain DDoS SYN Cookie hardware acceleration, provided you have an Internet link that can handle large scale DDoS attacks. For enormous attacks, you can subscribe to various cloud services that can handle many Terabytes per second of DDoS traffic, such as F5's Silverline cloud. These DDoS ‘cleansing’ services filter out the unwanted flood traffic and only send valid requests to your applications, preventing the DDoS from flooding your network or application services.

 

Boost your Immune System – Fraud & Malware Protection

Like taking immune system boosting vitamins and home remedies to prevent illness, if you have critical applications that are susceptible to fraud and malware attacks, you can implement fraud protection services. These include the F5 WebSafe and MobileSafe and Web Fraud Protection Services  and can safeguard against various forms of malicious activity including phishing attacks, Man-In-The-Middle (MitM), Man-In-The-Browser (MitB) and Trojan attacks. You can ensure that web injections, form hijacking, page modifications and transaction modification are minimized with these technologies.

 

Get the Flu-shot – Run-Time Application Self-Defence (RASP)

Run-time Application Security (RASP) offers a self defense mechanism for your applications – they act on attack traffic that has already entered your application system. They run on your application servers and have insight into application logic, configuration, data and event flows. Like a flu-shot, the RASP can alarm your system to block threats as they occur -- prior to impacting your overall system.

 

Take Your Temperature  – Deploy Security Information and Event Management (SIEM)

Like using a thermometer to take your temperature to monitor for fever, you can utilize a centralized event platform to monitor the vitals of your network and security devices. They do this by collecting, correlating, and analyzing security events generated by your network and security devices and alerting only on those that need the attention of your security experts.

 

Go to the Doctor – Third-Party Assessments

Like going to the doctor for tests to determine your vulnerability, utilizing third-party penetration testing tools and audits can assist in your security assessments to help address issues that prior techniques may not have caught. As with DAST, you can load the results of your assessments into your WAF to virtually patch your application against known attacks.

 

Avoid Contact – Web Application Firewalling

Like avoiding contact with infected persons, you can utilize the F5 BIG-IP Application Security Manager (ASM) web application firewall for alarming and blocking threats before they ever reach your application servers.

 

WAF Key Benefits

  • Mitigates OWASP top 10 and non-day zero attacks 
  • Mitigates day zero attacks with legitimate request learning
  • Detects and prevents:
    • Data Leakage
    • Malicious Web scraping and Bot traffic
    • Brute force login attacks
    • DoS and Phishing attacks

 

Positive Versus Negative Security

Within the F5 BIG-IP ASM, you have multiple layers of protection that you should be aware of that are not available in any other available measures discussed in this article. A negative policy blocks known bad HTTP requests from entering your applications and allows everything else; whereas a positive policy allows only known legitimate requests to enter and blocks everything else. You would typically start with a negative policy and slowly introduce a positive policy and additional enhanced WAF features into your application security, once you’re comfortable that you have a basic level of protection with a negative policy.

To get your Web Application Firewalling off the ground as soon as possible with minimal effort, you can initially deploy your WAF in negative security mode – this mode uses pattern matching against a black-list of known violations as defined by attack signatures. This protects against the OWASP top 10 attacks such as SQL injection and Cross Site Scripting. Although a negative policy is less secure than a positive policy, it requires much less work to manage than a positive policy.

Once you confirm that you have basic protection against the OWASP top 10, you can move towards a positive protection mode. With a positive model, you build a legitimate white-list of the various entities, such as HTTP headers, URLs, parameters, file types, and cookies that your application uses, based on the results of generating test traffic by your developers and actual users. Once you’ve established an exhaustive white list of entities, you can move your policy into blocking mode to enforce your items and block requests for any illegitimate entity that is not listed within your white-list. The end-result of investing in positive protection is an increased level of protection against day zero attacks by blocking illegitimate requests that are not known to your application.

Positive protection provides a higher level of security but is much more work to maintain than a negative model, especially for applications that change frequently. Additionally, the more granular you make your policy the more work that is required to manage the policy. For example, you can simply enforce the names of your form parameters and allow any values, or you can enforce data types, formats and ranges of values, such as with phone numbers, or entries within form drop-down lists.

 

A Prescription for Enhanced WAF Protection

In addition to negative and positive security, the F5 BIG-IP ASM offers additional enhanced features to protect your applications, such as data leakage prevention, bot detection, and brute force detection.

Here’s a prescription for phasing in the various F5 BIG-IP ASM features and functions into your application flow. Each phase should take at least one or two weeks to complete, depending on the complexity of your application. The time between phases also depends on your application team’s availability and comfort level with the accuracy of the policy of the current phase, but normally would be another couple of weeks.

 

Phase 1 – Basic Protection

During this phase you want to prevent false positives and build your confidence in your policy settings for your specific application. Here are the high-level items you want to consider for your first phase of deploying each application -- how to enable these on the BIG-IP ASM is out of scope of this article.

  • Negative policy protectioninclude the BIG-IP ASM default signature set as well as those related to your application, database and development environment, to circumvent against common OWASP top 10 attacks.
  • Data leakage protection Avoid data leakage by enabling F5’s DataGaurd feature to mask sensitive information your applications may be inadvertently exposing or that attackers maliciously expose, such as credit cards and social security numbers.
  • HTTP protocol enforcement and evasion technique protectionEnable HTTP protocol RFC compliance and evasion technique violations, such as directory traversal, to prevent additional data leakage and application discovery.
  • Session cookie hijacking prevention (default) – the BIG-IP ASM automatically protects all your application’s session cookies from tampering and hijacking by default.

 

Phase 2 – Medium Protection

During this second phase, you already have the comfort of knowing your applications are protected against OWASP top 10 attacks, data leakage and HTTP protocol violations, but you want to gradually provide more granular and positive policy protection against day zero, and CSRF attacks.

  • White-list file types, URIs, cookies, and parameters (ignoring values) you can either use the built-in automatic policy builder to trigger the ASM to learn your entities based on test traffic or manually add each entity yourself. Once learned, you can specify whether parameters are mandatory, sensitive or both. Mandatory parameters that are missing from requests will be blocked; the ASM will not log sensitive parameter values anywhere on the BIG-IP system. For this phase, you will configure the ASM to ignore parameters values to prevent false positives.
  • Cross Site Request Forgery (CSRF) protectionCSRF is a common attack where an attacker convinces a user to click a carefully crafted hyperlink, either from an email or web forum, pointing to an application that the user is already logged into, but that performs an unwanted action. A common example is transferring funds from a victim’s bank account to the attacker’s bank account. The BIG-IP ASM protects against this attack by adding a random CSRF token to each request, that an attacker wouldn’t be able to guess for inclusion in their crafted hyperlink.

 

Phase 3 – High Protection 

Now that you’re well on your way to protecting your application, you can introduce more granularity by enforcing parameter types and values, and enabling web scraping/bot detection, brute force login page protection and redirection protection.

  • Parameters data-types and values – Add a layer of protection to your parameters by specifying the data type and value ranges for each, and which negative signatures the ASM should match against for each parameter.
  • Web-scraping & bot detection – Prevent data leakage and application discovery by configuring the ASM to automatically detect and block hosts that are rapidly surfing your applications.
  • Brute force protection –  Protect your login pages by preventing brute force login attempts.
  • Redirection protection –  Prevent phishing attacks caused by your application not properly validating redirects by configuring only those redirects in your policy that the server should generate. All others will be blocked.

 

Phase 4 – Comprehensive Protection 

To achieve the most comprehensive ASM policy possible, enable the following features where needed.

  • Login page protection, navigation flow enforcementAdd logic to track individual user’s logins to your applications, and enforce a browsing sequence between the pages of your applications using navigation parameters.
  • DoS protection with transaction and latency detectionPrevent DoS attacks against your applications but enabling Transaction per Second (TPS) and latency based attack mitigation.
  • Integrate with DAST and third-party assessment tools for virtual patchingIn the event of a coding error by your developers, you can apply a virtual patch to your application without requiring an application code update by applying the results of your DAST or third-party assessment testing to your ASM policy and protect your application against the detected vulnerabilities.
  • Enforce geo-location and known malicious IPsYou can block users from a specific geographic location that you know with certainty that your users do not reside within. This can block attacks that originate from areas that you may have special knowledge about sources of attacks.

 

Exercise – Frequently Tune your WAF

Lifestyle improvements like regular exercise and better nutrition can reduce your risk of future illness. If you’ve filled the prescription outlined in the recommended phases in this article to completion – that’s great! Take a breath and enjoy the fruits of your labour… but you are not done.  Learn from other organization’s mistakes of filling a one-time prescription, checking the WAF box off on their security checklist and moving onto the next measure in the traffic flow.

During your initial deployment of WAF for your first few applications, you’ll get more familiar with the development life cycle and tools used by the development teams in your organization. As developers release new versions of their applications, you’ll want to update your policies to reflect the updates to application behavior. To assist with the tuning process, you can:

  • Create unique polices For dev, test, UAT, production and any other application environment used in your organization you can create unique policies, so that you can catch updates at every step of the development life cycle.
  • Tighten and loosen your policy’s thresholds Make these adjustments to the thresholds for accepting legitimate entities from test or real users at each step of the development cycle.
  • Import policy information from lower environments This will ensure that your production policy is as accurate as possible.

These three steps will provide the highest level of security while reducing risks of false positives in your environment.

 

Eat better – Educate your Enterprise about WAF

To help facilitate the use of WAF in your organization, you should take some time to schedule meetings with additional application teams to discuss the benefits of WAF and the phases involved in securely deploying applications. Work with your development teams to get an understanding of their needs and how you can help with WAF.

Remember -- don’t just turn your WAF on and leave it. Insert WAF into your Development life-cycle!

 

About the Author

Silvano Da Ros is an F5 ASM and APM certified Architect for JustADC, with over 15 years experience with various ADC vendors. When he's not designing and troubleshooting F5 environments, you can find him on the tennis court or spending time with family.

 

Please comment or ask any questions about this article.

Additionally, feel free to contact us to learn more about JustADC’s Managed WAF services to address your application security needs.

 


Notice: compact(): Undefined variable: limits in /home/silvanodaros1/public_html/wp-includes/class-wp-comment-query.php on line 860

Notice: compact(): Undefined variable: groupby in /home/silvanodaros1/public_html/wp-includes/class-wp-comment-query.php on line 860

Leave a Comment