Aaron Rose is a Cyber Security Evangelist, Security Architect & Member of the Office of the CTO at Check Point Software Technologies.  A subject matter expert in cloud, Internet of Things, and application security; Aaron has focused his career on securing organizations & their resources beyond the perimeter of the traditional network firewall.

An avid international traveler, Aaron welcomed the opportunity to spend three months in Tel Aviv, Israel training with Check Point’s research and development teams at the company’s global headquarters.

In this outstanding thought leadership interview, Aaron Rose provides insights into web application security and so much more. Harness proven strategies, understand challenges, and cultivate cost-consciousness in the process. Discover premium cyber security knowledge and know-how. 

Tell us about what you’re seeing in terms of threats to cloud computing and web applications?

In the past 10 years or so, the way that businesses use the internet has changed drastically. Many companies have developed new, innovative web applications that store and manipulate vast stores of data.  Traditionally, these applications were hosted in an on-premise data center, but today more and more companies are migrating these web applications to the public cloud. The cloud affords us many benefits: scalability, everything-as-a-service, and near infinite resources at the push of a button – but it also greatly increases a business’s attack surface.

What are some of the common threats faced by web applications?

  • Injection attacks occur when input from a user or another process isn’t properly “sanitized.” For example, a simple form field asking for a user’s email address could be a vulnerability if the application doesn’t verify that an actual email address was entered.  A cleverly encoded string of commands could be provided that compromise the back-end database or application.
  • Broken Authentication can lead to compromised passwords, keys, or session hijacking.
  • Sensitive Data Exposure is often the goal of attackers, attempting to steal or modify data that isn’t properly protected. Many web applications & APIs do not properly protect sensitive data.
  • Brute Force Attacks involve automated, large-scale attempts to “guess” credentials to your protected web applications. Bots are often used in these attacks which may also aim to overwhelm your applications (denial of service, or DoS) with requests in an attempt to render it unable to serve legitimate users.

What are the advantages to implementing automated application security?

Legacy web application firewalls (WAFs) taught us one thing; if your web application’s security can’t be automated, it’s practically useless in an age where applications, and those who wish to attack them, are evolving at an exponential pace.

Traditional solutions in this space often employ a static approach to application protections, meaning they rely on attack signatures rather than analyzing the behavior of the request and the reputation of the user making it.  This approach leads to a high rate of false positives, blocking legitimate users from using your application.  To address this issue, WAF administrators must maintain an ever-growing list of exclusions and manual rules. 

If an organization already owns a WAF, how can owners determine if it still meets the needs of the business?

When evaluating an existing or new application security solution, consider these questions:

  • How much time is my team spending maintaining our Web Application Firewall?
  • How well does the WAF scale to meet the needs of my business?
  • Modern businesses are rapidly deploying new applications, APIs, services, and features to stay competitive. When a change in an existing application occurs, or a new application is launched, does the WAF learn and adapt? Or is manual tuning required?
  • Does the WAF introduce additional latency or complexity to my environment? Does it create more problems than it solves?

What should organizations look for in obtaining a new web application firewall?

  • Where or how will it fit into my applications architecture? Is the WAF hardware, software, or as-a-service?  Can it protect both internet-facing, and internal applications?
  • What are the personnel costs to manage and maintain the WAF?
  • Special considerations when evaluating a security vendor:
    • How many CVE’s (vulnerabilities) has the vendor disclosed in its platform?
    • Is the vendor recognized as security experts in the industry?
    • How long has the vendor been in business?
    • Are they security vendor, or simply a niche player in web application security?
    • What 3rd party has tested or validated the security effectiveness of the proposed solution?

What is the difference between a WAF and RASP (runtime application self-protection)?

A Web Application Firewall (WAF) and Runtime Application Self-Protection (RASP) are both solutions to protect web applications.  But how they accomplish this is the key difference.

A WAF sits in front of the application, inspecting the web traffic and preventing the malicious requests from reaching the application in the first place.  In contrast, a RASP is designed to run on the device serving the application. By existing at this level, a RASP can monitor all aspects of the application at runtime & prevent attacks based on their impact to the application.  However, since a RASP runs at the device level, often it may require greater overhead and could impact application performance.

In configuring a WAF and/or RASP, are there any special concerns for CISOs or IT admins?

Yes, depending on the WAF solution you choose, and how it’s deployed there are additional points to consider during your deployment.

  • Where will this be deployed in my environment? — This will be dependent on the type of solution you choose: embedded software, a standalone virtual machine, physical hardware or is it provided as a service?
  • Who will be responsible for the deployment, maintenance & day-to-day administration? — It’s important to understand the time requirement for administering the solution. Some solutions may require maintenance of whitelists and exclusions.
  • WAF Training & Learning Period — How long of a period is recommended or required by the manufacturer to train the WAF? Will the WAF need to be re-trained on each new release of the application? Will testing be necessary after each training period?
  • False Positives – What is the average false positive rate of the WAF solution? It’s important to take this into consideration and to have an understanding of the impact on your users in the event of a false positive (if the WAF terminates a session, what is the potential effect on the application & user experience)
  • Troubleshooting – Who is responsible for troubleshooting the WAF in case of an error or application degradation?

How can these types of security mechanisms lower costs in the long run?

Determining a WAF’s cost effectiveness is a critical step in the evaluation process.  The costs of a WAF typically consist of:

  • Initial acquisition costs (licenses and on-going support)
  • Cost of the project to include the time spent evaluating solutions & implementing the WAF
  • Any costs that will be incurred to operate the platform (data center, cloud, co-location resources)
  • Personnel costs for implementation and ongoing operation

After determining the total cost involved with your solution you now have a basis to determine the potential cost savings.  According to a publication by the Open Web Application Security Project (OWASP), the potential cost savings of a WAF can be considering from multiple points of view:

  • Avoidance of financial damage resulting from successful attacks on the web application
  • Lower costs for reaching the necessary protection level for the web application in comparison to other options
  • Savings via the use of central services which are made available by a WAF for multiple web applications, and therefore no longer have to be implemented or configured in every application.