Author: Roshan Piyush

  • Web Application Firewalls Aren’t Protecting Cloud-Native Apps

    Web Application Firewalls Aren’t Protecting Cloud-Native Apps

    Your web application firewall (WAF) is humming at the edges of your network, faithfully blocking malicious attacks before they can do any harm.

    Better yet, it’s a next-generation WAF (NG-WAF). It consists of signatures, rules, and a sprinkle of machine learning to protect your applications (and user data) from harm. You’ve got it covered, correct?

    Yeah, right.

    You’re a security expert. You don’t take anything at face value. How do you know for sure your applications are protected?

    And what if you have cloud-native applications — microservices, HTTP requests flying around, multiple touchpoints for each user request? Can an NG-WAF protect all of these apps from external and internal attacks?

    We’ve discovered the answer. Let’s take a look at what NG-WAFs do well, what they struggle with, and whether a solution makes up for their gaps.

    The Challenge of Traditional Web Application Firewalls

    According to OWASP:

    A “web application firewall (WAF)” is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as Cross-site Scripting (XSS) and SQL Injection.

    Modern applications are more transparent than traditional web applications. Focusing on speed and agility of development — Continuous-Integration, Continuous-Delivery (CICD), and DevOps replacing the waterfall development model — developers tend to use open-source projects to save development time and cost.

    This transparency, ease of access, and incredible detail in documentation make the modern applications attractive targets. The frequent changes in applications make it almost impossible to detect and secure every vulnerability.

    WAFs have added new features over the years, but the backbone of their detection still lies in their signatures or rules. The question is: have WAFs indeed adapted to the needs of cloud-native applications?

    Applications have evolved from massive monoliths to microservices and distributed architectures. They now live virtually in any combination of public, private, or hybrid cloud. The new challenges and threats brought on by distributed architectures have given rise to the NG-WAFs.

    Network firewalls underwent a similar transition, where the Next-Generation Firewalls (NGFWs) introduced a new perspective of looking at firewall traffic with deep packet inspection and attack-centric detection models.

    The next generation WAFs have been frequently defined with three principal characteristics:

    • Detection is based on the application and the attacker’s behavior.
    • Going beyond signatures to identify anomalies and fundamental attacker actions.
    • Cloud-native deployment supporting various cloud platforms, APIs, and microservices architecture
    NG-WAF

    What NG-WAFs Solve

    NG-WAFs propose to solve the new problems introduced by changing application architectures.

    How well have they done? Let’s start by reviewing what NG-WAFs do well.

    Increased Cost to Attackers

    Attackers have a distinct advantage — they don’t play by the rules.

    We live in an age when you can connect almost any device in your home to the internet. Unfortunately, many IoT devices don’t take security measures, which means attackers are salivating at the opportunity.

    Malicious actors try to mask their origin and evade detection using an army of “bots.” Yes, they’re attacking you with DVRs, cameras, and lightbulbs.

    NG-WAFs take a fresh approach of correlating such behavior to detect the attackers and block them, thus increasing the cost for attackers and partly deter the script kiddies.

    Layered Protection: The In-depth Defense

    Defense in Depth increases system security by using a multi-layered approach with intentional redundancies. It’s commonly referred to as the “castle approach” because it mirrors a medieval castle’s layered protection. If one layer fails, another is waiting to take its place.

    NG-WAFs have evolved to protect at multiple levels, including the traditional perimeter and the newer approach of embedding alongside the applications. These layers make an attacker’s job much more difficult and expensive.

    Machine Learning and Behavioral Analytics with Automated Policy Learning

    NG-WAFs aggregate detection from multiple applications to understand attackers from a broader perspective to contextually score them. Using machine learning and behavior analytics on the aggregated data, NG-WAFs automatically disable signatures that would trigger false positives and update the application policies accordingly.

    Virtual patching

    You ideally want to identify and fix every vulnerability found in your code. But real-world business situations dictate that not all vulnerabilities will be fixed quickly or at all.

    A few NG-WAFs support virtual patching to prevent attackers from exploiting critical vulnerabilities until an official fix is available.

    Cloud-native Support

    NG-WAFs now support deployment in a public, private, or hybrid cloud. The NG-WAFs automatically integrate with a containerized approach to scale security natively and elastically. They distribute nodes all over the world to maximize coverage without increasing latency.

    What NG-WAFs Have Failed to Solve

    NG-WAFs have made strides in securing applications. They’ve used defense-in-depth to make successful attacks increasingly tricky to pull off.

    They’ve incorporated new architectures and virtual patching to match the pace and style of current app development. But they haven’t solved every problem.

    Let’s look now at what NG-WAFs are missing that may open up holes in your security.

    Motivated Attackers Can Bypass NG-WAFs

    WAFs introduce obstacles for hackers and penetration testers by making vulnerability finding and exploitation more resource-intensive. However, an experienced hacker or a researcher with enough motivation would probably be able to find ways to bypass it.

    When the application use case becomes complex, it may demand disabling many defenses that produce a higher false positive rate. The more complex a web application is, the bigger its attack surface, and the easier it is to find a bypass for it.

    NG-WAFs Are Vulnerable to Use Case Exploitation

    The same application deployed in different contexts exhibits different behavior. Requests that are harmful for one application may be perfectly normal for the other as user behavior varies for each case.

    NG-WAFs do not have a complete picture of application usage — they cannot detect the business use case. The attack patterns stay hidden within regular traffic and nested protocols. Eventually, the attacker can tune himself to the business traffic and bypass the NG-WAFs resulting in a window of vulnerability and delay in breach detection. Straightforward implementations for detecting such use case exploitation often result in a high rate of false positives and false negatives. Further, customers rarely use all of the available features and rules in modern NG-WAFs.

    Machine Learning and Behavioral Analysis Are Limited to Perimeter Defense

    NG-WAFs have evolved from WAFs and base themselves on a “perimeter defense” model — it guards only against malicious traffic originating outside the network. However, this model fails if an attack comes from within – a common occurrence given the wide variety of ways users can connect to an internal network.

    The new “stay at home” normal and increased risk of insider threats has led enterprises to adopt the Zero Trust model. It is essential to monitor the external traffic along with the internal flow and state of the applications.

    Missing Runtime Protection

    Malicious hackers are attacking all the application stack tiers, be it web, memory, or database. By design, NG-WAFs are limited at the edge of the application module and cannot protect the application at runtime. With this knowledge, the attacker could also circumvent the virtual patch defenses once the vulnerability is known to them by altering their attack method or mingling with the business traffic.

    Monitoring blind spots

    Monolithic frameworks base the visibility into the application on logging frameworks. Want to know what’s happening? Only one directory to check.

    Modern applications built on microservices and serverless introduce advantages to application development, but there’s also the cost of reduced visibility. You can monitor each service individually, but one can quickly lose sight of the global system behavior.

    A single request to the modern application can create a chain of calls behind the scenes. What appears simple can sometimes be incredibly complicated. For example, take a look at what happens inside Netflix when you hit play during your latest binge.

    This call chain generates a massive amount of data along its flow path. External applications have trouble ingesting it all. Instead of solving this problem, most NG-WAFs limit the amount of data they can capture and process, introducing blind-spots the attackers can leverage to bypass them.

    How to Protect Cloud-Native Applications

    Cloud-native microservice architectures introduce drastic benefits but are also challenging to defend. While NG-WAFs have made some strides, they still fall short in several crucial areas. To comprehensively protect your cloud-native apps you should look for a solution that seamlessly provides both security observability and intelligent threat detection. Look for solutions that offer:

    • end to end distributed tracing and visibility, increasing the accuracy and depth of attack detection without extra overhead
    • features that establish baselines for user behavior, API logic, and data flow to identify anomalies
    • the ability to block business use case abuses, insider attacks, and threat actors, even in distributed systems
    • visibility that provides a complete picture of how data (especially sensitive business and personal data) moves throughout your application so you can see problem areas before they become exploits
    • discovery and protection of the complete eco-system of your microservices

    If you’d like to learn more about TraceableAI you can view a recorded demo of Traceable in action.

  • What Runtime Application Self-Protection (RASP) Doesn’t Solve

    What Runtime Application Self-Protection (RASP) Doesn’t Solve

    RASP, or Runtime Application Self-Protection, is a modern security technology that protects web applications from attacks during runtime. The technology is an important complement to defense systems that focus on the perimeter, but RASPs also have weaknesses that can introduce their own vulnerabilities.

    What are RASP’s strengths and weaknesses in protecting against modern security threats? Are there better solutions that offer more in-depth insight into attacks as well as detect suspicious behavior?

    A deeper dive into RASP

    Gartner defines RASP as “a security technology that is built or linked into an application or application runtime environment and is capable of controlling application execution and detecting and preventing real-time attacks.” Many IT organizations already deploy them, often in conjunction with other security solutions.

    An ideal RASP promises:

    • Deeper-rooted code-level visibility into applications
    • Passive and active incident response features such as monitoring/alerting and blocking modes
    • Configurable options to log, alert, challenge, or block malicious behaviors
    • Support for many languages and execution platforms
    • Autonomous operation without manual tuning
    • Coverage for a broad set of vulnerabilities, including OWASP top 10
    • Integration with secure software development lifecycle (SSDLC) and monitoring tools.

    RASP fills the security gaps left by a perimeter defense model like Web Application Firewall (WAF), which protects both legacy and modern applications. Based on these promises, RASP may look like the necessary missing piece of your security stack. In practice, however, it has weaknesses. Let’s dive deep into RASP to understand its advantages and shortcomings.

    RASP advantages

    Watches rather than predicts

    Similar to WAF, Runtime Application Self-Protection works by blocking malicious behavior but does so without extensive need for preset rules and tuning. Rather than building a trained model or predicting behavior, RASP watches the application at runtime to see that those actions are actually performed. For example, a request call to a database occurred, a shell command is executed, or that a file is opened.

    DevOps-centric attack visibility with better SSDLC integration

    RASP provides visibility into how an application is being attacked, providing better intel and alerting security personnel and developers to the exact vulnerable code. Developers can use this information to modify the codebase and eliminate security vulnerabilities. RASPs may also offer the option to integrate directly with the application development lifecycle to pinpoint vulnerable code based on attacks observed in the production environment.

    No training required

    An ideal RASP doesn’t need to be taught what bad behavior looks like. That’s because it is tied to the application stack, so knows what the application should and shouldn’t be doing. When the application’s behavior changes, it’s no problem for RASP to adapt because the security is based on the application and not on a set of predefined rules and educated guesses.

    Provides time to fix vulnerabilities

    Programmers are responsible for developing and releasing new applications and features, and subsequently developing updates and patches as vulnerabilities and bugs are discovered. It can take organizations months to apply patches which creates a window of opportunity for hackers. Because RASP protects against incoming attacks, it provides the engineering team time to fix vulnerabilities free from the pressure of working during a crisis. It is synonymous with WAFs’ virtual patching.

    Cloud agnostic

    The RASP protection design is rooted in modern software engineering techniques such as instrumentation, dynamic hooks, and secure SDKs. It works by implanting sensors in the existing application code to monitor and control critical execution points in real time. Utilizing these techniques, RASPs become part of the application, allowing them to remain protected independent of their deployment environment. RASPs may not require network calls and work in any deployment architecture, including on-premise, cloud, and containers.

    RASP disadvantages

    Confined context

    Purely from a technical viewpoint, since RASP sits within the application framework, it may look to be a smarter alternative to perimeter defense solutions like WAF. Practically, however, no application is self-contained;  they interact with a multitude of other services and components. Consider that each application module can be deployed in different endpoints, further limiting the RASP’s visibility and capabilities.

    Use case abuse

    We frequently hear about large companies breached with modern application attacks like Broken Object Level Authentication (BOLA). Attackers substitute their resource ID in the API call with a resource’s ID belonging to another user. The lack of proper authorization checks allows attackers to access the specified resource resulting in BOLA. Since the input remains consistent with what the application received before, RASP finds no reason to inspect and will let it pass through. Attackers can abuse similar use cases like Broken Function Level Authorization (BFLA) without RASP suspecting the intrusion. Protection for such attacks requires building broader business context from the application, which RASPs lack.

    Normal API request by Robby to fetch his profile BOLA Attack: Robby changes his user id in the
    request and reaches Ava’s profile
    <code>
    REQUEST
    ===============
    GET /customer/
    12548
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12548

    “fName”: “Robby”

    “lName”: “Saxton”

    “phone”: “202-555-0128”

    “ssn”: “987-65-4325”

    “address”: “3454 Crummit Lane,

    Omaha, NE

    68114”
    }

    </code>

    <code>
    REQUEST
    ===============
    GET /customer/
    12549
    /profile
    Host: shop.store
    Cookie: session=
    5015ee5d-6133-cab4874b
    Accept: application/jsonRESPONSE
    ===============
    HTTP/1.1 200 OKContent-Type: application/json{“id”:
    12549

    “fName”: “Ava”

    “lName”: “Rose”

    “phone”: “340-5556-577”

    “ssn”: “449-26-2109”

    “address”: “4702 Gordon

    Street, Chino, CA

    91710”
    }

    </code>

    Missing distributed protection

    Since RASP only has visibility for the current application context, additional application-level Distributed Denial of Service and Bot protections cannot be efficiently solved by RASP. A perimeter defense solution can completely isolate that traffic, absorb it, and take defensive action even before the attack hits the application stack.

    Intrusive deployment

    RASP requires an intrusive deployment model and is highly dependent on the platform and codebase used for the application to be beneficial. It has to be deployed along with the application in the application stack. Some organizations may not feel comfortable deploying RASP for critical services, thus needing to invest more in other security solutions that add cost and maintenance.

    Deployment challenges

    Conceptually, RASP can do more in-depth protection sitting within the application stack. But there are practical challenges in managing and updating a RASP component deployed at every endpoint. RASP adds additional performance overheads not just on the application execution but also on the dedicated effort required to deploy, tune, and monitor itself and the runtime environment. And to determine proper placement that protects all assets, RASPs may need you to gather internal information about the application and trace data flow.

    Unintended consequences

    Though RASP’s goals are noble, its deployment can create unintended consequences that produce pain points. For example, situations may require the rewriting of software execution at the last minute, introducing risk from a support/incident response perspective, particularly as applications are modularized and supported by distributed teams.

    Performance degradation and impact on service level agreements

    In today’s high-performing environments, where availability is expected to be at least four 9s, downtime could severely impact SLA’s, resulting in lost revenue and damage to the company brand. RASPs might impact the application functionality even in monitoring mode as they wrap over existing essential library functions. Since RASP does not learn the business context, it may predict that a perfectly valid use case is malicious. Allowing RASP to stop code running in production amid an attack may pave the way for an effective (and self-imposed) Denial of Service (DoS) engine.

    Too much reliance

    RASP should be considered as another layer of control, but human behavior can lead to too much reliance on RASP for application protection. This behavior can generate a pile of vulnerabilities that attackers can use in conjunction with other techniques to exploit the application. For in-house-developed proprietary libraries, RASP tools are still not substitutes. The Secure Software Development Lifecycle needs to be followed with other formal methods such as source code reviews and automated tools, like static application security testing and dynamic security application testing, to identify and remediate vulnerabilities in both the source code and the application.

    You deserve better

    RASP is not a plug-and-play technology; it requires a full cycle of validation with existing applications to ensure functionality and performance are not adversely affected. What RASP makes up for in some areas it lacks in others.

    There is a need for a better solution in the application security world that can provide more in-depth insight into attacks as well as detect anomalous behavior. Traceable provides this hybrid approach by combining distributed tracing with intelligent analytics to build a complete picture of your microservices and protect them. Don’t just cover one part of your application; defend it all.
    ‍

    If this sounds like a smart approach to detecting and treating modern security threats, then we should talk. View a demo of Traceable in action.