Defense in Depth: DDoS Solutions

How seamless are Distributed Denial of Service or DDoS solutions today? If you get a denial of service attack, how quickly can these solutions snap into action with no manual response by the user?

Check out this post for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark (@dspark), the producer of CISO Series, and Geoff Belknap (@geoffbelknap), CISO, LinkedIn. Our guest is Alastair Cooke (@demitasenz), analyst, GigaOm.

For more oon the criteria you should be considering when looking at DDoS solutions, please check out GigaOm’s Key Criteria. And for their full analysis of the marketplace of DDoS products, check out GigaOm’s Radar.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our podcast sponsor, MazeBolt

Mazebolt introduces a new standard in DDoS coverage, automatically detecting, analyzing, and prioritizing remediation across the network, doubling coverage, and virtually eliminating DDoS exposure without shutting down organizational operations. Mazebolt’s continuous defense supercharges the performance of CISO’s as well as the mitigation solution installed.

Full transcript

David Spark

How seamless are Distributed Denial of Service, or DDoS, solutions today? If you get a Denial-of-Service attack, how quickly can these solutions snap into action with no manual response by the user?

Voiceover

You’re listening to Defense in Depth.

David Spark

Welcome to Defense in Depth. My name is David Spark, I am the producer of the CISO Series, and joining me for this very episode is Geoff Belknap, who is the CISO over at LinkedIn. Geoff, let everyone hear your voice.

Geoff Belknap

Hello, David, and hello, CISO Series fans.

David Spark

I am glad that you are here, and I’m glad that we’re finally talking about this topic, which, it’s weird, this is a topic that’s been around for a long, long time, and, yet, doesn’t get much talk today, and we’ll bring that up, by the way. I do want to first, though, mention our sponsor. Our sponsor is MazeBolt who actually operates in the DDoS space, so you’ll hear more about them later in the show. As I mentioned, our topic today is DDoS solutions, and I posted something about this after speaking with our guest, who is a analyst with GigaOm, who wrote an entire report on this very subject. So, we got the right person for this. What was interesting from the comments about where the DDoS solution should be placed, we got comments of how automated is the DDoS solution? At what level forensics can you do after the attack? Geoff, I’ll just ask you now, or in past roles, how much visibility have you had into any DDoS behavior?

Geoff Belknap

I’ve certainly spent a little bit of time on it. I’ll say, at LinkedIn, I don’t spend, personally, a ton of time on it, it’s largely handled by other teams. But I’m really interested to have this discussion because over the last ten or 15 years, if I roll my career clock back a little bit, this was a really major issue that people spent a lot of time and a lot of money on, thinking about strategically. Now, I think, for a variety of reasons, this has sort of turned into something that not everybody worries about the same way they used to, and I think it’d be really interesting to get into this with our guest about why that might be, and how we should think about it now.

David Spark

I want to preface, before I introduce our guest, we had a long conversation about how to pronounce his first name. And he said: “whatever way that you pronounce it is the correct way”. And I said, “no, it’s your name”, he goes, “no, no, but it’s you who take ownership of it.” So, I think we may be pronouncing multiple different ways through this entire recording. Hopefully by the end of the episode, he’ll tell us the way he prefers to hear it as.

Geoff Belknap

I’m just going to call him our guest. He who shall not be named.

David Spark

No, he’s going to be named. He is an analyst with GigaOm who wrote a phenomenal report on DDoS, so we got the right person. It is Alastair Cooke. Alastair, thank you so much for joining us.

Alastair Cooke

Thank you, David, and I call myself Alastair, but I do answer to all kinds of different names at times.

Geoff Belknap

There is a preference.

David Spark

There is a preference, and I think I got the right one at the beginning. Excellent.

How do we handle this?

00:03:04:03

David Spark

Stu Hirst, who is the CISO for Trustpilot said, quote: “I’m looking for three things with a cloud-based managed DDoS solution. The first is an extremely quick response to scrubbing the traffic; second, the right alerting to tell us something is happening, and it’s being responded to; and, lastly, data after the fact to inform us what the heck happened.” And Evgeniy Kharam of Herjavec Group said: “DDoS solutions should be cloud-based and not on prem, and they should be managed service or as a service. This way, customers shouldn’t be concerned about configuration.” I’m interested to know your take on that. And lastly, Eric Haberkamp of GigaOm said, quote: “DDoS mitigation is a pass-through cost from a cloud provider’s network service provider.” So, I’m going to start with you, Geoff. They’re kind of just outlining that this is something that has to be handled by the service provider predominantly. I mean, it should be; there’s no reason it should be at the user level is there?

Geoff Belknap

No, and really it can’t be. I think the reality is that it really depends on your business and what you’re defending. I think there are a lot of different options here, and certainly there are a lot of interesting opinions in the piece. But, for me, I could see what works for LinkedIn and the other companies that I’ve worked for. What we did at each company that I’ve worked for in the last ten or 15 years is very different from each other, and I think there’s good reason for that. I’m really interested to hear Alastair’s take on this.

David Spark

So, Alastair, your take.

Alastair Cooke

Well, I think one of the really interesting things was Stu’s comment that it doesn’t want to be involved in actual defense. That’s really important in modern DDoS protection, because with things like post attacks where a single attack vector’s used for 15, 20 seconds, maybe three or five minutes. You can’t manually mitigate against those. And I think that’s one of the themes we’re going to see in this, is the idea that modern DDoS protection has to be automated to cope with modern DDoS attacks. But I think one of the conflicts, then, is that these managed services that are very responsive aren’t very aware of the application they’re protecting. So there’s two layers in here, and I think we will sees some discussion around this difference between the automated cloud stuff and what you might do on premises that’s more aware of the application that’s protected.

David Spark

Can you dig into that a little bit deeper? What are you referring to, and maybe give us an example like: if it’s protecting this application, this is a behavior; or if it’s protecting this, this is a different behavior.

Alastair Cooke

The thing that suits being in the cloud really well is the high volume, what’s usually referred to as volumetric attacks, where lots of traffic is trying to flood some kind of connection. Often it’s the connection to the on-premises resource or in-cloud resource, and that suits being out in the cloud and being predicted as close to the attacker as possible. These are things that are typically attacks at the network layer, trying to exhaust TCP connections. But there are a whole bunch of DDoS attacks that are more targeted at the contents of the actual application server. There might be something that targets a specific vulnerability and a PHP stack as just a random example of something I’ve built – a PHP stack, notan attack on it. Then you need some mitigation that is aware that this is a PHP site and here are the valid things that could be requested from the site, versus the things that should be immediately denied. This is more where, though, web application firewall capability comes into DDoS protection.

David Spark

Now, Geoff, throwing to you, I mean, are you, or your team, aware that, hey, a DDoS attack attacks different vectors of our applications?

Geoff Belknap

Absolutely. Most people, when they think about DDoS, though, are really thinking about that volumetric attack, and that’s the kind of stuff that gets hyped the most. I think back to the Mirai botnet which was, I guess, a couple of years now. That was really impressive for a bunch of reasons, but both technically impressive how they amassed this capacity to distribute a volumetric attack, mostly through compromising other machines and repurposing them for attacks. Also very impressive just in terms of sheer volume of data they were able to push. That’s the kind of thing most people are worried about, because even if you’re leaning on typical volumetric defenses which, let’s be honest, in most cases just allow your cloud provider to absorb it because they have more band width than Santa Claus. I think most people can honestly be very comfortable that if you’re in a modern cloud provider, they probably will be able to absorb it. The hard thing, and the thing your cloud provider and your telecom provider cannot necessarily absorb for you is if there is an attack based on a flaw in the way that your application runs. They’re sending you a malformed header or something like that that just causes you to exhaust all the resources on your end, that is much more complicated, and I think that’s the thing that most people don’t spend time thinking about.

If you looked at the problem this way.

00:08:07:09

David Spark

Kaustubh Medhe of Cyble said that there needs to be a tiered approach with DDoS mitigation, starting with the ISP level, which we spoke about, and then on-premise, and then with each web server. We’ve kind of touched upon this already. But, also, plus periodic automated testing to make sure the DDoS solution is actually working. And this seemed like the best sort of solid advice, if you will. Tony Chryseliou of Sony commented about something that I said, which I was kind of echoing you, Alastair, so I’m going to want to get your take on this. I had said in my post, “users are required to manually react when an attack is actually happening.” And Tony responds, “this is simply untrue. Unless the person is thinking of a solution that the customer has to host or maintain, which is insane, the DDoS solution should be as far away from the customer’s assets as possible.” What do you say to that, Alastair?

Alastair Cooke

I agree that the DDoS solution should be as far away as possible, but the reality is many of them aren’t. My particular comments around that were driven by a DDoS attack against some providers in New Zealand, so several of the services. So, my bank and the New Zealand post office that I use for tracking deliveries were both hit with a large DDoS attack. One of the press reports about it was that the problem got worse because it was a manual configuration change in one of the DDoS products, and this was made by a staff member at the company. This, to me, is a symptom that this is a very poor implementation of DDoS, and that was what triggered my real thoughts about, why are people making manual changes in the DDoS? It should be a managed service that’s delivering this protection without human intervention along the way. I do want to know afterwards, and I particularly want to know what attack vectors were used and whether I can build my site better to mitigate them. And I want that continuous feedback to improve my system, but I don’t want to to be involved in the act of mitigating. Clearly, that was what was happening, and for the particular company that was covered in the press, their problems were made much worse by that manual change, which is exactly why I don’t want to do manual changes under duress.

David Spark

Good point. Now, one of the issues that came up again and again was the having or the lack of forensics for a time. Geoff, let me throw itto you. In general, when a DDoS attack happens, what’s the kind of stuff your average security person and network administrator would like to know?

Geoff Belknap

What would they like to know? All kinds of things. Like is there a pattern or is there a forwarding header? Is there some consistency to the attack that you can either attribute to an actor or attribute to a piece of malware or something like that? But now let’s talk about the reality. The reality is, you get none of that, unless you’re the DDoS provider. And even if you’re the DDoS provider, your job, number one, is throwing away as much traffic as possible as fast as you can, and trying to also make a very high precision decision about what is garbage traffic and what is good traffic. Because if you just turn the website off, you’re not exactly adding much value as a DDoS provider. I am definitely in the category of, I would like all that information so I can understand why I was targeted, why this happened. The reality is, why I was targeted and why did this happen, in most cases is, nobody knows, just because. And I think that’s unfortunate, but professionals in my space would like to know more.

David Spark

Yes, honestly, if you keep having that response, nobody knows it just happened, how the heck do we get any better?

Geoff Belknap

The Internet is a wild and mysterious place, and certainly it is hard to understand why anything happens sometimes. But the reality is, it comes down to two main things. You’re either dealing with a ransom where somebody says, “if you don’t pay me money, I’m going to DDoS you.” In which case, you should probably already know why that happened, and hopefully you can mitigate it with a cloud provider. Or, two, it’s random, and somebody on 4chan, 8chan, 16, however many chans there are today, decided that for some reason, political or[UNSURE OF WORD], they were going to take your website offline. And there’s no threat intelligence that’s going to help you manage that, which is why we all have to buy these services and have teams that can mitigate these things.

Alastair Cooke

I think the why is less important than the what happened, in terms of the forensics, because that’s what drives your future decisions about how you protect. One of the things that struck me was that there are varying degrees of risk for organizations around DDoS that aren’t necessarily about size. So, what’s the objective for the person? The why is really about how much of a risk are you at of being attacked? So, if you are a large bank, you’re at risk of those ransom attacks. If you’re an oil drilling company, you’re at risk of the cyber activist who wants to highlight the fact that you’re doing something terrible for the environment. As an organization, you need to do an evaluation of what’s the risk for us? Are we heavily dependent for protecting life with our IT systems? Because there’s a whole lot of DDoS attacks that have been going out against health providers, although ransomware’s more commonly attacking them. It’s got to be a risk-based assessment to look at what’s the right solution for you, and we’ve definitely seen in the comments that there are a lot of different opinions about what the right type of solution is.

Sponsor – MazeBolt

00:13:32:21

Matthew Andriani

The mitigation strategy of many organizations is designed to be reactive.

Steve Prentice

This is Matthew Andriani, CEO of MazeBolt, a DDoS security company with a straightforward message: “reactive mitigation strategies are not enough. We need more.” This company offers a unique product called RADAR that provides ongoing vulnerability detection, and just like its name, looks ahead to find danger before danger finds you.

Matthew Andriani

What RADAR does, what MazeBolt does, is we continuously simulate DDoS attacks against your production environment without any downtime to your production environment, and identify those vulnerabilities, that they can be closed quickly and continuously in your DDoS protection solution.

Steve Prentice

MazeBolt’s Red Team methods have been recognized in the industry as one of the most efficient techniques for DDoS testing. And in 2019, they released the next generation of DDoS validation called RADAR.

Matthew Andriani

So, RADAR is a patented product, it’s the only one of its kind. It’s a SaaS product. It’s easy to deploy; we’ve got a managed service for the product. So we manage the vulnerability identification process and the remediation process with the mitigation vendors, and we make the transition for any customer who wants to have full protection as smooth as possible.

Steve Prentice

For a risk-free proof of concept demonstration, go to MazeBolt, M-A-Z-E-B-O-L-T, dot com.

What aspects haven’t been considered?

00:15:08:16

David Spark

Kerstin G. Mende-Stief of data-disrupted said: “Hardly any manufacturer is able to communicate the real added value of their solutions or address real world concerns. Listing features is much easier.” So that’s kind of a global statement there. Richard Rushing, CISO of Motorola Mobility said: “Use your cookies. You give each customer that comes to your site a cookie, or maybe 74 of them. If traffic does not have cookies, drop it, it’s bad.” I’m going to throw it to you first, Alastair, on this. One of the complaints that you said is that it doesn’t address customers’ real needs, these DDoS solutions, when we were talking about how much traffic they stop. Also, I want to know your take on Richard’s cookie solution here.

Alastair Cooke

I completely agree with Kerstin. There’s a large number of IT vendors very obsessed about what they do, rather than what customers need. And so often, early in the process, there’s: what do customers need; let’s identify a gap in the market? But then they get very excited about the particular thing they do, the way they achieve what the customer wants. Customers don’t care, that’s your responsibility. Particularly, as we see cloud services where it’s all about, what are you actually delivering as a service? I don’t care how you deliver it.

David Spark

I can understand it, because there’s this kind of a spectacular nature of how you deal with DDoS problems. Just the sheer volume of it is: hey, we’ve got to tell you about this; it’s kind of spectacular.

Alastair Cooke

Yes, and we see it across the spectrum of IT products. One of the things I see in management vendors is often a focus on: look at all the wonderful metrics we’re gathering. Okay, so, tell me what I can do with those metrics. But look at all the wonderful metrics we’re gathering. I want actionable insight, preferably insights that you take action on directly, and this circles back to what I want from a DDoS provider. I don’t what to have to care about all of the knobs and bells in it. I just want you to protect my site, to keep my site up. And we definitely see a little bit of the obsession in the way we describe products around the tech. That’s also us as tech people. We tend to be more interested in the insides of the product. We see this in a lot of the way events like Tech Field Day workers that we’re briefed by vendors about a huge amount of detail in their product. But what really matters if what’s done for the end customer. There’s a disparity, and we, as the people in IT, are partly to blame for this because we’re obsessed about the detail of the numbers inside.

David Spark

Are you finding you have to translate what the DDoS provider tells you it’s going to do, of how this is going to help me, Geoff? Or are they pretty good at saying: hey, this is what you wanted; we’re going to deliver it?

Geoff Belknap

Well, we have this whole other podcast in the network that deals with this issue Kerstin’s mentioning, which is there’s a disconnect between how people are describing their product and how we want to buy it. I think setting that aside, yes, it’s really hard for DDoS providers, I think, in general, to figure out how to communicate well to teams, and that’s just the cost of doing business in security. I think at this point, I’ve just given up, like, that’s going to get better, but it’s never going to really turn heads. Honestly, I don’t know, does that really stop people from buying services they need? I don’t think so.

David Spark

No, because they still need them, regardless. What I’m saying is, you, as a security professional, often have to translate how that will apply in our network, yes?

Geoff Belknap

Yes. That’s part of why security people make the big bucks, so to speak. I think it’s just part of the difficulty. Like doctors have to understand Latin, and security people have to understand marketing jargon. You just learn to go with it. I think the other thing I’ll mention, just about Richard’s comment, is the cookie thing, absolutely. There are ways to use cookies to prevent abuse and sort of build your models, but I don’t see a lot of benefit of using cookies. By that point, if you’re inspecting cookies, you’re probably way too close to your primary application stack to really defend against a big DDoS. I also would say it doesn’t mean don’t use them, but if that’s what you’re planning to defray all your DDoS attacks, especially volumetric ones, you’re going to have a bad time.

Alastair Cooke

This is defense in depth.

Geoff Belknap

Exactly.

Alastair Cooke

And this is exactly how you should be running your DDoS protection. It shouldn’t be a single feature, absolutely. You should have applicationware features like the cookies, but they’re not going to help you against somebody who is doing a SYN flood.

Geoff Belknap

Yes. 2.4 terabytes of traffic, inspecting all of those for cookies, is not going to be the thing you want to do at that moment.

What else is required?

00:19:45:16

David Spark

Paul Stringfellow of Gardner Systems said: “Yes, we need more automation and intelligence in these solutions because our SecOPS teams need help. It’s hard for them to track and react to all these threats at all times.” Well, that’s true. Luis B of BRFibra Telecom said, quote: “Most solutions are really bad at giving you more in-depth insights about the attacks and the traffic engineering related to it.” We can discuss this. He goes on to say: “Most are only reactive scrubbing solutions that only look at the ingress traffic with no context.” And Rustam Bunyatov of DB Schenker said, quote: “We know that disabling a service is not always the ultimate goal of an attacker. It is also used as a smoke screen to hide low volume events, and therefore allow the real breach to go undetected.” I want to start with that last one, Geoff. How often is that the case?

Geoff Belknap

Well, I think it would be everybody’s wish to understand whether that’s what’s happening at the moment that you’re dealing with a DDoS. And the reality is, depending on the line of business that you’re in, most people’s response plans are just to assume that that is what is happening. Or, I’ll say, at least mature organizations that are dealing with either your critical service provider or life safety, or you’re in the defense and intelligence space, you’re building your runbook assuming something else bad is happening, and that this is just intended to distract your resources. How often does it happen? That’s a pretty good question. I don’t know if we have any data on that in reality.

David Spark

No, but I’m sure it’s in the back of your head.

Geoff Belknap

That is a real thing that does happen and has happened in the past. And it has to be something that’s on your mind if you’re running any kind of sizable organization’s security team.

David Spark

But I’ve got to assume the fear is, this is what’s right in front of my face, I’ve got to deal with right now. But, everyone, don’t lose sight, keep an eye on other things too. I’m sure there’s this sense of all hands on deck on this one thing, and that’s the idea, the attacker would want you to do that.

Geoff Belknap

Absolutely. I think this is also why, as I shared a little bit earlier, DDoS prevention is not my team’s primary function. We have a role to play, we’re a stakeholder in how we do that for my organization. But another team, another organization, primarily focuses on executing that. Part of that is so that my team doesn’t get distracted by an availability or a resiliency issue like that, so that we can focus on doing our jobs, even if the site is being affected. That’s the kind of thing you have to do everywhere. And this is why, to Alastair’s point, why it’s really important to have your DDoS defenses as far away from your application stack as possible. Because if you get into a situation where I can’t operate my security apparatus on top of my stack, well then I’m really in trouble. If my team has to sit on their hands during a DDoS because they can’t even execute a security operation, well then the attacker is winning, and we’re in a bad state. I think that really goes also to the discussion we were having about understanding what you’re buying, and what you’re trying to get out of it, more than just what features you get.

David Spark

All right, Alastair, I’m going to let you have the last comment on this. Lot of issues being brought up here with regards to the smoke screen and the amount of information that’s being coughed up. What have you seen?

Alastair Cooke

I think one of the really important things is to have this integration, to be getting some reporting out of the DDoS solution about what’s going on. It should be a, here’s a red flag going to the security team to say that there is a an attack in progress, but it shouldn’t be overwhelming your security team. I think that’s exactly where Geoff’s environment is, is that somebody else is hands-on looking after the DDoS. But I don’t completely agree with Geoff’s point that it should all be in the cloud. The volumetric stuff absolutely should be. But returning to Luis’s quote about this ingress traffic with no context, one of the things that you’re not getting is protection against things that are more visible at egress. So if it’s a cloud service, you’re only seeing the ingress component of the attack, and there may be a return path that you can get some intelligence out of as well. Quite often, there’s an on-premises requirement, or, potentially, what I call in the report a protected internet perimeter where all of your outbound routing for all of your internet access actually goes through a service provider who does some inspection. That’s the alternative to having something on-premises doing the outbound inspection. But there is definitely a use case for outbound inspection as part of your DDoS protection.

Closing

00:24:07:23

David Spark

That is going to bring us to the close of this discussion. And now we come to the point, and I’m going to throw it to you, Geoff, of your favorite quote on our discussion of a DDoS, which, by the way, is clear we just barely scratched the surface on this topic. There’s a lot more to go. What was your favorite quote and why?

Geoff Belknap

I think, for me, my favorite quote is going to go to Paul from Gardner Systems because even though it’s not directly applicable here, it’s more applicable to everything. But, yes, we need more automation and intelligence in these solutions because our teams need help, and it’s hard for them to track and react to threats at all times. That is so true about DDoS, but also everything we do in security.

David Spark

That is true. All right, Alastair, your favorite quote and why.

Alastair Cooke

I like the quote from Tony Chryseliou of Sony, that users are required to manually react when an attack is happening is simply untrue, because I think he’s in the future. But the problem is that the future is here, but unevenly distributed. Other people are not in that future.

Geoff Belknap

Speaking of the future, Alastair’s in the future, and that’s how he knows.

David Spark

Yes. We’re recording this on a Thursday, but for Alastair it’s a Friday because he’s in New Zealand. So he is in the future, and Geoff’s first question to him was, how’s Friday doing? What should we look forward to? Geoff, that was a good question. Thank you very much, Alastair, thank you very much, Geoff. Now, Alastair, for those listeners, has written a whole extensive report on it, where we just barely touched the surface. That report goes in great depth. Links to that report on GigaOm will be available to check out. So please check it out. And if you’re not a subscriber to GigaOm, why aren’t you? There are tons of amazing reports and tons of great analysts, just like Alastair, who give phenomenal analysis. And they do this key criteria thing that I love, that GigaOm does. You wrote the key criteria, right, Alastair?

Alastair Cooke

Yes, I did, I wrote the key criteria for DDoS. The man himself.

David Spark

So, if you’re looking to buy a DDoS product, it actually steps you through the process of what you should be looking for in your purchasing process. And it’s not just for DDoS; they have it for all other product categories as well. So, check that out. Links all available on CISO series dot com for this very episode. You know how you find it? Just type DDoS in the search and you’ll find it right away. No matter when you hear this episode. I want to also thank our sponsor, MazeBolt, who is also in the DDoS space. Check them out at M-A-Z-E-B-O-L-T dot com. Geoff, any last comments about this topic, or a question to either of us?

Geoff Belknap

No, I think, as always, Defense in Depth, we try to go deeper, but there’s so much more we could say about this. I’m looking forward to digging into Alastair’s paper on this. Then I’ll just say, as always, LinkedIn dot com slash jobs. I’m hiring, and if you want to do security stuff, and if you have some interest in DDoS strategy, we’re interested in talking to you. Come find me.

David Spark

Alastair, any last comments, any pitch for your report beyond what I just said?

Alastair Cooke

Well, I think the key criteria’s a really important piece of education, and then the decision making about products we do, the radar series. We do a report that evaluates products against those key criteria we identify. So, the DDoS radar is the final report of: here’s maybe what you should look at buying. And we do a whole lot of these. So I’m writing a lot more infrastructuring ones as well. There’s going to be a huge amount out there. In terms of the close-up with the DDoS, this should be invisible. This is like insurance. We should be paying a bill and being really glad that we never have to claim on it, because no attack gets through our DDoS protection.

David Spark

Good point.

Geoff Belknap

100% plus one.

David Spark

We’re with you on that. Thank you very much, Alastair, who, by the way, I think we just stuck with that pronunciation for the whole show. So, you’re stuck with it.

Alastair Cooke

Well, you can just call me Bruce from here on.

David Spark

Bruce Cooke, Geoff Belknap. Our audience is phenomenal, giving us phenomenal contributions. And, we appreciate it, and also we appreciate when you listen too. Defense in Depth.

Voiceover

We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity. This show thrives on your contributions. Please write a review, leave a comment on LinkedIn or on our site: CISOSeries.com where you’ll also see plenty of ways to participate, including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at David@Cisoseries.com. Thank you for listening to Defense in Depth.