Radware Ltd. (RDWR) Earnings Call Transcript & Summary

Migrating to the cloud is no longer a forward-looking trend. It's now the industry mainstream. According to Radware's own research, about 70% of production applications now run in the public cloud. This means that organizations need not only to protect their cloud applications, but also must take into consideration the special characteristics of public cloud environments and the security challenges that they pose. The purpose of this webinar is to discuss some of the unique security threats of public cloud environments and how to deal with them. Hi, everyone, and welcome to the special Radware webcast. My name is Eyal Arazi. I'm a Product Marketing Manager for Public Cloud Security here at Radware. Cloud security is obviously a very big topic, and so we can only cover a number of specific topics today, which are on the screen in front of you. Note that I've listed not just the topics, but also a rough estimate of how much time they should take. This is so that you, as an audience, have an idea of what you're facing. So first, we're going to start with the discussion of the challenges of securing cloud environments and why it's so different than on-prem. We'll cover that in a pretty high level, so that should take around 5 minutes. Next, we'll move to a discussion of a number of specific threats to public cloud environments, which are either unique to the cloud or are simply just that much more dangerous in the world of the cloud, which should take about 10 minutes or so. Then we'll spend just a few minutes touching on Radware's own solution for cloud security and how it helps customers address these problems. And we also have a customer, who will join us today, to briefly talk about their own experience before we move into the Q&A section. So overall, we should be looking at about 30 minutes before we move into Q&A. And at the end of this discussion, we will have a dedicated Q&A segment open to the audience. So please stick with us. So before we begin, just a few notes of housekeeping. Number one, a copy of this webcast will be sent to your e-mail for on-demand view. You will receive a copy of this presentation once the webinar is over. So once the webinar is done, a copy with a link to an on-demand view will be sent your e-mail. This usually happens in the -- within a few hours, which you can review all or part of the presentation, share with colleagues and so on and so forth. So that's one. Secondly, as we mentioned, there's going to be a Q&A segment at the end of the presentation. So ask me questions. Ultimately, this presentation is here for you. There's a question box at the bottom of your screen. So if you have a question about anything as we go along, feel free to write them in, and I'll try to address some of them during the presentation. But in any case, again, there's a dedicated Q&A section in the end. So feel free to write questions as we go along or when we get to the end. So let's begin with a brief discussion of some of the challenges to security of public cloud environments. So if you're watching this webcast, it should come as no surprise to you that cloud computing is now the norm. What surprised us, however, is how much so? Radware recently released its 2021 global application security report, which centered a lot on the cloud. And according to our findings, about 70% of production applications now run in public cloud environments. Now mind you that on-prem still isn't going anywhere. Many organizations still use on-prem environments. But what we found is that it is usually for testing and once the application is released off to production, it is from a cloud platform. So there's a discrepancy there. Over about 57% of organizations also deploy containerized applications, which are frequently used in conjunction with cloud environments and also need their own type of protection. And finally, about 90% of organizations, surveyed in this report, said they experienced attacks on their applications in 2020. So the takeaway from this last statistic is about the importance of application security. But we must remember that since now most applications run into cloud, this means -- versus the production ones, this means we must take into consideration the unique threats and characteristics of cloud environments and make sure that we have those covered. So let's look at some of the risks of running in the cloud. So there is no better way to illustrate these challenges than taking a use case, a case study, of a large organization running in the cloud, which experienced a major data breach and the results and the lessons that we can take away from it. Now this case study is a global leading bank, which operated in AWS. This is a large organization with a large number of experienced IT and security staff, and yet they still got breached. So let's look at a high level, very high level, of the screen in front of you. So as a first step, the attacker used the automated bot network to scan multiple targets, not just this bank, and identify vulnerability. Now in this case, the attacker used the bots to scan the bank's AWS cloud network and identify weak spots. So that's the first step. The attacker also used an application level of server side request forgery or SSRF attack to target one of the bank's external facing servers. We'll talk about this in more detail later, but that an SSRF attack is an established and well-known attack vector, aimed at tricking the target into making forged requests on behalf of the attacker. Now although this is a well-known attack vector, it is particularly potent in public cloud environments. So that allowed them to get into the cloud network and once they have that, in step 3, the attacker used the stolen server credentials to query the AWS metadata service, which, in short, contains all the roles and permissions of the cloud account, which the attackers then extracted outside of the network. Now once they have the machine role credentials in hand, the attacker used it to penetrate the network, scan it from within, identify sensitive resources and extract data from them, which included a large portion of the bank's customer data. Now note that some -- that while some of these attacks -- attack steps are on the external application service, specifically the bot scan and the SSRF attack, other steps exploited the security vulnerabilities of the application infrastructure of the public cloud environment. So talking about why did this happen, there are a number of key steps to consider. So first of all, the victim's perimeter defenses, such as their WAF, anti-bot, anti-DDoS and so on, did not identify the malicious traffic and block it. That is on the outside, on the application layer. However, once inside within the public cloud environment, the machine role had too many permissions, which it did not actually need. And in addition, untypical suspicious behavior of this machine was not detected or alerted in the cloud network. And finally, there was no correlation of application context and alert across multiple threat surfaces to identify an attack across multiple levels, attack surfaces in time periods. So this is just 1 example of one victim, which suffered an attack, but it goes to illustrate some of the vulnerabilities that exist in this environment and how they can affect almost any type of customer. So let's look next at the lessons to be learned. So there are a number of key lessons to be learned from this incident. First of all, public cloud threats are different. Now there were a number of attack vectors in this case, that possibly would not be -- have been as critical in a physical on-prem environment, but became much more potent in a cloud environment. So an example of that is the SSRF attack, again, as we mentioned, a well-known application attack vector. However, it is not in the OS top 10, which is probably the reason why security rules against this type of attack were not activated in the bank's web application firewall or WAF. However, and again, we'll talk about this a little bit later, in a cloud environment, this is a much more potent attack, which as a result, enabled the attacker to exploit the cloud environment's access permission, permissions to query the resources and kind of became sort of a flame within an all oxygen environment. Likewise, the issue of permission management becomes much more important in a cloud environment. Again, we'll talk about this later. And as a result, we must recognize that moving to a cloud environment doesn't necessarily make your data more or less secure, but rather that the threats facing you are different and must be met with dedicated defenses for the cloud. So that's lesson 1. The second lesson to be learned is that you must cover all direct services. Again, as the speech illustrates, vulnerabilities kind of correct multiple layers, either in the application surface or within your network, which combined, can result in a breach. Looking here, the attack started on 1 hand on the application surface of the external facing application, but then continued in the internal network and kind of exploited some inherent vulnerabilities there. So again, this illustrates the importance of safeguarding both the internal public infrastructure as well as the outside. Now the final lesson to be learned is that while detection is important, correlation of malicious activities is critical. Security admins today [indiscernible] a flood of security events. It is not uncommon for applications to generate thousands or even hundreds of thousands of logs each day. And when you have such a flood of events, really, you don't have the time to analyze each events individually and understand its meaning. It also means that medium priority, but highly indicative events such as connaissance, unusual operations, permission misuse and so on, often get buried under the noise. Now this is why simple logging is not enough, rather organizations have to deploy automated tools that don't just log, but to correlate security events and construct them into sort of unified attack story line to show you that event A is related to event B, related to event C and all of which lead to a breach. And only this way can security staff really identify activity and stop it in time. So moving ahead next, let's look at some of the critical threats in the public cloud. Now it's important to emphasize that most of the threats facing apps on-prem are just as relevant in the world of the cloud and vice versa. After all, a data breach is -- a data breach, really no matter where it occurs. However, because of the unique characteristics of the public cloud, there are many types of attacks that are more harmful and more impactful in the cloud, and it is therefore critical to make sure that you protect specifically against those vectors. So let's have a look at some of them. The first attack vector to talk about is server-side request forgery or SSRF, which we mentioned earlier. As we said, SSRF is a very well-known and established attack vector. However, for many years, it was kind of in the background of application security. And in fact, is not part of the OS top 10 list of most critical application vulnerabilities. However, in the cloud, it is a much more dangerous and potent attack. Now why is that? So SSRF attacks let attackers send requests to resources that sit behind the back end server, the back end of vulnerable web applications. It's usually targeting resources that are not typically accessible from the outside. So therefore, the SSRF attack kind of piggybacks on a vulnerable host. Criminals usually use SSRF attacks to target internal systems that are behind firewalls and not accessible from the external network. Now in a typical on-prem environment, the damage that can be done by such an attack is limited, since on-prem servers are frequently self-contained and do not share access credentials with other servers. However, as we mentioned, in a typical cloud environment, workloads and resources routinely communicate with each other via APIs, system calls and so on, using common roles and privileges across the entire environment. Therefore, if you're able to leverage those credentials just as an SSRF attack allows you to do, then it becomes a much more potent attack, because all of a sudden, you can do a lot more with those credentials. So this is just 1 example of an attack or a tuck-in attack rather, that is relevant whether you're in cloud or on-prem, but it's simply just that much more dangerous in the cloud, because of the specific characteristics of an architecture of public cloud environments. The next vector to talk about is API attacks. Again, API vulnerabilities are relevant no matter where you are, on-prem or into cloud. But because of its heavy reliance in cloud applications on APIs, again it becomes a much more potent attack vector. Now looking at some of the staff again from Radware's 2021 global application security reports, 55% of organizations consider API security as a top priority for 2021. And 84%, this is a ridiculously high number, of organizations experienced API attacks in 2020. So clearly, a very important vector to protect against. So let's look at that in a bit more detail. So APIs are, in fact, exposed to a large set of attacks. Looking on the left side of the slide, you can see that there can be many types of attacks and manipulations, which can be invoked against APIs, which require different types of protection. So you can have bot attacks, which require bot protection and dual location policies. Protocol attacks targeting TCP termination and HTTP and HTTPS parsing, access violations, irregular expression in parenteral manipulation, injections, exploitations, and so on. So as you can see, this is a very wide spread surface that requires specific attention and protection against those specific attack vectors. Another key threat vector in the cloud is crypto mining. Again, crypto mining can occur anywhere, but it is particularly potent in the cloud. And this is because of the large-scale instances that are so easy to spin up in cloud environments and the cost that is borne directly by the customer. The attacker just has to collect the bitcoin, without having to spend any money or effort on provisioning the computing power. It just basically leaves the customer to foot the bill. Now from the point of view of the attacker, if they're able to penetrate the customer network and install crypto mining software, it is actually a much easier way of making money, because it doesn't require going in, looking for data, exploiting the network, which can take a very long time, and then selling it on the dark net, but simply just making money straight up by using the victim's own computing resources and having them pay for it. So again, this is something that we see quite a lot from customers in the cloud, and again, a major source of concern for public cloud environments. So finally, I want to talk briefly about the issue of excessive permissions. Again, permission access and management is a critical IT security topic, no matter where you're hosted. But again, the cloud makes it particularly a problem. And why is that? So this is because that migration to the cloud to begin with is frequently driven by the desire for more agility and flexibility. As we talked about, the cloud makes it incredibly easy to spin up new resources, spin down new resources, deploy new code and accelerate the development process, which ultimately leads to faster time to market and faster time to push new features to customers. The problem, however, is that in the name of expediency, cloud administrators frequently hand out wide-ranging and unnecessary permissions and privileges for which there is no business need. Now this is done with good intention in the desire to make sure that everyone has all the access permissions that they need to go up about their business, not get into way, not going to slow down any development processes, but along the way, they create a huge security gap. Because if those permissions should ever fall into the wrong hands, they could result in incredible amounts of damage if they are misused. So this is why permission management and specifically eliminating excessive permissions is particularly a problem in the cloud and a source of concern to a lot of cloud users. So now that we've reviewed some of the key threat vectors, which are particularly dangerous and potent in the cloud, I would like to spend a few minutes talking briefly on how Radware protects against these threats. Radware is a cloud-native protector, provides capabilities to detect sophisticated attacks using advanced AI and machine learning algorithms. Radware detects suspicious activities in cloud environment by continuously monitoring for malicious behavior indicators or MBIs and an example of such MBIs can be accessing the network at an unusual time, accessing the network from an unusual location, first time identification on API calls, accessing sensitive resources, and so on and so forth. So this helps with the detection piece. The problem, however, is that almost every behavior by itself can have legitimate explanation to it. So for example, a user might be working away from home, or accessing the system in unusual hours or maybe they're on vacation and accessing it from a different country than usual, or maybe, in fact, they do need a new API call as part of their job. So just analyzing an event by looking at just 1 activity is very difficult. So this slide, Radware also correlates individual events into unified attack storyline. Radware's Cloud Native Protector uses advanced machine learning algorithms to identify relations between different activities and to create unified attack storylines, which show the step-by-step progression of attacks. Also an example of such a storyline is shown on the slide in front of you, demonstrating an orchestrated attack progression and the affected resources. This capability is crucial for identifying attacks. So as a result of these capabilities, we are able to provide actionable correlated insights, which show you how different events are correlated, whereas relying on legacy detection and monitoring tools, results in log overload with separate stand-alone logs, which quite frankly are lost in the noise. Now in addition, our Radware's Cloud Native Protector uses a unique approach to identifying excessive permissions and misconfiguration. So whereas most solutions compare configurations to statistic list of best practices, Radware analyzes the gap between defined permissions, that is the permissions that are allowed under different policies and used permissions. So the permissions that are actually used by users. So this allows for context ware of smart hardening, which is based on actual usage patterns. Now based on this gap analysis, Radware then applies the principle of these privileges to notify administrators of unused permissions, which might be exploited by attackers if the account ever becomes a compromise. So this helps reduce the organization's attack surface and fortify its cloud security posture against vulnerabilities. So you can see on the screen in front of you, a bit of an explanation of the gap between defined and used permissions and kind of drill down on some of the ways how Radware protects you with actionable with automated risk prioritized detection of permissions, detailed warning and context and elaboration, and easy to understand actionable recommendations. So just to demonstrate customer satisfaction with Radware's WAF vector protection product, we can see how many of Radware's customers have provided Gartner with a 5-star review of Radware's Cloud Native Protector. Again, this shows how customers are satisfied with their line of products and enjoy ease of use and security capabilities. So to talk about how Radware's protection helped customer in real life, we have with us today, Ofer Levi from Perion Network. Perion is a global leader in online advertising platforms, and Ofer is a technical lead in the company's DevOps team responsible for infrastructure and security across Perion's public cloud environments. So Ofer, first of all, thank you for joining us today. So can you give us a bit of background on the company, the challenges you're facing? And how Radware has helped you?

Hi, everyone. I'm Ofer, Tech Lead in the DevOps team in Perion and managing the security project that we promote. So what Perion does? Perion Network delivers advertising solutions to brands, agencies and publishers all over the world. Perion provides content monetization platform, search monetization solutions, actionable performance monitoring platform, and cross-channel social software as a service platform. To develop those services, Perion's divided into business units. Each business unit has its own R&D team and development environment, which runs on Amazon Cloud. Most of the services are running on dockers and on Kubernetes clusters. We also use various AWS services to complete the application needs in the meaning of networking, compute, storage, databases and big data, and for security, of course. Along with that, we also have third-party services to help us manage the accounts financially and to secure them. Key challenges in the cloud. Perion is rapidly growing, and currently, we have more than 30 AWS accounts, which we must manage and secure. Rapidly growing environment technologies that Perion acquired in the last few years and moving from on-prem to the cloud, created new challenges for us as DevOps. The constant growth in asset inventory, new users and new services brought new challenges in meaning of management, cost and security. In Perion, each R&D team in each business unit is responsible for its cloud environment and services that's running on it by means of resources and budget. The DevOps team built the deployment pipeline to enable deployment automation, and we also need to be able to monitor and control X permission across the accounts and to identify anomaly activities. DevOps also set security policies to be as much as possible compliance with AWS security best practices, setting permission should be done without interfering in the business activities. So we need smart hardening system to assist us tracking the accounts logs activities. We also need a system to support us, protect against malicious activities in the cloud environment and also to alert us if such activity is identified. I will give some examples for security needs that we worked on the cloud. We moved from keys to walls. We moved from users that were using keys on the local desktop to use Okta authentication with MFA and for services, we changed the use of keys in configuration file to roles on EC2 or directly on the container. Also, managing resources identify -- we want to identify the usage of compute resources, especially for large types and regions that we are not supporting. So how Radware has helped us? Radware helped us identify misconfiguration and reduced excessive permissions while detecting breaches, providing superior breach detection capabilities. It also delivered breach alerts without generating false positives. Although Radware detected many anomalies during our testing period, it only alerted us when it garnered enough evidence for a possible breach. The system can also be customized via the settings option, where we can configure the severity of all of a rule for our needs or create custom bundles with specific rules that we want to identify. So for the example, I gave before, we created custom bundles to identify and alert us when new user is created on the AWS and other bundle to alert on large EC2 creations or EC2 that was created on regions that we are not supporting. The Cloud Native Protector has a well document API on how to do it. It also provides actionable misconfiguration alerts. Cloud Native Protector only alerts when an actual configuration issue is detected that risks exposing workloads. We integrated the system with a pager duty, our incident management tool, so we will get notified by the application or by a phone call. Radware's support, Radware provides exceptional support during the testing and the implementation of our environment. Cloud Native Protector is an easy to deploy with only a few steps to onboard new accounts and no need to install additional software or application in AWS account.

Thank you, Ofer, for your detailed explanation about your environment and how Radware has helped you to secure it. We really appreciate your trust as well as your willingness to participate on this webcast. So before we move to the Q&A segment, I'd like to review just for a minute on Radware's approach to public cloud protection. So Radware provides a 360-degree protection for cloud applications. We do so by protecting both the application surface as well as the public cloud application infrastructure that sits behind it. We do so with cross cloud protection for AWS, Azure, private cloud, hybrid cloud, anything on-prem as well as a single provider with a single technology stack across the board with multiple delivery options either as a SaaS-managed service or through our customer managed virtual appliances, which can fit any customer environment or architecture or use case. And we provide kind of a single pane of glass with centralized management, visibility, kind of support and a single throat to choke. Now what makes Radware unique is that it is the only security provider currently, which provides protection for all facets of public cloud applications, both external, for the application surface and internal for the cloud application infrastructure. So on the application surface, we protect -- we help customers protect against application hacking and vulnerabilities, [indiscernible] DDoS, bot attacks and manipulation, API abuse and so on, whereas on the cloud application infrastructure side, we help them protect against accidental public exposure of assets, of cloud security misconfigurations, of approval privilege escalation, malicious abuse of credentials, and suspicious behavior within the cloud environment and so on. And again, we are the only security vendor in the market, which really provides comprehensive protection across all attack surfaces. So just for 1 last slide before we move to the Q&A, touching on the actual products that we deliver to help achieve these protections. For the application surface protection, we provide a WAF, which can be deployed in multiple deployment options, either the cloud WAF or virtual instance or even a Kubernetes addition, bot manager, which can be deployed either as a SaaS service or with local installation, API protection, DDoS and DDoS protection. Whereas for protection of cloud application infrastructure, we have our Cloud Native Protector or CNP, as we sometimes call it for short, which we talked about earlier in this presentation with key capabilities for a Cloud Security Posture Management or CSPM, Cloud Infrastructure Entitlement Management, or CIEM, which is how we address the problem of excessive permissions, cloud threat detection and response to actively detect malicious activity within your cloud environment and across cloud visibility and reporting to cover all of your accounts across multiple cloud environments. So let's open the floor now to questions from the audience. I saw during the presentation that a number of you have already written in some questions, which I'll begin to address now, but feel free to write any additional questions that you have in the Q&A box in the screen in front of you.

Okay. So 1 question that has come up is you talked about the application surface versus cloud infrastructure and why specifically these vectors? So this is actually a fair question. Ultimately, there is a very wide set of threat surfaces out there and a lot of different defenses for very different types of attacks. Just off the top of my mind, for example, CASB, you can go with VPNs for securing the remote connection. So why specifically the application surface and the cloud infrastructure. So the reason for this is that at Radware, we take an application-centric view for security. So we look at security -- at the application, sorry, and we try to understand where are the largest threats to it. So when we look at it, you can either have attacks coming from outside through the application in what we call the surface, the external facing side of the application or you can have attacks coming from the inside by attacking the back end of the application, which in cloud environment is hosted out on the cloud and through that to steal and extract data. So this is why we take kind of this long view of both sides, the external application surface and the internal infrastructure of the back end of the application, which in a cloud environment is really also external. And therefore, we feel you need to put the emphasis on securing specifically those 2 vectors. So we have another question here coming up. What router products do you have to cover these protections and these attacks that you talked about? So again, we covered this briefly in the presentation. I think it's 1 of the last slides. So again, looking at that kind of a dual view of the application, the external attack surface and the back end infrastructure. So we have 2 families of products to protect each of them. So for the external application surface, the perimeter protection, we have WAF. We have DDoS protection. We have a bot mitigation and management, and we have our new API protection feature. Now each of those can be provisioned either as a cloud SaaS service or can also be deployed as a locally managed virtual appliance within the customer's cloud network. There are pros and cons for each of these approaches. And it really depends on what the customer is looking for, what's important to them and their specific use case. So that is for the application surface for the -- for blocking external traffic and bad traffic from coming into your network. On the other side -- on the other end, we have, as we said, our cloud infrastructure protection. For that, we have our Cloud Native Protector, which includes within it a very wide set of capabilities for cloud security posture management, for cloud infrastructure entitlement management, for cloud threat detection and response, for cross side visibility and so on. And the purpose of our Cloud Native Protector is to protect your cloud infrastructure against either accidental exposure or malicious attack. So with the combination of these 2, it gives you kind of 360-degree protection for your cloud application. So there's another question here about the benefits of taking a unified solution from a single vendor versus kind of taking best-of-breed point solutions from multiple vendors. So there are a number of advantages for taking a unified cloud solution such as Radware over point solutions. One has to do with cross cloud visibility and making sure that with a single product, you can cover all of your infrastructure, whether it's running in the public cloud or in the hybrid cloud or even on-prem and making sure that you have all of your bases covered. The second has to do with consistent and unified security protection across multiple levels. In our experience, if you take point solutions, a lot of times, not only are they going to give you incomplete coverage of environments and platforms, as we mentioned, but also what you're going to end up with are inconsistent levels of protection and different policies between different solutions that you are running. So making sure that you have a single technology stack, making sure that you have advanced protection based on positive security across all of your different protections. These are all very important. And finally, another prime advantage for taking a unified solution over point solution is shared intelligence and contacts, making sure that all of the information coming across all of the -- from all of your threat surfaces, gets funneled into a single place, correlated with multi vector protection, detailed threat reporting, shared threat intelligence team and so on. So again, this is an advantage for taking the unified approach. So we're coming up on the top of the hour, and we want to be cognizant and respectful of everyone's time and making sure that you make it in time to your next meeting. So I'm going to take here just 1 last question. So there is a question here that came up from a number of people. How can I get a copy of this presentation? So again, as we mentioned, once this live webcast is over, a copy with a link for on-demand view will be sent to you to your email. This usually happens pretty shortly after the presentation, usually within a couple of hours. And you can use that link either to view the presentation again, share it with a colleague, and so on and so forth. And of course, if you have any further questions, feel free. Certainly, we encourage you to reach out to your local Radware representative, whether it's a salesperson or a customer success manager, Radware partners and so on and so forth, or feel free to reach out directly to us with any questions that are yet unanswered. So again, want to be respectful of everyone's time. So I'm going to cut it off here. I know there are a number of questions that we were not able to get to. So we will follow-up with you directly. But for everyone else, in the meantime, thank you so much for attending this webcast. We hope that you enjoyed it, and you found it useful and educational. And we certainly appreciate your time, and we hope to see you in a future webinar event. So thank you, and have a great rest of the day. Bye-bye.