Cisco Systems, Inc. (CSCO) Earnings Call Transcript & Summary

Hello, everyone, and welcome to the Guide to Preventing and Minimizing the Impact of DDoS Attacks Webinar. I'm Mark Watts, your WebEx Producer. In a moment, I'll turn the session over to our first speaker, Matt Carling, but first, I have a few housekeeping notes to cover. Please note your microphone has been automatically muted. So feel free to ask your questions in the Q&A panel throughout the session. And to view the Q&A panel, click the 3 dots on the lower right corner of your WebEx window. At the end of the session, a survey will automatically pop up in your browser. Please click Continue to complete the survey. We really appreciate your feedback. With that, we are ready. So let's get started. Matt, in a few seconds, it's all yours.

Thanks, Mark, and good morning, and good afternoon to everyone joining us here on the webinar today. As Mark said, my name is Matt Carling. I'm the National Cybersecurity Adviser for Cisco's Security and Trust Organization based in Australia. And I'm very pleased to have a couple of guests with me today to talk about preventing and minimizing the impact of DDoS attacks. And that's Pascal Geenens, who's the Director of Threat Intelligence at Radware; and my colleague, Bradley Anstis, cybersecurity specialist at Cisco. So to get the call underway, I might throw to both of you just to do a brief introduction of yourselves, and I'll start with you, Pascal, yourself and what does Radware do?

Thank you, Matt. Thank you. Thank you for having me in this call. It's an honor to be here. So my name is Pascal Geenens. I'm the Director of Threat Intelligence for Radware. My objective at Radware is keeping track of threats, threat actors and the different attack tools they are using. Let's say, what, why and who are behind the attacks. And that ranges from research up to presenting and speaking at different global events and trying to share my passion and also help people to better understand and also be aware of the risks and threats for their businesses. So for the people who don't know who Radware is, Radware is a global leader in cybersecurity and application delivery solutions. So Radware provides defensive solutions to keep your infrastructure and application secured and online. And our product portfolio ranges from DDoS protection, web application and API protection, whether it's on-prem, in the cloud, hybrid. And we also provide leading solutions for bot management to keep bad bots out while letting the good bots in.

Cool. Thanks. I'm really looking forward to our discussion today. And Brad, a bit about yourself?

Yes. I'm Bradley Anstis. I'm a cybersecurity specialist at Cisco, also based in Australia. Currently, I look after e-mail security actually, but certainly today, leaning over on the DDoS side, should I say. Previous experience working in telcos and helping architect their networks against DDoS attacks, which I can tell you is a bit more intense in such situations than commercial networks. But looking forward to the call today, and great to join Pascal and yourself.

Great. Thank you. Just to give you a bit of an idea of the flow of the webinar. We're just going to touch on the landscape and look at the impacts of DDoS. And obviously, we're talking about Distributed Denial-of-Service attacks. I know we're acronym guilty in our industry, but then get into some of techniques and tactics that attackers use, and then flip to the defender side around what are the tips and techniques we can do on the protection and the response side.

So with that, I might ask Pascal first, what -- if we look at the DDoS landscape today, if I look at the news articles, the feeds that we read every day, there seems to be a lot of DDoS tied to like issue-motivated groups at the moment. So if we look at conflicts around the world, Russia-Ukraine or Hamas-Israel. We can see issue-motivated groups declaring their allegiance and then launching attacks against countries, organizations from the other side. So is that what we're looking at today or, obviously, it's a much bigger picture. Your thoughts?

Yes, sure. So in the last 2 years, I have to say that DDoS has been wildly mediatized. If you look at the press, if you look before 2 years ago, so before the war started, DDoS attacks, when I was talking to an accountant or to somebody in the shop, and I was -- and they were asking me, what is your job? And I say, yes, I mostly go after DDoS threat actors. They were looking at me like, what is DDoS? But if you talk to people today, it doesn't matter who, they are all very much aware what is DDoS. It has become prime time news. So it comes on the news almost every -- every week, talking about this website from this government has been attacked and has been attacked by, typically, it would be, in our case, when we watch the news, it would be Russian threat actors that took down the minister, the Prime Minister's website or the website of food chains. But there's much more going on than just war. So as you said, on one side, we have the patriotic hacktivists who are trying to spread the message. So they are hacktivist. Like an activist, they want to get noticed. So they want to spread a message. So they're going to try every possible way. That might be doing defacements of the websites or replacing the main page by another message, typically a shocking message about what they want to say. But then you have hacktivists like Noname057(16), for example, which is very methodological, and goes on Telegram and says, "Hey, today, we're going to attack those countries because," and then they will give a reason. And most typically, that reason would be that the government was showing support or did a gift or sent weapons to Ukraine. And then they will go and DDoS attack some innocent websites, which can be a government website, but it's not limited to government website. We also see public transport ticketing websites or online shops and also public information websites. But there's not only hacktivists. So we also saw at the beginning of the war in Ukraine, for example, there was a DDoS attack that was performed by the GRU. They leveraged an open source or open source of widely available DDoS-for-hire service to attack several targets in Ukraine, and they also were able to take down the Viasat Communications. So DDoS is also an important weapon in hybrid warfare because it can impact communications. You can create chaos. You can distract the other side from what you're trying to do and make your invasion more impactful. It didn't help that much in the case of Russia, but they did have an impact on the communications on the ground because they took down the systems that were being used to communicate with the ground troops. Besides war and conflicts, so as you said also in the Israel-Hamas, we saw that the activity, especially from hacktivists, so pro-Palestinian hacktivists and also pro-Israelian hacktivists, both sides of the fence actually, we saw a much bigger impact compared to what we saw before. So the war or the invasion of Russia and Ukraine is like a blueprint in many different scenarios. It's being used as a blueprint and something that people base themselves on to create new actions. So the way that the impact was on DDoS attacks after Israel started to go into war with Hamas, we saw much faster ramping number of DDoS attacks and also much more impactful for both sides, not only for Israel, but also for the Palestinians. And then, of course, besides war, there is also the traditional attacks. Motivations would be financial gain, for example. They can do extortion through ransom DDoS. Gaining reputation in gaming. So gamers who are competing, who are attacking other multiplayer gamers, so the online gamers, so that they can get an advantage. When his screen is frozen, they can go for the kill, for example. Also, streamers. Competing streamers and influencers. When somebody is gaming online on Twitch and their IP address get leaked through that game in the multiplayer game, they might attack them and they might interrupt their Twitch stream so they can have it for them.

It seems like lots of motivations. So I guess mostly Asia-Pac time zone, Asia-Pacific time zone, we're geographically somewhat away from some conflicts. But I guess listening to you speak, it's just because we happen to be based in Australia or Singapore or whatever nation we're in, would you just be a target because of support our governments have offered to one side in some of these conflicts, not forgetting we could be directly targeted to financing extortion. I remember the Sony PS DDoS from 8 years ago now maybe?

Yes. That was a totally different motivation. That is more in the gamer and reputation side, those things, kids getting bored. And during the holidays, attacking PlayStation, threatening to impact and all other kids who want to go play. And to your point about Asia, Japan was -- this weekend, was the target in attacks from different patriotic hacktivists of pro-Russian hacktivists that went after Japan because they declared support for Israel. So it's not only Ukraine, but any country that now declares support for Israel in their war is also being targeted by the same pro-Russian hacktivists and typically joined by pro-Palestinian hacktivists. They are a strange bunch, those hacktivists. So in some campaigns, they will come together, in other campaigns, they will fight each other. So it really depends on what suits their needs and what kind of motivations or ideology they see behind it, but they are pretty ferocious. And in the beginning, we might have said that, well, those hacktivists are not worrying us because, yes, they're not nation-state attackers. They're not backed by big money. But after more than 2 years of every day coming back from their day job, starting their evening, and their evening is like spending different ways to perform DDoS attacks or defacements, they got experienced in those 2 years. They created big communities. We're talking communities that are above 100,000 members. They are almost all on Telegram now. So before, when you looked at hacktivists like DragonForce Malaysia, for example, in the Asian continent, they have private forums. And it's only when you were in that private forum that you got exposed to their messages, but nowadays, they are all moving to Telegram. They create public channels so that they can spread their message that the media can pick up on their actions. So whenever they do an action, they will post it on Telegram hoping that the media will pick up on it. And you can see that in the Telegram posts because whenever there is media coverage, they will take that media coverage and they will just post it and say, "Hey, look, everybody saw what we've done that we really impacted and made a difference."

Matt, sorry, Matt. I was just going to say, a previous one, I saw that was pretty interesting actually out of Perth here in Australia. So it was a mergers and acquisitions sort of activity happening between a couple of mining resources companies. And I was sitting in one office in Perth, and they basically said, well, we're currently being attacked by that company, and they pointed out the window across the street. Obviously, they had gone and obtained one of those open source kits that Pascal was just referring to. And basically, they were trying to give the other company something else to sort of be thinking about when they were both trying to compete to acquire another company. So while it's really interesting to look at all the cyber activism and warfare sort of aspects, it's actually quite astonishing also how you can come across these sorts of things in a lot smaller, more local environments as well.

Bradley, yes, I totally agree with you, so-called competitors attacking each other. You don't see it a lot in the media because one of the things about DDoS is like a hit and run. It's very difficult to find out who's behind the packets that are arriving at your network because you can spoof them, you can hide yourself very easily. So it's very difficult to attribute DDoS attacks. It's not like a ransomware where the ransom is dropped and then you have to go into negotiation. You know exactly who dropped the ransomware there because they reach out to you and you have to go into a negotiation. With a DDoS attack, there's typically no negotiation except when it's a ransom DDoS or when it's an extortion, then of course, they will send you a letter and expose who they are. But typically, you -- they will not expose who they are. And most of those people like -- you don't even have to be versed in DDoS attacks. If you go online, you just go to Google right now and type in booter and stresser, you will even find advertisements by Google where you have illegal booter and stresser services that's -- after creating an account, just put in whatever e-mail, put in whatever password, it doesn't matter, don't put in your real e-mail for sure. Don't do that. But they're not verifying e-mails. Once you get into the portal, you will see that you have access to a whole bunch of different attack vectors. So you can choose what kind of attack you will do. And then all you have to do is put in the host name, press the start button, and it will start attacking. Of course, you have to pay for that service. Some provide 5 minutes for free with limited power. But once you start paying and that can be as few amount as $30 for 1-day access or $30 for a couple of days access, which allows you to perform devastating attacks, some attacks going up to 1 terabit per second on the application level, on the web DDoS, going into the millions of web requests per second just for a couple of dollars. And with the attacks on Russia and the hacktivists, we see more and more of those services coming up from the Russian side. It was already a problem before, but now it has multiplied because many of the pro-Russian actors, they are now experienced, and they see an opportunity to make money. So they will take the tools that they use before for their ideology and they will turn them into a commercial tool and try to get people to pay for them. And at the same time, you have the other -- yes, sorry, the other hacktivists...

No, no, no. You're touching on my question around how these different actor groups, whether they're issue motivated or criminal motivated or nation state, is a lot of it now moving to what it sounds like is DDoS as a service? Is that the predominant means by which attackers like getting the capability? Or how many -- how much of it is still people building their own infrastructure to conduct their own attacks?

Well, yes, of course, the people who don't know how to do it or how to start to do it and who were not versed in all the different technologies that are out there, like cloud and IoT, they will pretty much leverage one of those services. And that can be an online portal, but you can also have a Telegram channel. So some of those booter and stresser services, they expose a Telegram channel because Telegram is free and open platform. It's a great platform to actually build bots that are running on the channel and that automatically interact with whatever message you're typing in. So some of those booter and stresser services now use Telegrams. So from your phone, you just go to the Telegram channel, you say, okay, I want to do an application-level attack, use this attack vector, and attack against this host name. Press enter. Well, press enter, no, press send on your Telegram, and boom, the attack is starting. But then on the other side, you have, of course, the more versed ones who are building their own infrastructure. So as I said, hacktivists, typically, they don't have the money. They have different means of income. Like, for example, relating to those DDoS-for-hire services, those services, they are competing with other DDoS-for-hire services. So you will see them doing advertising. Of course, they're not advertising through Google, they are advertising through hacktivists because hacktivist has a channel, a Telegram channel with 100,000 people who are eager to perform DDoS attacks. They're just jumping for the possibility to perform a DDoS attack against the target and brag about it in the channel, "Hey, I took down this or this, this country." So what they do is they typically will reach out to the hacktivists themselves and ask to advertise their technology. And we saw that by Anonymous Sudan, for example. Anonymous Sudan performed, last year, some attacks on OpenAI and on Microsoft. And you might think why is he doing that? Well, at the end of the of the bottom of that message during the DDOS attack, it would say, "This DDoS attack was performed through the Skynet botnet. So it's clearly advertising that Skynet botnet to its channel and showing world, hey, that Skynet botnet can have an impact. So if you want to -- if you want to subscribe to it or if you want to use it, if you have a big target, that Skynet botnet can be very impacting and can be very damaging.

You mentioned a couple of things that I just wanted to -- for everyone here on the call, big multi-terabit or greater than 1 terabit per second attacks and also an application-layer DDoS attacks. So maybe you could share a little bit around like what are the techniques and tactics behind different types of DDoS attacks and the types of infrastructure or services they go after?

Yes, sure. So maybe start at the network level. If you look down at the -- so I was going through the [ Aussie ] levels from down at the network up to the application. But DDoS attacks, typically, when I talk to people, they would see it as a volumetric attack. So something that has a lot of packets coming at them that is saturating the bandwidth so there's no communications possible anymore. So we have different techniques in volumetric attacks. So one would be by having an infrastructure with a limited number of nodes. So -- and the same way that our businesses are finding agility in the cloud by moving to the cloud servers and deploying using DevOps tools such as Terraform deploying multiple nodes. Attackers, while, basically, typically, they would do the same job as you and me, only when they come home, they switch -- they flip the switch and they become the other side. So they use the same techniques. They deploy their bots across the cloud infrastructure, of course, not in a public cloud. We have seen some of them in public cloud, but whenever we find the origin of the attacks, we can always send an abuse message to whatever cloud and they will take down those nodes and then they lose their infrastructure. But they can go into what we call bulletproof services, which do not react to abuse messages. Typically, they would be located in countries like Gibraltar or Iceland, where even regulatory environment is much more difficult and the authorities will not go after them and bring them down. So they're pretty hard to take down. So they have a cloud infrastructure. And with a limited number of servers and also what we call the amplification attack, so reflection and amplification where you leverage like, for example, open relay DNS servers on the Internet, you sent a small request and the fact about DNS is that we still are using UDP, which is connectionless. That means that there's no authentication. There is no connection involved when you do a request to the DNS server. So I can send a UDP request asking the DNS server, give me a list of all the names that you know for this domain. And how does the DNS server know who I am? Well, he's looking at the source IP. That's so the DNS server takes the request, creates a response and send the response back to the source IP that it came from. If I change the source IP and I do a big request, but I change the source IP to another victim to somebody I want to attack, I send a request and the server will answer to that other company, so to the victim. And in doing so, I can create a stream that is only a limited number of gigabytes or even megabits per second. And then the server will answer with like 50x, 100x, and we have seen certain application where you abuse not only DNS, but you can abuse memcached. It can be NTP server. So everything that is based on UDP and that doesn't do any authentication can actually be abused as a reflection and amplification service. And you can have levels of amplification ratios up to 5,000, so where you send in 1 byte and 5,000 byts go to the victims. So if you generate 20 gigabit per second, that results in a 100 gigabit per second attack for the one who's on the receiving end. So that's at the network level. That's volumetric attacks. Typically, they will also -- you maybe heard of carpet bombing where instead of focusing on one specific IP address, the whole load, the volume that they're sending, is being spread across the whole IP range. And they do that to actually evade traditional threshold detection. So if you do detection per IP or per server, you might see instead of one big peak that is easily to spot, you will see that the whole volume is spread across multiple IPs and stays below a threshold, but if you add them all up, your Internet line is saturated. So still at the network level, but you can also target Internet gateways of service by resource exhaustion attacks like SYN floods. So you send SYN packets, and if you create a session table, so you send the SYN. The server will answer it to SYN-ACK, and you create a temporary session in the table until you get the ACK. And then the session is complete. We will let it through. Typically, what an Internet gateway or a firewall would do. With those SYN attacks, you can fill up that table. Of course, there are solutions with SYN cookies, but then there's all the drawbacks. But exhaustion attacks are still very much something that is happening. And that might be at the level of exhausting memory or limited tables, but also at the level of processing power of those devices. If we move a little bit more to the application layer, encrypted attacks. So encryption is very expensive. When you attack a server, you might do a TLS start and start a TLS negotiation, but then drop off. So just initiate it, the server goes to all those encryption things, creates [ announce ] and a key sends it over, and nobody is listening on the other side. And if you keep doing that, you can impact the CPU of that server. Also, resource exhaustion attacks on the application layer can be what we call low and slow attacks, where, for example, you have a download of a file, so a server can handle a limited number of concurrent sessions with multiple users. Let's say, you have 1,000 users that you can serve at the same time. It's a small amount, but it's much more than that in reality. But if I have a program that can -- sorry, upload or download the file, and I do the upload very slow, like, for example, 1 bit per minute, always trying to keep within the range of the time out, so that never time out is occurring. But I can do an upload of a very small file with only a few bytes and it will take the server more than 1 hour to upload that file because I slow it down. I'm very slow, but I'm still allocating a session in the memory of that server. So low and slow attacks can be impacting for those things, can be also impacting for memory use because all those malicious sessions are taking over from the capability to address legitimate sessions. And then going one step higher in the application attacks, we have what we see more and more today, which is the web DDoS attack. So those are encrypted HTTP attacks. So it's an attack of the website. But the request to that website looks completely legitimate. So what the attackers do is they go look at your website, they try to find things that can be impacting for the back end, for example, a form fill that posts information and records it in the database. They will look at all the different variables and arguments in that webpage and they will construct a request that looks exactly legitimate, but they will randomize the content of the different variables, up to the point that whenever you need a number, they will put the random number. If you need an e-mail, they will randomize an e-mail. If you need text, they will randomize text. And then they will hit that website with millions of requests per second. And then your back end will fall over because there's so many requests coming in. And if the back end does not fall over, then you have still the human factor because the human who's looking at the form fields will have hundreds of millions -- billions of e-mails with a new feedback form that is being filled in. So he will not be able to see the legitimate requests of that day from the attack request. And that's also typically what we see happening by hacktivists today. Those web DDoS attacks can be really difficult to detect and to stop.

Well, just before I move on to -- there's a huge variety and different techniques from DoS and DDoS attacks. But Brad, in the -- in your background as a service provider space, I always assume to be like it's the pipes problem. But when we look at large enterprises and SPs, obviously, some of the crown jewels is the control plane. So I know there's a lot of focus on control plane isolation, control plane policing and right loading because some of the things Pascal was explaining around, it doesn't necessarily take a lot of traffic to consume a lot of resources. What was the experience from being in the telco space?

Yes, and great topic. And I think the big thing was around architecting so that your control plane was running on a separate internal-only network, and that was critically important because it's your control plane that will help you understand when something is going wrong. If you've got everything off in the same network and your network is being completely flooded then you're also going to obviously find out about it a lot after the fact as well. So architecting those sorts of networks so that they control plane and even more importantly, the remediation capabilities were on a separate network that were not accessible to the outside or certainly were shut off from most of the sort of typical DDoS attacks are very important because at the end of the day, from a [indiscernible] viewpoint, you're under an SLA to your customers. So it really is in a situation where the buck stops with you.

Yes. And look, again, you're jumping to what I was going to ask around next around the response side. So Pascal, with that large variety of the attack surface, I guess, you say across our OSI stack, however, you want to frame it, how should organizations think about how do they prepare and defend but also respond to the whole space called DDoS attacks?

Like most of the things in security, preparation is like 80% of the job. Understanding your attack surface is very important, knowing where the vulnerabilities are, where the holes are. And it starts with just having a good idea of which services you are providing. So if you know exactly which services there are and through red teaming, pen testing, you can find out where the holes in my attack surface and then you can plug those holes. One thing that I see coming back very often is domain name system, DNS. I already mentioned it leveraged as a reflection server. But DNS is the cornerstone of all our communication on the Internet. If an attacker goes after your DNS server and brings down the DNS server, then there is no more website, there's no more APIs that's accessible. There's no more mobile applications. There's not even communications anymore because maybe the company is using voice over IP, using the same host names. There's no more remote access for the people who are on the road because they are connecting into the VPN through a DNS host name. So everything that's not using IP address is, all of a sudden, grinds to a halt because the attacker is going after your DNS server. And we've seen that in 2016 when Mirai hit Dyn DNS, how many services like Netflix and Amazon were just off-line because their DNS was impacted. It still happens a lot. So one of the things that we saw in last year's attack in 2023 is an increase in application layers or web DDoS, but also a big increase in DNS attacks, so going after that DNS and going after that cornerstones. But as an organization, I still have to see an attack that we cannot detect and defend against. But depending on the attack, there's something that you can do yourself. So first of all, preparation is already a big part of it, as I said, but then also having the protections in place. But you can protect yourself on-prem, which means closer to the application, you are in full control of the protections. And you also have no latency because your traffic is not being redirected to a cloud. And that works well for the low-and-slow attacks, for resource exhaustion attacks, works well for application-level attacks, everything that doesn't take a lot of bandwidth. A DNS attack, for example, several millions of requests per second will be below 1 gigabit per second. So a lot of companies now have a 1 gigabit per second or more lined into their premises. So you can do a lot on premise, but it's when the attack starts to grow and when the attack has moved to volumetric attacks that then you are limited in what you can do. So then you need an ISP protection or a cloud protection that corrupts your traffic. If we're talking multiple hundreds of gigabits per second, then we have seen several terabit per second attacks on the record level. Once you get into that area, well, there's no protecting on-prem. And I can tell you, the attackers have access to all the different tools that I was talking about. So you will typically see, when there's a DDoS attack happening, they will start with amplification and see. So they will just hit things at the wall and see what sticks, right? So they will try with a volumetric attack, no impact. Okay, maybe it was too easy, so they're going to change vector to an exhaustion attack. If that has no impact, they're going to change vector again. So it's not like -- that's why we have hybrid solutions in DDoS protection, where you have both the low latency on-prem defense, but when the volume gets too high, we automatically move all the traffic through scrubbing centers that are in the cloud so that we have much more capacity and capability. And the same for web DDoS attacks. If it's a low-and-slow attack, just a couple of hundred requests per second, most of the servers can handle that on-prem. But if we are starting to talk about multiple millions of requests per second, that's another level. Most of the servers are not built to withstand that. And then you might say, yes, I'm going to move to the cloud. And in the cloud, hey, I have unlimited capacity coming into me, which is true. And I give you that. You put your server there. You take full subscription. But when you're under volumetric attack, you will not even feel it. Except when the end of the month comes there and your bill comes, your invoice comes in, and then you see that you're paying maybe 10, 20x more than usual. And if you look at where the cost is going to, it's going to a traffic because every tier in the cloud, there is a certain limit in total traffic. And when you have volumetric attack, you're easily going into multiple terabytes of traffic coming in within a couple of minutes. So even a couple of minutes attack can cost you tens of thousands of dollars of cloud excess traffic instead of the typical $1,000 bill that you get in. I actually had a customer who had that. He said, "Yes, I was -- I felt perfectly safe because the cloud consumed all the packets. But afterwards, they sent me a bill that I was not really expecting because I had to pay for the excess in traffic because I did not have a DDoS solution." However, most cloud providers will provide you a DDoS solution, and then they will waiver excess in traffic because you are paying a subscription for a DDoS solution. But if you don't have a DDoS solution, it's not included, best to always check your contract and make sure that excess in traffic or that you don't have a cap on your bandwidth coming in because when they do volumetric attack, the bandwidth will jump in the air very fast.

It sounds like something that, yes, When you describe it, it's obvious because that's how a cloud works from a subscription model. But when we look at the people doing their preparation and looking at what would be the impact by business, and we'll talk about in a moment around that sort of planning, we think about always our website defaced or can we provide our service external facing or is it our control plane or infrastructure running and potentially didn't think about those traffic charges down the track when -- until you get the nasty bill at the end of the month, I guess. I guess one thing I heard there, especially with the volumetric attack where you need to solve the problem upstream or mitigate the attack upstream is, obviously, you need to have all this planning in place beforehand. When you're under a volumetric DDoS attack or whatever type of attack, isn't when you need to be working out or who do I call, my service provider or my cloud provider to help me mitigate or shift my workloads, how they're going to achieve cyber resilience. So are there any good -- it may not be DDoS-specific, but good frameworks that people might look at around that sort of preparation for incident response planning, obviously, DDoS being a type of that?

Well, yes, so to give you an example, we have a service which is like a big red button on our websites. Get me under protection right now, which can help you last minute if you didn't prepare for it. However, you have to take into account that making changes to your network last minute in a chaotic environment is not a good idea. I do remember a big government that was under attack. And they got us in but we were not the only one. They also got in some of our competitors, and they were putting one layer of defense on the other layer. And our defense was completely disrupted because they put another layer in front of us that was funneling all the traffic and everything came from the same source IP. So everything looked like an attack. So they were just blocking everything, confusing everyone. And even after the attack was over, it took them still several hours to redo all the changes they did while they were under attack to quickly try to get different vendors onboard and try to find the fastest one to provide mitigation and hoping that putting one bandage on top of the other would be more effective, which it was not. So doing that is never a good -- that's why we always say, come prepared. Do an incident response exercise. And that can be as easy as tabletop exercises. Just sit around the table, start talking. Find the scenario. Hey, we're under DDoS attack right now. What are we going to do? Who are we going to call? Who are the people that we are in contact with? Can we talk to those people? Try to find out where our weakness is. Talk to a red team, pen testing service, try to find out where the vulnerability. So from there, you can build a whole plan on how to mitigate and how to be prepared. If you are prepared, there's no reason to fear DDoS attacks, even if we talked about multiple terabit per second. And it doesn't really matter. I've seen websites falling over because of a couple of megabits per second. If you have the right target with the right limitations, a small attack is more than enough to tip over services. So it doesn't have to be multiple terabits. So you don't have to be scared. You just need to be prepared. If you're prepared, that's the whole thing.

I was going to just shift gears slightly because talking a lot about the different types of attack vectors and the levels of the stack, but might throw it back to you, Bradley. If you're the CISO of an organization or the security manager, what would be the tips of where they should start when they're thinking about defending and responding to DDoS attacks?

Yes. Good question. Boy, it's been so negative until now.

Some -- like how we get rid of it.

Well, the great news is, obviously, I mean there are some really good tips. There's some great frameworks. Here in Australia, cyber -- have some great tips about time preparing for DDoS attacks. On the Cisco website, we have 5 tips to go through and help you prepare for these sorts of attacks. I mean there are things like mapping your vulnerable assets and that's not only on-premise applications and servers, but what have you got running up in the cloud. Do you have an entire inventory of everything you have running, make sure you keep an eye on shadow IT with marketing, firing up new services every week. But once you've got a control of all those, obviously, you're trying to assess the risk across them, which are the critical ones, which are not so critical because there's different approaches to DDoS as well. And Pascal has kind of been referring to some of them already. I mean it could be an on-demand type part, DDoS remediation that you might choose for some slightly less impactful resources or if it was a very important resource, maybe that is a permanent traffic redirect, we're doing via a cloud scrubbing service, for example. Yes, we're going to put up with a little bit of extra latency because traffics going through somewhere else. Yes, it costs a bit more than on-demand-type services, but I know that, that very important resources protected 100% of the time. All are hybrid approaches. So it's all well and good mapping out the areas or the assets that you've got. Obviously, you've got to assess the risk across them, start helping you -- which will help you understand maybe a budget that you can apply to address the dangers of DDoS against those different assets. I think one of the really important areas that I've seen a lot of customers fail on, is how do you detect? And being aware that you're under a DDoS attack, as Pascal said, right, if it's running in the cloud, that could just hoover up all those packets and you don't actually realize it necessarily. But certainly, at the end of the day, it's all about application performance and application response to your customer. You can go and monitor your network and have all this cool stuff sitting there, and that's all really important to do. But at the end of the day, it's all about how is that external user, what is their response and interaction like with my web resources, for example, and helping you assign the cost or the budget. For example, what would it cost Cisco if the cisco.com website was down and people couldn't download brochures or place orders or do those sorts of things. And that's how you kind of assess that budget to apply against each one. So making sure you map out the assets, assigning a risk to those assets, making sure you assign responsibility as well is also critical. If you're using a lot of hosted providers or SPs, for example, do their SLAs, are they backing up your SLAs. You probably have a performance guarantee to your business. You better hope the service providers that you're using back to back, if not better, responses to these sorts of attacks. Detection mechanism is critically important. This is an area I see a lot of organizations fall down or quite limited and then how you respond. Pascal talked about before, actually, I've seen an organization they were moderately well prepared for a DDoS attack, but one of their remediation actions was for a specialist cyber company to remote into the organization to help them remediate the attack. Problem is the way they access the internal network was via a VPN. And the attackers took out the DNS server and it was all over from them. So certainly doing their preparation are strictly important. But then your effective DDoS protection. It's not one size that fits all, whether it's on demand. It's really interesting edge protection capabilities now. I mean it's one of our advantages, I guess, being such a big networking vendor is having onboard protection and routers and firewalls and things like that can also be a great addition into edge detection for DDoS response. So on-demand, edge protection always on or a hybrid between them with a common management console, so you can see exactly what's going on is the best way to kind of appropriate the cost against those different assets, but it comes down to understanding exactly what your inventory is.

Yes. Pascal, jump in Pascal. I know there's a lot of sub-security risk management process and governance and what Brad just explained, but you picked out something for around like DigiNote DNS was the most critical thing, the critical dependency of the crown jewels. So do you have any advice to tack on to what Brad was sharing?

Yes, especially on the risk assessment side, because people are quick to say, "Oh, that website is not important for us production." You know that public website that is out there. How many times I heard people say, "I don't care if that website goes down." It's like, if you don't care about the availability of that website, just don't put it online. If you don't care about your data, just don't put it online, keep it off-line, right? There's not only such thing as availability as a website not being available, but there's also things such as reputation. A lot of the damage from DDoS attacks is done through your reputation. Attackers are attacking you and are bringing down your website. Why? So you cannot perform business, yes, but some businesses are not doing online transactions, some are into production. It doesn't impact production, yes, but it impacts their reputation. If a customer cannot access the website, if they cannot do payments, okay? It's a direct impact, but the indirect impact is reputation, and reputation can cost you lots of dollars down the line. And that's what competitors are after actually. And then the second tie-in is towards detection. So we've seen DDoS attacks actually being used as smoke screens to hide other attacks. So as you know, when you're log and so -- so when you have detection, detection is based on logs, on events. Now if I sent so many requests to web server that he's logging, he's trying to log the events, but then the speed of logging gets impacted. So typically, you will have a limited number of events per second that can be logged to your disc or to your storage infrastructure. If I can get on top of that level that is the maximum that you can handle with your storage, it will start dropping events, so not logging them. If I then do another attack, if I do, for example, an intrusion and I get inside and I can plant back door, it's not being logged because I saturated your capability of logging events. So in the terms of detection, you can leverage DDoS attack to hide other attacks. And it's not hiding in the masses because we have AI, I'm giving you a bridge to the next topic, but you have AI and you have all kinds of smart automation that can find that needle in a haystack, that one attack between all those different logged events that are coming from a DDoS attack. But the big problem is before you can find something in big data, you need the big data. You need to log everything that is happening, but if your logging infrastructure is being saturated, yes, sorry, but you will not see it.

I'm just watching the questions come in. And I'll -- there's a question around early signs that the DDoS attack's underway, what should we be looking at a daily basis. But maybe I'll include opportunity to answer that with, as you alluded to, I think in 2024, there's an unwritten rule, you're not allowed to hold a webinar without talking about AI. So the question on AI is, we see -- I hear a lot about AI helping the attackers and making better attacks. So your views on that. But more on the detection side, you started alluding to, is AI really going to -- we should be looking for capabilities on the detection side because some of these things you have low and slow and other types of attacks? They may not be triggering thresholds. So I'll pause there, so thanks for the question, sort of roll it into does AI help you or is it just stuff we can do with logging and other detection mechanisms? So Pascal, I allow you to jump in as you mentioned AI.

Yes. So let me start from the attacker side. So the AI tools that we have now and when we say AI today, everybody is, of course, thinking about GPT, right, about transforming models and about large language models and diffusion, where something is generating either text or an image or video, those AI systems are not at a level that they're generating payloads or more sophisticated or unseen levels of new sophistication and attacks. What we do see, however, is where we also, as the good guys, benefit from attacks in our day-to-day job is that where is the gap in the malicious crime or in the underground. So when somebody builds a tool like a DDoS for a service. He's very good at building that tool, but he's bad at marketing. Like I am very technical, but I'm bad at marketing. Well, I can use AI to fill that gap, to bring myself up to the level of I can write a very exciting text and sell my stuff because I will go to GPT and ask it to do so. If you're not versed with scripting, you can go to ChatGPT and ask it, "Hey, write me a script that does a limited low and slow attack against the server that looks like this and this and this." Well, yes, don't call it the low and slow attacks because there are certain guardrails put in place by the provider of the AI system. But there, the attackers are smart enough to just copy. So you also have open source models, you can download the model, which is a pretrained model like the GPT that you're using online, but online there's guardrails set. You can download that on your own server or your own PC and run it without the guardrails. And it's the same model because it's just the same data that's trained on. It's just a bunch of power meters that are -- and the architecture of the model that sits inside kind of parameter file, that's a couple of gigabytes that you can download and you can run it. But the bad guys downloaded that and run their own services underground and are selling access to those services to run like a kind of GPT without guardrails. And typically, they will use it to do research. Like we would also use it. If you want to do something and it takes a lot of time, well, you can use AI to outsource it and to have it done instead of having somebody doing it for you. Now you have a model doing it for you. It's a repetitive task, go search for all the vulnerabilities behind all those IPs, for example. That can be easily automated. Before we needed to write scripts, now we can have generic models that can do that. But it's not increasing the sophistication and towards the detection. So as I said, we're honing in or we're hearing a lot about those transformer models and large language models, but AI is much faster and bigger domain than that. That's like a very small tip of the iceberg that we're seeing there because it's so popular and so impactful for the common people. But AI has been going on since the '50s. The first foundations of AI come from the '50s and even neural network has not evolved that much since the '70s. It's just that we have access to lots of data, lots of compute that enables us to leverage those models to do something big now but it's still the same foundation as we had before. And then the defense side, we are already using machine learning for -- we didn't call it AI. Now we call it AI, marketing term, right? But before we just called it machine learning. And the difference between a generic or a more -- sorry, generative AI and a more general approach because a model like GPT, you can ask it anything, you can ask it to write a script, it will write a script. You can ask it to write a poem in French. It will write a poem in French. You ask it to write a love letter, it will write a love letter. It can do a lots of things. However, you can also do something that is more modeled closer to the problem state. What I say, for example, a nice example would be blocking a SYN attack. So typically, when you have TCP, you have SYN, SYN-ACK, ACK, so it's a 3-way handshake. Now instead of just see, looking at the threshold of the number of SYNs coming in, let's look at the distribution of the flags between SYN, SYN-ACK, and ACK. And if you have a large amount of SYN and you don't have enough SYN-ACKs and ACKs in there, that means that you're under attack or if you see a lot of ACKs and not a lot of SYNs coming with that, there's something wrong. So that's kind of the modeling and there's no thresholding in there. You are independent boss of thresholding and some other models that are more closer towards the problem space but are still using AI to -- well, not AI, but machine learning to set the thresholds automatically and adapt those thresholds, like put in place a signature, look at the traffic that goes through if you think that, oh, that signature is blocking traffic that is potentially legitimate traffic. I'm going to refine the signature. So you can make your systems intelligent, not to block everything but to refine your signature and multiple steps by putting it in place, look at the result and just improving it and improving it and improving it. So those are things that we already do for a long time. Now going into the future, both sides have access to the same technology. For me, it will still be the same game in the end. Just a game of the cat and mouse. So some things we are in front of them and their attacks will not be useful. Somethings they are in front of us, they surprise us with a new kind of attack. We come with a new quick response with a detection and protection. And on the AI level, it will be the same, it will be the same game again that we're going to play and the same technologies that we're going to use.

And maybe just to jump in, Brad.

And maybe just to jump in, Matt. So obviously, detecting whether you're under a DDoS attack, there's -- we've talked about some detection methods, et cetera, technologies like thousand lines, et cetera, that can actually measure a end-users's observance and response for the application is probably one of the most effective ways of actually doing it, but there's also nontechnical ways as well. So does your receptionist's issue getting phone calls from external customers saying, "Is there something wrong with your website? I can't seem to download something or access it all." Making sure that people like that, there's nontechnical ways of detecting now that you're potentially under an attack as well. So don't forget those because...

Yes. Yes. To your point, you have the things that you can easily detect. So when your website is under a DDoS attack and they are just knocking it out of the air, well, yes, obviously, you will see it, right? You don't need any sophisticated detection to find out that your website is not working. However, there's also those attacks that we call the low and slow attacks that some are using to impact your bottom line on applications. So let's say that you have online applications, somebody is coming in with a steady stream of requests that keeps your CPU busy and can keep your CPU busy for like 20% of the time. Well, you are paying for that 20% in the cloud. And we -- I've even seen attacks. So at one point, we had an attack coming in, so targeting one of our customers, and that attack came in like every 3 minutes on the dot, there was like a big burst, big volume for a couple of seconds, and then it goes away. And after 3 minutes, bang, it's there again. And then 3 minutes later, bang, it's there again. What we found out is actually that it was targeting the way that Elastic Cloud is working. When you're in Elastic Cloud, you have computes, a certain amount of compute. But if you go above that amount, you can jump to the next tier of compute, so you just add more compute power. Now if somebody doesn't attack and you're under attack, you need more compute, you add that tier. Now there is a certain cooldown period. And after the cooldown period, the tier will fall because it sees that, oh, the CPU has not been used, so I'm going to fall down to the original tier, so that you pay less. So it's elastic stretching in and out. But if somebody is sending you like burst attacks every 3 minutes or 5 minutes or 10 minutes, depending on how that cool timer works, it keeps that elastic like being inflated and you will pay the whole month for a more higher tier of elasticity.

Look, we're down to the last couple of minutes. So I have one last question. So it might be unfair because I'm going to give you 30 seconds each to answer this. This is the crystal ball question. What do you think is the future of DDoS attacks? What should we be thinking about on the horizon? 30 seconds, Pascal?

Yes. So when I look at what happened -- and again, going back to the conflict, the democratization of DDoS attacks, the IT army of Ukraine asked volunteers to help them in fighting Russian propaganda. And to do so, they created tools and made DDos much more accessible, improved public tools. And for me, going into the future, I'm looking at a future where an activist like Grandma and Grandpa are not happy with the taxes put on their pension instead of writing a letter or going to the journalists and saying, "Hey, I'm not happy about what the government is doing on tax." They will just sit behind the tablet and perform a DDoS attack on the government website.

Brad, your 30-second thoughts?

Yes. I think it will be around DDoS being a lot more mainstream. And I think coming into -- I mean, actually, business continuity planning from a cybersecurity viewpoint, some of the main reasons why cybersecurity was originally included was actually around DDoS attacks. And that seems to have gone out of favor for whatever reason. So I certainly think a better understanding of DDoS attacks and all the different types of DDoS attacks that Pascal has been talking about today, with a lot better understanding of exactly how and where they could impact our organization. From a technologies viewpoint, the benefit behind this obviously, if it's a core part of your BCP plans. Obviously, management are ultimately responsible for the business continuity plan and funding it. So certainly, that can really help allocate appropriate funding to address this very serious issue.

So thanks. Look, there's a few questions that people submitted. I apologize we didn't get to everyone, but we are going to note them down and so we will follow up. So if you've submitted a question, someone will get back to you, some very good ones. So thank you very much. With that, again, I'd like to thank Pascal and Bradley for joining me. I thought it was a great call. I learned a lot personally. I hope you enjoyed the call. And I'll hand back to you, Mark. Thanks.

Thank you. Thank you for joining, everyone, and thank you for having me. It was a great time.

Thanks, Pascal. Thanks, Brad.

Thank you. We'd like to thank you all for attending this event. We hope you found it informative. A special thank you to all the panelists and speakers for presenting today. And as a reminder, please take a moment to complete the confidential survey that has been posted in the chat panel. It will also pop up in your browser as you exit. Thank you for joining, and have a great day.