Beyond Firewalls: Proactive DDoS Defense for a Stronger Cybersecurity Posture

Hello, everyone. Welcome to our webinar today. My name is Osman Celik.

Today, I am with Andrey Leskin from Qrator Labs and Andy Shoemaker from NimbusDDOS. And, yeah, actually today, it's a very sunny day today. So sorry if I have some reflections, but I'm glad that spring is over here. And I don't know where you're located, but I'm hoping that all of you are having a good time. And before we start, we have to do some housekeeping first. So you are muted. Unfortunately, you cannot participate in a conversation with us. This is not an option yet, but we offer some options to interact with us.

And if you go and see the menu in the right-hand side down below, then you will see the options, the links, people, polls, and questions, and also the chat buttons. So if you have any questions, you can use the chat. And questions, you can also use to ask us questions directly. That's going to give us quicker access. And also throughout the webinar, we prepared two poll questions for you that we will share the results with you at the end. So if you wish to participate, please use that button and please answer our questions. And then we might as well also discuss the outcomes of it.

And the slides will be recorded, so you don't have to worry about it. And then it will be available for you to download later on.

All right, so the agenda is I'm going to cover some side of DDoS protection from my point of view, from Kubinger Call's point of view. I've recently worked on a report. I'm going to share my findings also and why DDoS matters to you. And then Andrei and Andy will also do their parts, layers of DDoS attacks and why DDoS testing, which is our main topic today. And at the end, approximately 10 to 15 minutes, we will dedicate for your questions and also for some kind of panel discussion, let's say.

So the first question, first poll question is, does your organization have a DDoS protection in place today? The options are actively deployed. You are in the evaluation proof of concept phase or no. I give you 10 seconds to answer to that.

All right, I think that should be enough. So, as I said, around like 67 months ago, I've worked on application firewall solutions. And then one of the fundamental part of it was DDoS protection. And then I had a chance to go over and see what vendors are doing, what solutions are available in the market, and then how it's a complementary tool to the overall your cybersecurity strategy. But before going into that, I wanted to present to you what, like briefly, what is a DDoS attack and what are those layers and why we talk about them? What are actually those layers?

To be honest, before I did this research, I was not even aware of how layer one, fifth and then the sixth was called. But after that, I actually made the research about it because what I saw in the market that most solutions are actually concentrated on the layer three, layer four and layer seven attacks, which I'm sure our speakers will also elaborate on that why those matters. But what I've seen that these are the most exploited attacks in the market. And you see the common DDoS attack types. I've actually made a very small list of it. I'm sure our speakers also will agree with that.

They might maybe thinking that, oh, this is missing, this is missing. But when I made a research about common DDoS attacks, this was the list I could find that the most important one. But I am sure if you're familiar with the topic, then you might as well say that, oh, this is missing. But I totally agree with that. But to sum it up and to give a more concrete image, we can talk about three common classification of DDoS attacks. And then they are application layer attacks, which is also corresponding to the layer seven.

These attacks target the layer where web pages are generated on the server and delivered in response to HTTP requests. And what, yeah, I mean, as an example, we can already give the HTTPS slot in our common DDoS attack type lists. The second one is protocol attacks, and those are targeting layer three and four. Volumetric attacks are also targeting mainly layer three and four. And that's why I said the layer three, four and seven are the most important ones. But why do you need to have a DDoS protection and what are the challenges that makes you procure one?

We can start with talking about like evolving tactics, but I think this is not limited to DDoS protection. And we see that the attack vectors in the cyber threat landscape is increasingly getting bigger and more sophisticated. Because we see the tools like AI and ML being exploited by the cyber actors. And then now it's really difficult to come up with an overall cybersecurity strategy to defend your organization or defend your infrastructure. So the number one reason is that you have better attack TTPs. The second one is the frequency.

And that's also highly related with your bandwidth capacity or your CDN or your POPs, etc. So this is something that your vendors need to be providing for you. Because if you're left alone by yourself, then you won't be able to answer to those attacks by yourself. The third one is, again, a general cybersecurity matter. If you ask me detection and response time in any sort of cyber attacks, then you have this period where you answer to the attacks, the incidents.

And then it really determines the cost that you're receiving, the damage you are, the economic and the reputation damage you are being received. The fourth one is legacy infrastructure. This I can actually evaluate in two phases. The first one is that if you have a legacy infrastructure as a hardware or as an appliance, for example, together with your modern setups like your cloud infrastructure or your hybrid infrastructure. But if you have a device that is not supporting up-to-date systems or solutions or operating systems, then they might actually give you pain in the long run.

But in the second phase, you might have a legacy solution to deal with DDoS protection. Like, let's say, not a proper WAF or WAP, or maybe you might have a very traditional WAF, or you have IDS or IPS systems. And these sometimes are not very useful when you're combating with the modern attack types. The fifth one is always costly to be on the always-on protection, of course. The technical challenges, like I can say that real-time traffic analysis, you might want to have an NDR for this, for example.

And now the attackers are mimicking the real legitimate users, so you might as well have to have a solution to detect that. And if you have a SIEM solution, then you're probably basically bombarded with tons of logs and unrelated logs that you might need to also pick up and then find, and that you are going to deal with the overload there. I'm sure that all of you have some supply chain and third-party vendors, and there are not many solutions providing a visibility into your third-party dependencies. And the other one is, of course, the botnet diversity, which is related to the attack types.

So I'm going to share with you in the slide a couple of incidents, and that's also kind of like the reason, that's kind of like also create the baseline for why you should be careful. Because if you look at, for example, the Cedars-Sinai Medical Center, it was a hospital in the United States, and an estimated cost of this incident was around $10 million. And if you are from the healthcare industry, then you might as well think about that this can one day hit you as well.

The Steam platform, online sharing gaming platform, I mean, whatever platform that has millions of users can be even a target of DDoS attacks, and an estimated cost was around, again, $10 million. And then I'm just going to quickly go through and then talk about this Cloudflare and Google attacks. As you see that I could not really find a specific data, financial data, how much they cost for each of the, how much the damage they cost for each attack. But the numbers were around $10 to $20 million combined. And that's, again, a lot of money.

And then that's, again, something that I think we should be careful because we have lots of websites using Cloudflare and everyone's dependency on Google Cloud, for example. That's something that everyone should be concerned about. And then you see that, for example, in the Cloudflare attack, then we have seen a record-breaking attack that peaked at 5.6 terabits per second. Let's go a bit specific from now on. And I want to talk about, as a coupling call, why we see DDoS testing is something important. I have to be honest with you here.

And I'm actually glad that Andy and Andrei will share their insights on this. When I was doing my web research, I have never seen a vendor actually providing DDoS testing. Maybe I might have neglected this part of web application firewall solution or web application API protection solutions. But it was something new for me as well because I've been working on attack surface management and pentesting in the last couple of years. So I'm aware of the security testing solutions. But DDoS testing is something new and emerging as a protection against the emerging attack factors and actors.

So what are the benefits of it? You identify the weak spots before attackers. Being proactive is very fundamental to your cybersecurity strategy today. You cannot be reactive anymore. So this applies to DDoS testing as well. So you test your system before the attackers do, basically. The second one is, again, related to what I previously discussed. So you definitely have a shorter time between detection and response.

Otherwise, the cost and the financial cost and the reputational damage will not be maybe revertible. Validated incident response plans so that your teams actually can collaborate to see whether they can collaborate well enough or not. So you address the pitfalls there if they cannot really communicate and address the issues on time. The fourth one is, again, mimicking the real user side of DDoS. Because now that we have the cyber actors mimicking the real users. So you don't really know if this is the normal traffic or the attack traffic.

And you sometimes have, especially if you are working with network analysis tools. So you will see that any website can have their normal traffic and a high peak traffic throughout the day, throughout the week, throughout the month or during the year. So you know when there is a peak, but it's normal. But sometimes you might as well need to understand your patterns, your traffic patterns. And then this will also let you understand why you have, let's say, a peak at 3 a.m.,

let's say, Central European time or in the United States. These are some unexpected times, but you need to have a solution trying to give you, trying to understand the patterns. And also you need to have a better improved rate limiting, filtering and the trapping. The last one is that the DDoS testing actually controls if your infrastructure is set up properly and also validates your solutions like WAF. And also your POP servers and then the load balancers, how they perform under pressure. So a couple of more minutes and then I'm going to switch over to our guest speakers.

So this research I have actually conducted again like a half a year ago or something. This was a research actually focusing on WAF solutions. It was not only for DDoS protection, but since DDoS was one of the fundamental capabilities of WAF, one of the eight main capabilities to be exact. So actually I had a good chance to go over and see what can I share with you in terms of DDoS protection. So the first one is DDoS protection is a master feature for next generation WAF and WAF solutions. So in my research, I actually excluded most of the vendors.

I excluded many vendors that are not providing DDoS protection. There are many types of DDoS attacks. We covered it already. Most solutions provide protection and mitigation against L3, L4 and L7 DDoS attacks.

Actually, this could be a question for my speakers also at the very end. Then we can discuss why the other layers are not very much targeted or the solutions are concentrated on this. Maybe they might have a different approach than me. The fourth one is providers are investing in low latency, high bandwidth, DDoS resistant POP data centers around the world. There are some solutions actually having these data centers everywhere around the world. But of course, these are big vendors in most cases. An emerging cybersecurity strategy among vendors is API DDoS protection.

So some of the attack types are actually targeting the API endpoints. So this is also something that is new for the vendors. And then some of them actually provide protection against this. Some vendors have dedicated security teams to respond to DDoS attacks. Reporting common and emerging DDoS attacks to customers is a common practice. And DDoS testing, this is important. DDoS testing is not offered by any of the vendors I evaluated. I think this is something that Andy and Andrei would like to also talk about. All right. So this was my part. Thank you for listening to me.

And from now on, I'm going to hand over to Andrei. And we'll meet up at the end of their presentation during the Q&A. Yeah.

Hi, Andrei. You can take it over. Hi. Thank you very much. Let me overtake the stream. Yes. So I think we're ready. So my name is Andrei. I'm CTO at Curator Labs. And we provide network security, network availability to our customers. And DDoS mitigation is a part of our portfolio. So let me start with what we have on hand. Osman already gave us some headlines. And I will share some statistics that we have on our hands and encountered. So first of all, if we compare 2023 to 2024, we have doubled the amount of attacks that we saw. And in general, it's not that we see one and now we have two.

We deal with them on a daily basis. So it's hundreds of them. Looking forward, what's the scale of them? And I must say so that last year we have over one terabit attack. And it wasn't a single occurrence. And I must say it's not a rarity now. It's a reality and quite an often occasion. So be prepared for terabits. If we talk about different sectors, who are the targets of the attacks the most frequently? If we are speaking about bandwidth related attacks, financial technology sector takes like a quarter, then followed by e-commerce with 20% and media sector with 13%.

But what all of these three have in common is that your downtime translates directly to lost revenue and damaged customer support, customer's trust. So that's quite alarming. Moving forward, if we are talking about persistence of these attacks, the longest one that was last year lasted for 19 days. So you can imagine like almost three weeks of huge load for your systems and operational strain would be probably enormous.

Here, financial technology, if we are talking about application lawyer attacks, so this is the lawyers that Osman told you about. This is the same lawyers. And I will tell them, tell something about them a little bit later.

So here, financial technology sector is against the leader. Major part of the attacks were targeted towards them. And speaking of these attacks, they are usually attacks with botnets. And last year, we saw a botnet with over 200,000 devices. And like a short spoiler alert, this week we saw a botnet that like broke through 1 million devices. So this is not the end of the year. And I expect the amount of them to be larger. So given these statistics, I hope or no hope, I scared you a little bit. Let's talk about defenses. Is there silver bullet?

Because your general and natural approach would be to find something that will work perfectly, universal solution that takes care of everything here and makes all of these DDoS demons disappear. So is there any silver bullet? You might think, well, here might be yes, but I have an asterisk here. And this asterisk here is quite unimportant. So the real answer is no. Unfortunately, there is no one size fits all approach for every organization.

Well, because every network is unique. Every business has different application infrastructure components, different risk tolerances, different compliance requirements. Everything is unique. You have to address every specific business and component exclusively.

However, we have two asterisks here. So in the end, if you approach the problem with a tailored strategy, if you understand your infrastructure, if you make informed decisions about your security posture, you can probably make something that will work as your own silver bullet for DDoS and cybersecurity problems in general. So here are the keys, not to find a universal solution, but to find a solution that will work for you and develop a cohesive strategy for this. Let's think about what are DDoS attacks in general. And where are they targeted?

We have different applications and you have databases, part of infrastructure under this one. And this is an application that deploy your business functionality, maybe like a store or maybe a media site or whatever. Moving forward, these applications are located on some sort of computers. There might be clouds, maybe bare metal hardware and data centers. Even home servers might work as your maybe production environment. Who knows? But let me make an emphasis here that even when we're talking about clouds, there is no cloud. Every cloud is just someone else's computer.

Maybe there are many of them, but still these are like limited computational resources. Sometimes your money resources are exhausted faster than these computational resources, but still this is the subject to be depleted. And as its core, DDoS attack is the battle of resources. The attacker's goal here is elegant, simple and devastating. He has to overflow your resources, be they like computational power, storage capacity, bandwidth, whatever, using relatively small amount of their own resources. And this asymmetry makes DDoS attacks so attractive to all the malicious actors.

They have like minimal investment and provide you disproportional damage for your infrastructure. And here, the good mitigation service provider becomes invaluable. He increases the cost for the attacker, making the attack economically unfeasible. And they shift their resource equation back into your favor. Before we begin dealing with these attacks, let's go through their types. As Osman mentioned, there is ISO-CI model, that's layering network model with levels one to level seven.

Usually, yes, we do focus mostly on layers three, four and seven, which are application level, where all your business logic is. And layer four, here I have a mention of TCP IP, basically UDP comes here as well. But I'd like to mention here that we're talking about connections, TCP related floods, and some UDP protocols nowadays have something like connection as well. So this is a connection because UDP basically stateless, but nowadays they try to preserve the connection, even in the UDP.

And even lower, we have a bandwidth level, layer three, where we have all the amplification attacks, IP floods, that are targeted towards your network bandwidth to overflow your uplinks or whatever you have. So to deal with this, we have to research what are we trying to defend. And here we have, generally speaking, three different versions of the infrastructure. So let's try to see the evolution of a small business that we have somewhere.

For example, we have an application, we set up an online store, an eShop, a small one, and we're small entrepreneurs, we used, for example, like maybe some online platform for that. And we have a single application in the data center, in the public cloud, somewhere over the internet that serves your purpose. Maybe your vendor here has some DDoS protection already, but everything you care about are HTTP requests that handle your business functionality, your orders, your maybe customer requests, and so on.

Payments, and other related stuff. But you grow, your protection evolves, your business takes off, you evolve, and now you decide to add to this application some other services. For example, some email marketing systems. You would like to add some customer support with voice calls, so you include SAP in your infrastructure. So you set up some specialized inventory systems, maybe to track your orders, where are they, where are your couriers, and so on. So your infrastructure becomes more complex, and so has your DDoS or any other cybersecurity protection.

If you try to move forward, let's say you become a multi-regional business that has, like, quite a few years later, you process thousands of orders across the whole world, and at this scale, like, single cloud is no longer meeting all your needs. Perhaps some regulatory requirements demands, like, certain data states in specific geographic regions, or maybe cost optimization forces you to use different cloud providers for different services, or maybe reliability concerns have pushed you to establish your own data centers for your own core operations.

And given all of this landscape, the approach for them would be completely different. It becomes more complex, and given what we are trying to focus on, you have, like, from the simple HTTP application to a complete Frankenstein that is truly hybrid, multiple clouds, your own data centers, lots of different environments, and you have to somehow protect each and every component that you see there. And this is the problem for a different approach for DDoS protection. What worked for a simple application doesn't work for your Frankenstein.

And this evolutionary journey that I tried to describe illustrates perfectly why there is no, like, universal bullet. Your protection strategy has to evolve alongside with your business and your infrastructure. And let's see in details what are we talking about and what kind of threats we have to deal with this.

So, we started with a store, with a single web application somewhere on the internet. You have, like, a front door, you have HTTP requests with your web applications, and the only thing you care about is to deal with lots of HTTP requests. And sometimes it becomes an attack, DDoS attacks. We're not talking about volumetric attacks here because, generally, your provider, your data center, or your cloud provider will give you some sort of volumetric attack protection. But you have to deal with your own requests when there are an enormous amount of them.

You have the database, and the SQL database is going to load your system quite rough, and you have to ban or refuse to process malicious requests. But you have to add to that other bad guys that do not want to overflow you with requests, but they would like to steal personal data of your customers, or maybe inject something onto your site and use your server as a botnet node.

So, for that, you have to use a special mechanism called web application firewall. And this is not the end, because the last but not least part regards bots. Nowadays on the internet, bots may be good ones, may be bad ones. The good ones are, for example, Googlebot that will crawl your site and give you probably the best rank that he has in your search system. There are bad bots that will scrape your site and give all the description that you have, for example, for your goods, somewhere over the different marketplace.

Aggregators that will just steal your marketing data, and you definitely don't know who your customers are. There are sort of grayish bots nowadays, like the AI ones, like ChatGPT, Perplexity, Cloud AI, you name it, there are lots of them. And they became quite aggressive recently, we see that on our data. And you have to deal with them as well, how to respond to them making, scraping you and provide the data to your customers in their own windows.

So, generally, this is what you want to take care of as a web application owner, let's say. But you grew, you decided to add to your application other services, as I mentioned, like SAP, marketing, maybe VPN for your different offices. And now you have a different, like, evolved infrastructure.

So, you have still the same web application with the same concerns, the same risks, and add to that layer three and four services that are no longer HTTP. These are some maybe custom-made protocols, maybe stateless protocols, and you have to address the issues of volumetric attacks and deal with them somehow. Maybe some generic traffic filtering that you can maybe sort of make a regular expression for traffic and apply it on your firewall. This may work, may not work, this is kind of 50-50 situation.

There are more generic approaches like rate limiting of the flows that might not work in UDP as well because UDP is stateless and you can encounter spoofed data. There are some authorization mechanisms that you have to deal with. To ensure that your customers are the valid one, you first authorize them, authenticate them, and then you allow them to get inside your infrastructure, like the whole infrastructure.

These are all the different scenarios, but the complexity of the situation increases and you have to deal with more and more income data, income traffic, income resources, income components that you have to protect. For example, you have an ingress firewall on your own infrastructure that takes all the traffic maybe from the DDoS mitigation service or from the internet. It doesn't matter because this firewall is a bottleneck.

We quite often see the situation when our customers' networks render unavailable because their firewall, their ingress firewall, in some way died because too much traffic happens due to marketing activities. Another thing that you might want to consider here is that you have a huge infrastructure and BGP takes place there. BGP is a protocol of routing the network over the internet, how the traffic flows here, there. There are different problems, completely different problems here.

But as a DDoS mitigation service provider, I have to remind you that if you have your network and you would like to bring your old network to the provider, you have to deal with update policies of different network providers, uplink providers, I mean, that may generally take up to 24 hours to implement. Sometimes you can accelerate this, but you can't count on it. So you have to prepare in advance and you can't do it with a snap of your fingers. So each additional component adds another layer of complexity and another potential point of failure, another aspect that needs protection.

And as our evolution grows, we have now a hybrid infrastructure. So we have everything that we've mentioned, this application, all these services, all these virtual offices, virtual appliances that you have. And now it's all spread across multiple clouds, multiple vendors, and each vendor has a mitigation. The question is, if every of your vendors has a DDoS mitigation, does it mean that your system as a whole has a protection?

Well, the answer might be obvious, but the answer is no. And mitigation services might work in general, but when you deal with an attack, you will definitely encounter some false negatives, false positives. For example, this is like a tiny bit of the problems that you will encounter across multiple vendors. And you don't have a single point of truth. Information is spread across different people and organizations, and you must coordinate all of this during incident.

This creates a communication hell where your team runs around in circles back and forth and tries to fix at least something, and it doesn't work well usually. So our recommendation here is to have a single point of truth. You must ask one single vendor to coordinate protection across your entire infrastructure. And this thing only eases troubleshooting exponentially. It ensures comprehensive coverage without any gaps and provides accountability of your protection. So when something goes wrong, you definitely know exactly who to call.

And let's leave this a little bit aside, and let's think about DDoS mitigation service from a little bit different angle. So is it just a service that you acquire? Is it like a checkbox? So you're just, okay, now I have a DDoS mitigation service. Here I have a piece of paper on my wall that I have a contract with a DDoS mitigation service provider. So am I protected?

Well, in general, DDoS mitigation is a part of cybersecurity, and what I'm going to tell you here is cybersecurity approach in general. So this is definitely not a checkbox, because as we saw, your business evolves, your infrastructure evolves, and you just can't install and forget. You can't forget about your protection because something changes every time. Like a month later, you have a completely different picture. So if we think carefully about what DDoS protection is, we have to think of your business and what it consists of.

So your business evolves, and configuration, speaking from the technological side, it becomes obsolete quite fast. And people, you grow, you hire more people, and people make mistakes, unfortunately. And you have to deal with them as well.

And here, my point is that as your business is a process, the DDoS mitigation has to be a process as well. And another main point here is that this process has to be mutual. Not only the DDoS mitigation vendor has to ask you some questions. You have to go to your vendor and give him new information.

Like, for example, you have changed your infrastructure. You want to go further. You want to develop a new network.

And here, please take some measures in advance so we will deal with it later. But my colleague, Andy, will tell you more about the process aspect and how to handle these challenges effectively more.

So please, Andy, the stage is yours. Thank you very much for that, Andrei. And actually, I really like that last point that you made about it being a partnership between the mitigation vendor and the environment being protected. Because it really is a partnership in success.

So anyway, yeah, so I'm Andy Shoemaker with Nimbus DDoS. And so I want to actually take a little bit of a step back.

So, you know, a lot of times when we talk about DDoS attack threats, we often relate this directly to DDoS mitigation solutions. But this is a little bit of a too narrow of a focus. And we should really consider what it means to be DDoS prepared and think of that in a more holistic sense. And the mitigation solution, as I show on the slide, is just one element that leads to this.

And, you know, there are many other areas that work in conjunction with the DDoS mitigation solution to achieve DDoS preparedness. For example, when we talk about operational capabilities, we naturally have the mitigation solution, of course. But it's helpful to have complementary systems such as data collection and logging, detection and alerting systems. And then actually I left it off of the slide, but application performance monitoring systems, all of those things can be very helpful operationally.

And we can also see that there's similar complementary components within the areas of preparedness and incident response that help become DDoS prepared. And the point that I want to emphasize here is that mitigation is critical, but true preparedness requires you to take that step back and view the broader picture. So how do we move from our current state to a more elevated state of preparedness? This is where the DDoS preparedness lifecycle is important, and it has five major areas which are shown on this slide. The first step in our journey is to identify areas of potential risk or concern.

Now, this can take many different forms. For instance, you might have internal teams that may already have specific concerns about certain public resources. But more often, this is driven by risk analysis that's performed by cybersecurity professionals with a focus on DDoS attacks. And it's important to note that this review must be DDoS attack specific, since traditional vulnerability scans and pen testing don't actually evaluate DDoS risks, or certainly not comprehensively.

Now, once we've identified risk areas, we really need to then evaluate those risks to understand them a little bit better. And the purpose of this evaluation step is to understand what impact a DDoS attack would have on those risk areas and what gaps exist in the defenses. And normally, the way that this is done is by using formal DDoS testing. And the intent is that you use test data to confirm or reject the risks and provide additional context.

You know, because really, without actually doing a test, you're just hypothesizing is really what it boils down to. Once we move past that, we get to the remediation phase. So at this point, we've confirmed that we have a problem. And it's really about starting to find solutions at this point. And the good thing about the test data that was collected during the evaluation phase is that we can use that to help shape and inform how the remediation occurs. So for instance, that test data may guide the selection of a mitigation solution.

Obviously, after we do that, we then move on to the implementation phase where we are implementing whatever that remediation solution is. And then lastly, now that the remediation is in place, we complete that cycle by confirming that the risk has been resolved. And here again, this is where we use DDoS testing extensively, so that we have data that supports that successful resolution. And the key takeaway here is that we have an iterative approach that allows us to improve the environment over time.

And rather than being haphazard in our approach, we use data and real-world tests to drive that progress. Now, I'd actually like to talk about a few specific use cases that we see as part of that DDoS preparedness lifecycle. So we're going to zoom in a little bit. So one of the most common is what we call baseline testing. And really, the issue is that most organizations don't have a proper understanding of where they currently stand with their DDoS defenses.

You know, and this really boils down to, you know, they've never been tested. So they don't know their starting position, and they don't know the maturity of their defenses. So they may have theories and assumptions, but no hard data to support this. And this is actually the most common reason that people reach out to us at Nimbus DDoS to perform testing. Without testing, you simply don't know how your defenses will work when a real attacker targets the organization.

So the baseline testing is specifically for the purpose of getting a consistent starting point and a foundation that you can then build upon and improve. And then along with this foundation, we also identify the gaps in the defenses, which then starts, it basically starts, it acts as a starting point on that DDoS preparedness lifecycle that we spoke about earlier.

So, since this is baseline, since this is sort of a baseline, the testing that we perform tends to be very broad in this area with attack vectors that span layer three through layer seven. And since the focus is on the technical controls and the environment capabilities, we specifically do these events as scheduled events and not surprises. The idea being to maximize the value of the testing session.

Now, while talking about DDoS preparedness lifecycle, you may recall that we talked a little bit about that remediation step. In some cases, remediation may be a very simple task. It might just be simply adjusting a configuration or adjusting a rule. But in some cases, we may have a broader control issue that needs to be addressed. And as an example, we've sometimes worked with companies where they lacked any form of meaningful DDoS defense. And in these cases, the remediation step was actually to implement such a solution.

Now, the challenge is that you basically have many different DDoS mitigation solutions on the market. It can be difficult to select the right one. And as Andre mentioned earlier, each infrastructure is somewhat unique. And the DDoS mitigation solution must be aligned with that specific infrastructure in mind, the business risks and the broader DDoS landscape. So this is where proof of concept testing comes into play. And the intent with this is to use testing to evaluate different solutions. So rather than making decisions based on marketing information, we basically perform a battery of tests.

And we use that output of those tests to make a data-driven decision that guarantees that you have proper alignment with the organization. Now, continuing our journey on the preparedness lifecycle, you may recall that we talked about the implementation phase. This is where our remediation is actually enabled. But how do we know that our work has been successful? Do we wait for an attacker to target us? Of course not. And this is why we must validate the changes to our defenses.

And the intent here with this type of testing is to proactively test the environment to confirm that any changes we make have the effect of improving those defensive postures. And again, this type of testing, it could be broader, it could be narrow, depending on what solutions were implemented and what the remediation were.

But, you know, it can be Layer 7 and Layer 3 and Layer 4, all different types. Next type, which I'll just actually talk about briefly, because it actually is something that both Osman and Andre talked about in their selection.

You know, we've mainly been talking a lot about technical controls. But one area is that there is also this human element to being DDoS prepared.

And, you know, DDoS mitigation solutions can vary. There are some that are highly automated solutions that require very little human interaction. And then there's others that can actually be highly manual. And similarly, you have businesses that can also be either highly automated or highly manual and process driven. And as you might imagine, if a business is heavily reliant on process, the process itself becomes a risk that could be exploited by an attacker.

Now, to give a very specific example, we've seen across our customer testing that manual mitigation strategy, on average, requires about 35 minutes to be successful. However, there are outliers that can take 90 minutes or more to successfully mitigate an attack in those scenarios. And the reason those customers took 90 minutes is because they had a process that failed. So you had a manual process, and then that manual process performed inadequate.

So these events, these are basically done very similar to some of the other testing, except they tend to be surprise events where you're measuring specifically the process. Then I have just a couple more slides before we wrap up here. The next one here, it's about testing, you know, how things are changing. So the DDoS attack landscape is sort of constantly evolving. And the defenses that worked yesterday may not work today or tomorrow. And as with other areas of cybersecurity, there's this continual arms race between the attackers and the defenders.

So every year, attackers are coming out with new attacks that are both bigger and maybe more complex, but they're also attempting to evade those defenses that worked last year. So to confirm that the defenses are still effective, it's important to test as those new emerging threats come out. And primarily, this helps to uncover those gaps in the defenses, but it can also act as a way of testing secondary levels of defense. So if you have alternate backup layers of defense, you can also test those as part of these type of exercises.

And then another use case that we often see, this is not part of the lifecycle, but it's sort of an implied one that we've hinted at throughout the discussion today, is using DDoS testing exercises purely as a training exercise. The reality is that during a real attack, you don't have time to really learn from what's going on. And the best you can do at that point is look at the postmortem data after an attack is finished and try to learn from that.

During an actual DDoS test, you can take your time, you can dig into things, you can learn all about your infrastructure, take your time and maximize the value to learn the most from it. And then the last item I'd like to mention is sort of the compliance part of this, which again, my colleagues mentioned this as well in brief.

But, you know, testing is often becoming a requirement or just generally beneficial from a regulatory and compliance reasons. And this is specifically relevant in highly regulated industries like the financial services and healthcare space.

And, you know, one thing that people often don't realize is that even within the GDPR, which people don't think about from a DDoS perspective, it actually has requirements for data availability. So a DDoS attack actually can cause a GDPR violation, even though people often think of it purely as privacy. But even beyond those specific regulatory environments, we do see corporate governance policies that are increasingly demanding that organizations be prepared for DDoS attacks.

And the interconnected nature of business means that partners and customers are also increasingly demanding that organizations be prepared for these threats as well. Actually, Andre, I'll hand back over to you. We can talk about key takeaways.

Yeah, thank you. So first, I'd like to mention that everything that we discussed and told you will be available as a white paper to download with our approach to these problems. And in general, these problems are that DDoS attacks are nowadays a reality we have to live with, and you will deal with them anyway, sooner or later. So be prepared. And to properly address the DDoS attack issue problem, you have to know your infrastructure, how it works.

And if you don't want to know how your infrastructure works, or you're like maybe somewhere on the highest level of making decisions, you have to find a vendor who will ask you the right questions after you will get them the problem that you have to mitigate some DDoS attacks. So please find a vendor. And my recommendation is to have one single, because communication is the key. And the less communication you have to deal under attack, the better, because it's a stress and the communication ways are not always straightforward.

So, and keep in mind that cybersecurity and DDoS mitigation, and like any area here, is more of a process and not a checkbox. Andy?

Yeah, and I'll just add my sort of two final closing remarks, which is, again, preparedness for attacks is more than just mitigations. You really have to think of things holistically and look at how these attacks will interact with different aspects of the business. And then the final one is, you know, test, test, test.

You know, if you have the ability to test, you definitely want to do that, because otherwise you're really just, it's just a guess at that point. Thank you. Great.

Thank you, Andrei. Thank you, Andy.

All right, before we begin our Q&A, I would like to share my second poll question with you. And I know that even though many YouTubers say that, like and subscribe down below, you don't do it. But please do in our webinars so that we can actually elaborate on this a bit more and then see if we can give you any insights that will help us. And you can still go back and answer the first question.

Again, it's in the tab down below in the poll section. And I give you 10 seconds. And meanwhile, I tell you something. When Andy and Andrei were given their final key takeaways, I was just thinking that preparedness is something I can relate to being proactive in cybersecurity. This is like super important and also becoming a fundamental strategy.

Now, I always give this example to people. When you're driving a car, you always turn on the lights. You fasten your seatbelt and you put the child lock on when you have children. You never start your car, ignite the start before you do all these steps. So these are all being proactive actions, actually. So you make sure that nothing hits you, but you know that they might actually hit you. So if the same strategy applies to cybersecurity strategies, just do you go and test your environment, your infrastructure and see the gaps and also the pitfalls. So that's something very important, isn't it?

Would you like to say something about that, Andrei? I completely agree. This parallel with a car is the perfect example of this preparedness that Andy told us about. The seatbelt is the law and this is the law that was written with blood. The same works with cybersecurity. All the stuff that we can tell you, like how to deal with DDoS attacks, the general approach here, these are sort of laws that are written in the blood as well. Exactly. So actually, before we spend some time on the questions, I would like to share the poll results and then let me know if you want to add something to this.

For the first question, does your organization have a DDoS protection in place today? We have 60% of our voters said no, which is good. Because then they know that they should today. And 40% of them said yes and no one is in the evaluation process. I think that whoever said no should be going to this evaluation phase at this moment, after this webinar. The second question was, what do you see as the biggest challenge in implementing DDoS protection? I have to say that majority of our voters said wrong tool choice. And the second one was budget and no one voted for the other options.

So we might think that people are more concerned about the wrong tool choice. You want to add something up to that? I will add to this poll, especially for the biggest challenge and the wrong tool choice. As I mentioned in the presentation, there was like, even for the HTTP service, there were three threats.

First, DDoS attacks that have to be dealt with DDoS mitigation service. Then something that has to be dealt with web application firewall. And then you have an anti-bot. And these three are completely different services. And you have to be careful selecting what are you going to choose. Because web application firewall will not work under DDoS attack. Because you have to analyze thoroughly each request and you will just be overwhelmed. Exactly.

Okay, I want to ask one question from our audience, Tana Zeiler. There are lots of different kinds of attacks. Do I need to try or test all of them to know if I'm safe?

Yeah, I think I can definitely chime in on that one. So, yes, I mean, you're absolutely right. There's like thousands or maybe even more different types of attacks and permutations. So what we do when we test is we try to find representative samples that represent what the DDoS landscape looks like. So at Nimbus DDoS, and I'm sure actually, you know, Andre probably does this at their organization as well. We track which attacks are the most common in the wild. And what you'll end up seeing if you look at that analysis is that, you know, 90% of attacks is a very small number of types of attacks.

And then there tends to be a very long tail where, you know, yeah, there's thousands of attack vectors, but those are also very infrequently seen. So if you test against that 90th percentile, the 95th percentile, the 98th percentile, you can get very complete coverage without, you know, being either cost prohibitive or time prohibitive. And that's probably highly related to which industry you operate, right? Yes.

Yeah, I would think so. Yes. And which devices you use. And actually, I have one question to you. I was thinking of this. So I've been working on this proactive cybersecurity solutions, and one of them was actually pen testing solutions and red teaming solutions. How do you actually differentiate yourself from those?

Yeah, so, yeah, that's a great question, too. So, yeah, because people often sort of misperceive how these things work.

So, you know, pen testing and vulnerability scanning, that's generally about finding places where you can either steal data or gain access to systems. So a lot of the red teaming exercises around that are about, you know, attackers trying to break in, steal data, access systems. They traditionally don't focus on DDoS attacks. And the reason for this historically was because it was very difficult to actually run controlled DDoS tests in a red team scenario because, you know, it's potentially a damaging behavior to do.

But with the proliferation of cloud vendors and sort of how the Internet has evolved, you know, we can now construct botnets that are almost the same as a real DDoS attackers by using legal and authorized public cloud providers. And we can do that in a safe way. So it's a little bit of a different angle.

You know, we're focused on availability. They're focused more on the other areas of cybersecurity. I agree with you. I must verify this, that all the solutions I have evaluated so far is not paying attention to DDoS testing. And that's something, a unique selling point of your company, I have to say. And another question. Let's see. We can have one last question and try to wrap up. I haven't been attacked before and I'm not really a prime target. How often should I test my mitigation once it's in place? Good question, I guess. The answer would be, like, regularly.

Well, in general, it depends on, first and foremost, it depends on your business. If you're a very conservative European business that doesn't like any changes at all, then probably twice a year, maybe once a year would be good for you. Because you have to deal with the change of attacks overall in a scene. And it changes year after year. So yearly tests would be fine for you. And if you, on the other hand, if you have an enormous infrastructure with lots of developers that launches different products, different applications, like maybe an application a day.

Or even, I know the situation where it's even worse, like tens of applications per day. And they become automatically deployed and you don't even know what's in your infrastructure at the moment. You have to do it more often. Four times a year, at least.

Like, at least. Is there a way to automate this? Sorry to interrupt, but is there a way to automate this process? Because then we might as well say that we are kind of bound to, obliged to have ad hoc or on-demand scans. Or testing, sorry.

Yeah, so I can sort of speak to that. So I guess the short answer is yes, you can. In practical terms, a lot of times we see people not doing it. We can also talk about the real life. Is it necessary to have an automated system like that?

Well, I think the issue is that most people, when it comes to doing this sort of testing, there's a concern that it'll cause an outage. And so normally people want to be very conservative in how they do the testing to minimize that.

Now, over time, as you become more comfortable that your defenses are working well, then doing either a more frequent cadence, like Andre was saying, or doing something more automated, like you're suggesting, Osmond, those both become much more realistic. Like, what we see in practice is that, you know, first time customers or customers that have only been doing it a short time, they end up being a little bit more slow and methodical in their approach because there is that concern.

But there are absolutely ways that it can be automated where you're just doing traffic at a lower volume, where it's a lower risk, but you still are able to detect that mitigation happening and see that working effectively. Yeah. All right. I think that we are seven minutes over our planned time, but please forgive us.

But yeah, I think that we should wrap up, and I would like to thank you, Andy and Andre, for joining us today and sharing your insights and also presenting what you're capable of. I would like to thank you again, and thank you for our audience, and hopefully I see you next time. Thank you all. Thank you. Thank you very much. Bye-bye.