devopsy.kinsta.cloud

Tag: Traceable

  • Cloud Security Requires Shared Responsibility

    Cloud Security Requires Shared Responsibility

    The Growth of Public Cloud and the Need for Cloud Security

    Since 2006 when Amazon first introduced EC2 — the first public cloud service — cloud has become a major staple of enterprise information technology strategy. Both Infrastructure as a Service (IaaS) and newer cloud services continue to grow robustly. Enter the need for cloud security.

    While providing undeniable benefits to users such as scalability, speed to market, and cost savings, public cloud offerings also created a new dilemma: Just who was responsible for security when the platform was no longer protected on the user’s  premises,  and was in some part controlled by a third-party vendor?

    Cloud security is an issue the industry has had to solve in order to achieve such impressive growth. Since 2014, security services have been a key focus area of cloud providers. This includes protection of the infrastructure itself and tenant boundaries, as well as advanced services protecting the data itself. Without security, no reasonable enterprise would use public cloud in production.

    AWS Approach To Shared Responsibility Model

    As a public cloud pioneer, Amazon Web Services (AWS) was the first provider to introduce the term “shared responsibility model” and its components, starting to think about improving  cloud security to a level sufficient to protect enterprise production workloads.

    According to Amazon:

    ‍“Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.”

    In short, AWS secures the cloud’s physical infrastructure, compute, and network systems  from outside physical access and from digital access and insider threats.  The customer’s responsibility is to protect everything they run in the cloud.

    What Needs To Be Secured in a Cloud Deployment?

    The importance of security in the context of public cloud has led to formation of the Cloud Security Alliance (CSA). CSA has their own interpretation of the shared responsibility model.

    From the CSA’s perspective, the following are the categories of cloud systems that need to be secured:

    Information and Data – Data are the crown jewels of any digital business. From the addresses of paying customers to sensitive financial records and employees’ information ,  protecting data is critical to the success of any online business. Further, many compliance regulations, especially the recent focus on GDPR and CCPA, exert additional pressure to protect personally identifiable information.

    ‍Application Logic, APIs, and Code – The data are interpreted and processed by the application logic and application programming interfaces, or APIs. The code that implements applications can represent a core competitive advantage for the enterprise, but the logic itself and protection of the APIs is extremely important for securing  both the business and its data.

    ‍Users, Authentication, and Access Control – Users — who are both owners of the data and the source of revenue for the online business — , also need protection. From account takeover to identity theft, malicious actors can harm the users. The owner of the service where such attacks take place  is ultimately responsible for providing security.

    ‍Platform and Resource Configuration – This is the only major component of the cloud that is protected by the cloud provider itself. Protection is typically extended to the physical premises, computing resources, including cooling and physical maintenance requirements, network resources, virtualization systems and hypervisors, resource management systems, storage systems and so on.

    As Platforms Evolve, Does Shared Responsibility Change as Well?

    Newer cloud services go beyond providing just infrastructure-as-a-service and may influence how we think about shared responsibility.

    For example, some of the more interesting platform offerings include serverless compute services, a cloud development model that allows developers to build and manage applications without having to worry about server management. These offerings include  AWS Lambda, AI-as-a-service, (such as Google Cloud AI), and hosted blogs like Medium.

    If the application uses one of these advanced services, it changes how the shared responsibility model is applied because the provider is not just responsible for the host, but also for the security of the platform itself.

    While this helps us sort out security responsibilities, we must still consider security of information and data (think hosted WordPress blog); security of intellectual property and code (such as the case with serverless);  and security of the API and application logic (as might be the case with a hosted Kubernetes infrastructure, Amazon Elastic Kubernetes Service or Azure Kubernetes Service). All these data, application logic and code elements should still be secured by the cloud user or enterprise according to the shared responsibility model.

    There are a couple of additional important security considerations for newer platforms. Watch out for cloud lock-in. While running a guest Linux OS makes it extremely easy to migrate  workloads back on premises or to a different cloud, running the logic on a hosted platform makes the migration more difficult: the logic becomes dependent on the provider APIs. Secondly, data flows and compliance becomes a touch more difficult because best practices are not as well established for newer platforms.

    How Traceable Can Help with Cloud Security

    Traceable Defense AI provides application protection that helps fill in the customer’s share of the shared responsibility, especially as data flows, application logic, and APIs are concerned.

    Data flows – Traceable observes the data flows throughout the application running on the platform and identifies sensitive data for compliance purposes.

    API security in pre-production and production – Traceable maps out the application flows, protects applications and APIs from run-time threats, assesses API risks and helps with threat analysis and compensating controls.

    User-centric view – Traceable identifies suspicious activities and anomalies. When suspicious activity is detected on a previously well-behaved account, it’s an indicator of an account compromise. Combined with a rate-limiting functionality, this helps protect legitimate users.

    Traceable is a born-in-the-cloud company that prides itself on helping enterprises adopt cloud-native architectures in production. Understanding the shared responsibility model, selecting the cloud provider that holds up their end of the bargain, and using the right cloud security tools to fulfill the enterprise share of security responsibility is what will make the cloud truly secure.

    To learn more about Traceable you can visit us at https://traceable.ai or view a recorded demo.

  • Securing Microservices Vs. Monolithic Apps

    Securing Microservices Vs. Monolithic Apps

    New requirements for Securing Microservices Vs. Monolithic Apps

    Enterprises are migrating from monolithic applications to microservices, hoping to accelerate software deployment and improve scalability. Security is sometimes glossed over in these transitions.

    Simple best practices like authenticating users and using SSL are still important to follow. But teams need to think through important differences between the two architectures to ensure new risks are not inadvertently introduced.

    As you begin  migrating from a monolith to microservices, some of these issues may seem relatively trivial. But left unaddressed they can create substantial security vulnerabilities, reduce performance, and result in technical debt.

    Some of the most important differences to consider include the number and size of attack surfaces, and how and where teams manage business logic security. Teams also need to think through the additional complexity of increased communication between microservices running in separate containers or machines. New issues also need to be addressed when application state is stored externally.

    1. One Larger Versus Many Smaller Attack Surfaces

    The biggest difference relates to the size and number of attack surfaces. A monolithic application is by definition a single application with a single attack surface. In contrast, a microservice architecture spreads the same functionality across multiple, independently running microservice applications, each with their own attack surface.

    The attack surface on the single monolithic app is also larger than on each microservice because the application has far more responsibilities to control.  In contrast, the attack surface of each microservice is much smaller because they are limited in what they can do. In traditional web application security, a web application firewall can protect the entire application in aggregate. With microservice security, however, teams need  to think about securing the connections to each microservice using a more adaptable firewall.

    2. Managing Business Logic Security

    Web application firewalls provide a front line of security to track what clients are requesting data and ensuring they have the appropriate credentials. Monolithic applications often add an additional layer of business logic security using a servlet. This performs logical filtering within the app itself to ensure requests are reasonable before passing them to the appropriate component.

    As a result, monolithic app components can operate on the assumption that the request has been validated at the application programming interface (API) level by the servlet. The servlet can keep track of who is making calls into the application and block requests that fall outside the bounds of normal behavior. A microservice rarely if ever has any idea about what has been done between other microservices. They are typically designed to operate independently from the details of everything around them, which means that business logic-level attacks are easier to perpetuate.

    3. Service-To-Service Complexity

    In a traditional monolith, messages are passed between functions within the application. In a microservice architecture, this traffic passes between multiple services that may reside behind a common firewall or separate firewalls.

    Developers may mistakenly believe these communications are safe when the messages are passed between services that exist behind a common firewall. But because of the dynamic nature of microservices, sometimes these communications are passed over wider networks. There can be security issues when data is passed between applications in plain text.

    Teams should consider encrypting data in transit as it is passed between microservices, and then encrypting data at rest when it is stored.  This encryption requires teams to think about creating an encryption process that runs in conjunction with provisioning and managing microservices. Each service needs to be provisioned with a public certificate and private key. There also needs to be a method for revoking  certificates and issue new ones when services are decommissioned or compromised.

    4. Authentication Latency

    Microservices can also increase the number of authentication steps required to execute a transaction. In traditional application security, an API security service only needs to secure one link between client and server.   With microservice security, additional consideration needs to be given to securing the connection from a client to each microservice and to the calls between them. This increases the number of security steps required for requesting and processing security tokens. Unless this process is efficiently engineered, each request can add latency and degrade performance.

    Some organizations may skip some of these steps, under the assumption that these services are communicating on a secure virtual private network. However, this can increase app vulnerabilities if the network is compromised. Another approach lies in implementing a better strategy for API security.

    5. Immutability

    Monolithic applications manage data as part of their operations. In contrast, microservices are architected so all data is stored external to the microservice, which is called immutability because the service does not change state. This makes it easier to spin up new instances or kill running ones without affecting the application as a whole. But because the microservice itself does not change, an external process needs to maintain a list of which microservices are allowed to talk to others. These need to be managed centrally and then either pushed out or pulled in to each microservice automatically.

    Another challenge is data integrity. In a traditional application, the state of a transaction can be monitored internally; if a step cannot be completed the entire transaction can be rolled back. In a microservice architecture this kind of state management needs to be managed externally.

    6. More Services To Monitor

    Traditional infrastructure-based monitoring was designed for providing endpoint and server security. Microservices generate more traffic between services at a finer level of granularity,  which can make it harder to automatically enable application observability through metrics, logs, and tracing. This is difficult enough just for measuring operational health, and even harder for tracking security posture.

    Another challenge confronting security designers lies in ensuring consistency for application observability data generated across microservices. At the least, security requires good logging and integration into incident response systems to alert security analysts to the possibility of subtle and slow-moving security breaches. More sophisticated approaches can combine these richer data sets with machine learning to help detect and block attacks without burdening teams with false positives.

    Planning for a New Security Posture

    None of these security concerns should be deal breakers for transitioning to a microservices architecture. But as enterprises begin to scale up their microservices implementation, these issues will grow in complexity. A little planning upfront could reduce the need for significant rework down the line.

    Security tools such as Traceable’s Defense AI are emerging to address these challenges in a more automated way. The key lies in balancing the appropriate set of rich observability data and machine learning, with a deep understanding of the rapidly evolving API threat landscape.

  • Dependencies in Cloud-Native Apps can Amplify Risks

    Dependencies in Cloud-Native Apps can Amplify Risks

    Hidden Dependencies in Cloud-Native Apps can Amplify Security Risks

    Cloud-native applications and modern development practices result in applications that are highly distributed and loosely coupled. In many cases, organizations have no control over or little insight into the different elements and software entities they use in their applications. The result often is hidden dependencies that can impact performance and add to security risks.

    The New York Times noted an example of the consequences of hidden dependencies. The article cited the work of researchers who observed that the quality of weather forecasting models declined as air travel dropped off during the pandemic. One might easily conjecture there was a physical cause and effect. Jet engine exhaust includes water vapor, soot, carbon dioxide, unburned fuel, and several oxides. Perhaps the diminished amounts of these particulates due to fewer commercial flights had some impact on lower stratospheric dynamics.

    It turns out that was not the case. The article reported that researchers found “that when a short-term forecasting model received less data on temperature, wind, and humidity from aircraft, the forecast skill (the difference between predicted meteorological conditions and what actually occurred) was worse.”

    Atmospheric observations made by instruments on commercial and cargo planes are “among the most important data used in forecasting models,” according to the article. The measurements are transmitted in real-time to forecasting organizations around the world, including the National Weather Service.

    The pandemic resulted in fewer flights. So, there was less or no data. A prediction’s degradation due to this data disruption not only impacted the primary forecasting application but had many downstream implications. For example, these short-term forecasts are used by many industries (logistics, agriculture, entertainment, public safety, and more) to make business decisions. Hence, the degradation of performance in that one application due to previously unknown dependencies could propagate to third-party apps that simply relied on the output of this one app as input for theirs. In a sense, this particular dependency (fewer observations leading to poorer quality forecasts) becomes yet a different hidden dependency in many other applications.

    Security implications

    As this example illustrates, small changes in complex systems can have unexpected application performance impacts. They also can impart unintended security problems.

    At the heart of the issue is the fact that today’s cloud-native applications are complex systems. And security in cloud-native systems can be impacted by small changes.

    It might be something as simple as reusing a component whose original permission setting gave a development team broad access to certain data for testing purposes only. With software component reuse being quite common, that point may be forgotten at some point, and the code might be made available to other groups. Those groups may just want anonymized records in that database or a subset of data that did not include records that should remain private. Use of that code in a larger cloud-native app for such purposes would not necessarily expose the data. But someone might discover the mistake later and exploit it.

    Another aspect of cloud-native application security is that many modular elements are linked together via APIs and microservice calls to form a larger application. Those software elements (be they open-source or commercial) often have security flaws.

    A report last year by the Laboratory for Innovation Science at Harvard and The Linux Foundation highlighted this issue, noting the need for an “understanding and addressing of the security complexities in the modern-day software supply chain.” With frequent reuse of components, even if a known vulnerability is taken care of with a patch, the problem may not be eliminated. Someone needs to know that piece of code is in a distributed cloud-native app, that there is a patch for the vulnerability, and that the patch was applied.

    Any small flaws like this can have a larger negative effect on the security of the entire cloud-native system.

    What’s needed

    The reliance on open source and third-party code in cloud-native applications requires that security be entrenched throughout an application’s lifecycle. It is no longer enough to test for vulnerabilities after the fact. Third-party or open-source code used in any one element of a larger application might be changed at any time. If a vulnerability is introduced, a developer might not know of it.

    The inter-dependent nature of discrete code working together in a vast cloud-native app thus requires a new take on security. The constant refreshing, updating, and replacement of applications dictate that security must be an integral part of the entire lifecycle of an application. As such, companies must bring security into the application lifecycle just as DevOps does for development and deployment.

    To find these impacts, stay ahead of them, and react effectively and efficiently when they show up, developers and companies need a deep understanding of the context of their systems and how all the parts work together. Just as the pandemic-related downturn in commercial flights impacted the accuracy of forecasting models, so to can a seemingly unrelated (or unknows) security flaw in one part of a cloud-native application impact the entire application.

    To avoid such problems, a DevSecOps approach is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s applications comprised of many interconnected parts.

  • The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    The Shopify Breach: Why Authz Exploits Slip by Most Security Defenses

    What Happened

    As part of a bug bounty, the security researcher Uzsunny found a critical vulnerability on the Shopify platform. The vulnerability allowed the attacker to assign himself as a “collaborator” to any store on Shopify without approval from the store’s manager. Collaborators have full access to perform any action on the store, including reading customers’ data, changing inventory and more.

    Technical Details

    The Shopify Partners Program allows experts to connect with Shopify store managers and provide them services such as design and web development. A single expert can be a collaborator on different stores.

    The process of requesting “collaborator” access to an existing store contains three steps:

    1. The expert enters the store URL.

    2. The store manager receives an email about the access request.

    3. Once the store manager approves the request, their browser sends an API call to:

    This API call approves the access request by the expert and converts him to a “collaborator.”

    The problem: The code did not validate that the API call was triggered by a store manager. In fact, any user could call the API endpoint and approve the access request, even if they don’t have the right privileges.

    Using this technique, Uzsunny managed to “log in to any store with full permissions.” For his troubles, Uzsunny received a $20,000 bounty from Shopify, which reported: “We tracked down the bug to incorrect logic in a piece of code that was meant to automatically convert an existing normal user account into a collaborator account.”

    Why Can’t Current Security Solutions Detect It?

    The exploit in step #3 looks simple and requires only a single HTTP request: “POST /admin/settings/account/approve/<id>.” Authorization exploits usually look legit from a WAF/RASP perspective; they don’t contain suspicious payloads or characters, weird HTTP headers or abnormal structure. In fact, if the same exact HTTP call was sent by a different user who is a store manager it would be completely legit.

    In order to understand authorization exploits, a much broader context is needed. It’s simply not enough to look at a single HTTP request.

    How Traceable Solves the Problem

    Our approach to detecting API attacks is very different. In a nutshell, we observe the data that passes through the API and the microservices of the app. We then use our machine learning algorithms to discover the application’s business logic. We get full visibility into the users and their roles, the API endpoints they communicate with and the resources the endpoints interact with behind the scenes. Now we can create a baseline understanding of a legit user’s flow through the system.

    The visibility into users helps us understand that the client is actually a guest user, and the visibility into the API helps us to recognize that the endpoint is an admin endpoint that should be used only by store managers. Then we can simply block malicious abnormal activity.

    With this approach, we can detect the most sophisticated and subtle API attacks, including broken function-level authorization (BFLA).

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • Why Was Facebook Vulnerable to an Authentication Exploit?

    Why Was Facebook Vulnerable to an Authentication Exploit?

    What Happened:

    As part of a bug bounty program, the AppSecure cybersecurity research team found a vulnerability on the authentication mechanism of Facebook. It gave them the ability to potentially gain full control of the social media giant’s more than 1 billion users. The team won a $15,000 bounty for its discovery.

    This vulnerability was found on a niche API, which reminds us that in many cases the most interesting bugs don’t exist on main APIs but on secondary ones that have fewer protection mechanisms in place.

    Anand Prakash, CEO of AppSecure and who was credited with finding the bug, explained what he found: “This gave me full access to other user accounts by setting a new password. I was able to view messages, their credit/debit cards stored under their payment section, personal photos, and other private information.”

    Even though the vulnerability was discovered in 2016, similar weaknesses have been discovered — and in many cases exploited — ever since. Here is a closer look at the Facebook case and lessons to be learned in modern application development.

    Technical Details

    The vulnerability exploited the password recovery mechanism on Facebook. The steps of the process were:

    1. The user starts the “forgot password” process by using their email address.
    2. Facebook sends a text message with a temporary 6-digit secret token to the user.
    3. The user enters the received temporary code, and the browser sends an API call to “POST facebook.com/recover/as/code/” with the secret token.

    Facebook had implemented an anti-brute force mechanism on this API that blocked the user after 10 failed attempts. However, during their research, the AppSecure team found that the same API endpoint existed on different API hosts, under “beta.facebook.com” and “mbasic.beta.facebook.com.” These API hosts didn’t implement the anti-brute force mechanism, allowing the attacker to easily iterate through the secret token and reset the victim’s password.

    Why Current Security Solutions Can’t Detect It

    Keeping track of your APIs it’s not an easy task. Modern organizations might have dozens or even hundreds of API hosts for different environments, regions, or versions. Each API host can expose multiple API endpoints that are related to authentication processes including login, forgot password, and one-time login link. Many security solutions in the market focus on protecting your main APIs and don’t have enough visibility into the less common or less used APIs (such as Facebook’s beta API in the example above). Sophisticated attackers choose to target those niche APIs.

    How Traceable Solves the Problem

    Traceable AI monitors all APIs including the different environments, versions, and regions. For each API host, we automatically and manually detect the authentication endpoints that your APIs expose (including login, forgot password, etc).

    This granular understanding of the API structure allows us to set very strict protection for your most sensitive assets.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • The Uber API Authorization Vulnerability

    The Uber API Authorization Vulnerability

    What Happened

    In September 2019, a critical bug was discovered on Uber API, which allows merchants, service providers and others to offer ride-sharing services to customers. Uber had exposed a vulnerable application programming interface (API) endpoint that allowed attackers to steal valuable data, including personally identifiable information (PII) records and authentication tokens of riders and drivers. The leaked authentication token could be used to perform a full account takeover.

    Luckily for the company, the vulnerability was discovered before harm could be done. But the case is an example of where traditional security systems can fail to find potential threats because they lack the business context for the application’s logic. Let’s take a closer look at what happened and the implications.

    Technical Details

    When a new Uber driver joins the platform through a referral link, their browser communicates with the API host  “bonjour.uber.com”. The registration process triggers an API call to the API endpoint of:

    POST /marketplace/\_rpc?rpc=getConsentScreenDetails

    The API receives the “userUuid” parameter from the client and returns details about the user. This information is used to populate the consent screen on the client-side:

    As part of a legit flow, the user should send only his own user ID.

    The API endpoint is susceptible to two types of API vulnerabilities:

    • BOLA (Broken Object Level Authorization). Because the program didn’t validate that the client who sent the request had access to the user represented by the user ID parameter, the client could access data of other users by changing the user ID.
    • Excessive Data Exposure. The API response contains a large JSON object with all the user’s details. The API returned this information, even though the client didn’t use it.

    Why Current Security Solutions Can’t Detect This

    When we look carefully at the exploitation flow, we find the attack involved a very subtle change in the API call, replacing one user ID with another. In order to detect such a small change in the traffic, a deep understanding of the business logic of the app is required.

    Current security solutions in the market lack that understanding, usually acting on the context of a single HTTP request. They don’t deeply understand important components of the application that are required to detect BOLA and other authorization vulnerabilities.

    How Traceable AI Solves the Problem

    The Traceable Defense AI approach to detect API attacks is very different than other security solutions. In a nutshell, it observes the data as it is passes through the API and the microservices of the app. It then uses machine learning algorithms to discover the application’s business logic, providing full visibility into the users and their roles, the API endpoints they communicate with, and the resources that the endpoints interact with behind the scenes.

    This methodology allows Traceable to create a baseline of what a legitimate user’s flow looks like, and hence to detect the most sophisticated and subtle API attacks, including BOLA.

    Interested to learn more?

    Watch our recorded demo and see Traceable Defense AI in action!

  • 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.

  • The New Norm for Modern Apps: Security Observability

    The New Norm for Modern Apps: Security Observability

    Observability has burst onto the scene across all types of operational and security-focused activities. Its need is being driven by increased demands for businesses to be more responsive to changes and more proactive when dealing with potential problems. In particular, security observability holds the promise to help reduce the time to detect a cyberattack. And going a step further, it can help detect security vulnerabilities before an attack even occurs.

    What is security observability?

    In the past, most operations relied on visibility into their systems and applications to manage security. Visibility would be achieved via monitoring applications, systems, and their logs. Monitoring solutions would collect and analyze information to detect suspicious behavior or unauthorized system changes. And having defined which types of behavior should trigger alerts, solutions would take action as needed.

    Perhaps more to the point, monitoring lets you detect a known set of problems or conditions. Thus, it is essential for alerting and analyzing long-term trends. Simply put, monitoring lets users know how their systems and applications are functioning and being used.

    However, the problem with security monitoring of complex distributed applications is that it is a passive approach to highly dynamic operations. And it often does not provide any insights into root cause problems or anomalies that might be precursors to problems in the making.

    Security observability expands on monitoring by enabling correlation and inspection of the data to provide much deeper insights. Observability typically requires logs, metrics, and deep tracing. All data is used for modeling and analytics. Companies can mine the data, look for patterns, use artificial intelligence and machine learning to remediate problems and proactively defend against problems.

    Why security observability is needed now

    The need for security observability is growing due to the way applications are developed.

    The general industry trend is a move to cloud-native architectures based on microservices. Such an approach brings many benefits. Applications can scale quickly. Companies can easily change or update a small aspect of a larger application without impacting the rest of the app. And businesses can make use of new technologies. For example, a business can add a new front-end or implement more sophisticated AI or machine learning modeling.

    Such a development approach can introduce potential blind spots and complexity. In particular, modern applications built using cloud-native architectures and microservices introduce new challenges. The loose coupling of such applications, their distributed nature, and increased complexity makes it harder to understand vulnerabilities. As a result, traditional cybersecurity approaches break down. They miss the interactions and inter-dependencies of the many elements that comprise modern applications.

    Furthermore, traditional security monitoring solutions can be limited. For example, visibility often must be split across tools resulting in insecure platforms or situations where relevant data is not even used in monitoring.

    Adding to the security challenges is the widescale embracement of low-code/no-code development methodologies. Such technologies open development up to business units and citizen developers. These groups can build sophisticated applications, often with little oversight or guidance. As a result, apps may be created by assembling building blocks that may be outdated, unpatched, or simply have vulnerabilities.

    DevSecOps needs security observability

    With all these trends, it is not surprising that businesses are exploring new approaches to security. Just as quality assurance was melded into development processes using automated testing, security ops are being meshed with development. Hence, the rapid implementation of DevSecOps methodologies in organizations today.

    While security issues can grow when using cloud-native development methodologies, there is a lesser-known security benefit. Applications and services constructed using APIs and microservices have an advantage over other systems because developers and security staff can more easily observe what’s happening inside them. In addition, businesses can add links to the APIs and microservices and use tools to collect the details of such operations.

    Given this wealth of data, security observability expands on monitoring. Rather than just detecting vulnerabilities and incidents that raise compliance issues in the development process, DevSecOps using security observability, seeks to identify issues and automatically take corrective actions.

    Moving forward, businesses should expect more adoption of DevSecOps and more automation based on security observability. This will only serve to strengthen security and compliance across systems and applications.

  • TraceAI : Machine Learning Driven App and API Security

    TraceAI : Machine Learning Driven App and API Security

    API security

    Modern applications are mobile first and are built around cloud-native distributed microservices architectures. These architectures have become the basic building blocks for complex and reliable distributed web and mobile applications. Many of these distributed APIs expose the business logic directly over the web; hence the attack surface and attack vectors are very different for these next generation applications. These next-generation applications demand next-generation application security solutions that need to stitch together a distributed application’s activity using techniques such as distributed tracing and then use next generation ML techniques to solve important application security problems.

    Proactive anomaly detection

    Anomaly detection approaches are a practical way to discover unseen strategies of attackers. However, these approaches are prone to very high false positive rates, thereby defeating their very purpose. Most anomaly detection systems flood analysts with false alarms resulting in a cognitive fatigue. Traditionally, the pitfalls of anomaly detection approaches have been addressed via false-positive workflows, better user interfaces and user experience tools. Analyst feedback is taken as a reinforcement on the algorithm and the algorithm tunes itself. However, the engineering cost of such an approach is very high and the product gets very complex leading to reliability and flexibility issues. Secondly, it still requires analysts in the loop to tune the back-end algorithms. Most practitioners think the issue lies with the anomaly detection algorithms, but in reality there is nothing much that the underlying mathematics powering these algorithms can really do in a cyber security setting. These very algorithms have been proven in domains other than cyber security.  At Traceable, we believe that the problem lies elsewhere. Our understanding of the nature of data shows that we need to support anomaly detection algorithms with something else. We need to marry specific application security nuances with the mathematics powering these anomaly detection algorithms. This understanding led us to build TraceAI.

    TraceAI and API

    TraceAI is the core engine that powers the application security functions of the Traceable Security Portfolio. The foundational principles behind TraceAI are:

    • To be able to dissect the AppSec requirement into the constituent entities that are root causes for application vulnerability
    • To be able to holistically observe the interaction behavior among these entities
    • To be able to discover anomalous patterns in this  behavior

    Using these guiding principles TraceAI implements a complex behavioral anomaly detector. To power this behavioral anomaly detector, we have identified five entities that interact with one another to result in security vulnerabilities. They are:

    • APIs – the basic building blocks of the distributed applications
    • API interaction – how these APIs are wired in order to provide the intended functionality
    • Actors – users, IP addresses or client-side applications such as mobile apps that use APIs to benefit from the intended functionality or in a malicious case, subvert the intended functionality. The actors may be assigned different roles such as admins, clients, managers etc…
    • API Data – inputs from actors required for the APIs to come to life. Outputs from APIs in response to the input.
    • Resources – back-end data or compute functionality requested by actors by calling APIs

    TraceAI combines APIs, API interaction, API data, resources and actors holistically to build an actor-centric and API-centric behavioral anomaly product. As a result, common behaviors, outlier behaviors, automaton behaviors (bots), and attack behaviors are discovered from trace data. These behaviors are API-centric as well as Actor-centric.

    False positives are eliminated by introducing additional security concepts commonly referred to as Trust-and-Risk models. TraceAI automatically identifies API risk and Actor-trust by observing data relative to a baseline which is again automatically built. The baseline in itself is not a piecemeal integration of various unconnected baselines, but is a holistic combination of various observations modeled using modern machine learning tools. We do not need teams of data scientists and security engineers to support the system as the underlying algorithms automatically learn from data. Once in production, the algorithms run in a self-drive mode, automatically building baselines and generating ML models.

    Machine learning algorithms under the hood

    The foundation of any machine learning is the depth and breadth of the dataset relative to the number of features used for detection purposes. Traceable agents, deployed inside your application, API gateways, and Kubernetes cluster, automatically collect all the necessary data and build distributed traces that form the data-layer foundation for TraceAI. Traces are continuously collected to become a learning set on logic and data flow from Edge APIs, to internal APIs to backends and third party services and thus generate the features that represent the application context. Having addressed the data challenge via the tracing platform our next challenge was to choose appropriate machine learning technology.

    The biggest challenge for machine learning in cybersecurity is having to deal with high-dimensional categorical data of sequential nature, combined with the need for explainability, causality, and attribution. Because the attackers’ strategy constantly changes, supervised learning has its limitations. Most popular ML algorithms fail miserably while simultaneously dealing with these two requirements. Taking these factors into account, we have engineered ML-based solutions by building algorithms ground-up (instead of fully relying on libraries) and adopting a self-supervised learning framework. Our unique way of representing multidimensional categorical information allows us to perform ML-based detection even on certain forms of encrypted data as well.

    A key component of the ML-based solution is the ability to discover the API endpoints, and to automatically generate the API spec via data analysis. As a result the expected request/response headers, body parameters and query parameters are not only identified, but are also characterized. This helps build the API spec, violations to which are flagged as anomalies. This completely automated process without the need for manually annotated data is feasible owing to the richness of data captured by the core distributed tracing platform.

    Complementing the ability to detect API data anomalies, TraceAI also detects anomalies in API interaction, and anomalies in users accessing these APIs. The User Behavior and Business Logic representation modules capture, represent and build baselines for regular user behavior and expected business logic. Unsupervised ML techniques are employed because these techniques are the only scalable alternatives. Once the baseline models are built, business logic abuse and behavior deviations are captured and surfaced as alerts.

    Extending behavioral anomaly detection to predictive threat detection, TraceAI introduces a novel exploratory learning paradigm for API security. This approach harnesses the fundamental principles behind reinforcement learning, adapted uniquely to application and user behavior representation. Using such an approach, we are able to generate potential anomalous patterns even before they occur. By comparing users’ activities against these generated patterns, we can identify users who are beginning to tread on a dangerous path. Hence, we can flag these users even before a full-blown attack is launched. As a byproduct, we are also able to quantify known and risky behaviors without manual intervention. Some of the machine learning techniques that we have used in order to power TraceAI are MinHash based embeddings, hierarchical user behavior clustering using LSH and OLAP-style sub-clustering, Bi-Directional RNN variants for time-series anomaly detection, and use of random walks with evolutionary algorithms for explorative learning.

    Anomalies in user behavior in the context of business logic

    Understanding application behavior and user behavior helps in:

    • Identifying violations to known user behaviors
    • Discovering novel behaviors
    • Grouping users based on their behaviors to create user cohorts
    • Determining how exactly APIs are being used in order to build a web application

    One can represent user cohort behavior as a summarized flow-graph as shown below.

    sample application flow
    Sample application flow.

    Each node in the graph represents an API that was called during an active user’s session. Two  nodes are connected if there is a transition from one API to another, and the flow between two nodes represents various statistics such as how many users exhibit such a transition or how often such a transition occurs across user sessions and so on.

    In the above figure, there are around 26 different nodes, each representing an API, and the flows connecting these nodes indicate paths of API access  based on monitoring users’ API call graphs. For a human analyst, this map is very difficult to comprehend and more so to detect that a particular user’s behavior has changed compared to other users’ behavior or to detect that a particular user’s behavior has changed compared to a baseline. Only machine learning algorithms can automatically interpret these kinds of representations and that too at the scale that we have to deal with.

    Behavioral clusters

    The figure above shows how TraceAI was able to create user behavior groups based on the pattern of API access. In essence TraceAI has peered into the complex flow graph shown above and then identified groups of users based on their respective API call flow behavior. The gray circles represent users who fall under commonly occurring behavior groups. These groups are low priority for an analyst as they are population characteristics. The red circle-A represents a user whose behavior is very similar to the gray circle-B. This means the user in circle-A is accessing the same APIs as users in  circle-B but managed to attack one or more APIs.  This further implies that the user in circle-A is following the same business logic as many other users but has managed to compromise one or more APIs. This is interesting information for an analyst, because one can now understand what led to the compromise in addition to knowing what was compromised.

    Tracking user behavior to detect API attacks

    Here, the figure above shows the user’s behavior and where exactly the attacks took place. There were authorization bypasses detected in two of the APIs (nodes) colored in red. The analyst now knows where the attack took place and how they got to this stage. The APIs leading up to the attacked API can now be analyzed for security vulnerabilities and code design flaws. In essence TraceAI has isolated and surfaced interesting behaviors from many possible behaviors so that security analysts can investigate further. By cutting down on possible candidates, TraceAI has reduced cognitive load and investigation fatigue by many orders of magnitude. TraceAI can also detect outlier behavior to flag groups of users who are not explicitly responsible for a known attacks, but are exhibiting suspicious behavior and not being like the rest of the users. Analysts can also dig into the outlier groups shown as “blue” circles, analyze few of these users, and then as a batch put all these users under a watch list. By working at the level of a group, multiple users can be tagged/flagged/watched without having to deal with each user separately.

    Summary

    Traceable combines the power of Distributed Tracing and TraceAI technologies to protect next generation attacks on Web Applications and APIs. By choosing the right machine learning technology, and focusing on addressing API security issues Traceable is pushing the boundaries of API security.

    We would love to talk to you further and demonstrate how our technology addresses API security issues in your environments.

  • Safeguarding Composable Architecture Applications Based on API-enabled Components

    Safeguarding Composable Architecture Applications Based on API-enabled Components

    The use of composable methodologies for application development is growing rapidly. The reason: It offers many benefits that speed the development process and opens up application creation to developers of all skill levels. However, the speed and ease-of-use benefits, via the reuse of pre-built components, can introduce new security risks that traditional security management solutions might not be able to handle.

    The rising interest and adoption of composable architecture seems to be a matter of the right approach at the right time. Businesses today are under great pressure to innovate, transform, and offer new products and services. The pressure is coming from both inside organizations and from customers. Those within need applications, tools, and services to increase productivity, boost efficiencies, and cut costs. Customers want fast service, improved engagement, and quick responses to any queries and questions.

    A composable approach to application development helps businesses deliver the needed solutions at the pace of modern business change. It accomplishes this by using composable entities that offer self-contained business capabilities. These elements make use of APIs and can be assembled and combined into larger applications.

    Bolstered by other industry trends

    Another reason for the popularity of composable application development is that it is a good match and complements other application development trends.

    For example, its usefulness is enhanced by low-code/no-code development methods. Low-code/no-code saw great adoption during the pandemic. Businesses realized they needed to be more responsive to fast marketing changes, and their at-home workforce needed easy-to-use solutions.

    The surge in their use continues this year. The low code development technologies market is projected to grow by 23% this year over last.

    Many of the reasons companies cite for moving to low code are similar to why they use composable application architectures.

    Namely, professional developers work faster, and they can spend more time on higher-level development problems. And both low code and composable methodologies let individuals and business groups with limited or no development expertise create their own powerful applications.

    So, in many ways, the two technologies go hand-in-hand in many organizations.

    Similarly, many of the underlying rationale and principles for using composability align with the other cloud-native methodologies. Specifically, with a cloud-native approach, applications are broken into loosely coupled microservices and container elements that are then assembled into a larger application. Specific elements in a cloud-native application, such as a front-end application or a business process, can be standardized and made available as a composable component in a cloud-native application.

    What’s needed for security?

    Enabling development using composable elements centers on APIs. Specifically, with respect to composability, Gartner notes that businesses “seeking to kick-start efforts to turn an organization into a composable business” should:

    • Enforce composable application design by ensuring application development teams use available external and internal API products
    • Educate teams about how to exploit existing applications and platforms for composability by using application APIs and low-code development and integration platforms.

    Hence, security efforts must change from traditional approaches to ones that are more API-centric. Solutions must observe all user activity and API interactions, then act on unexpected user and API behaviors.

    Solutions that address composable application security must offer infrastructure, services, and code-level threat analysis in a single platform to facilitate collaboration and expedite threat resolution to meet the needs of modern DevSecOps approaches to application development and security.

    Such capabilities are critical given the complexity of modern cloud-native applications. In many cases, when creating applications with composable elements, hidden inter-dependencies can arise. Traditional security solutions often will not be able to detect such issues or trace the source of problems down to the composable element level.

    Furthermore, while each element of an application may be secure, the interplay between the composable elements and the data exchanged between them can introduce risks that need a more API-centric solution which understands the greater application context.