Transcript
relatable human names, whether that's a cookie, which stores information about your session on a website, so you don't have to start from scratch each time, or a worm, which is a self-replicating program that worms between devices. These names help our understanding. Memory Fail, Heart Bleed, Log for Shell, Bit Unlocker, Print Nightmare. For some, these names could trigger PTSD-style flashbacks of emergency patch cycles, overnight incident response investigations, or board requests asking what our plan is to deal with X vulnerability. To others, these names might vaguely ring bells from your RSS newsfeed headlines. Some might remember the ins and outs of a vulnerability just by the name, while others will have little insight beyond how cool or uncool it sounds. What is for certain is that vulnerability names are more memorable than CVE numbers, and assigning names to noteworthy vulnerabilities has improved awareness outside of the security community. But words have power, and assigning names to vulnerabilities has proven to be unhelpful in many circumstances. In this episode of The Art of Security, we're here to discuss the rationale behind naming vulnerabilities and how this has aided or hindered security efforts. My name's Josh Davis. I'm joined today with my usual co-host, Tyler Reguli, and this is The Art of Security. So Tyler, I think first of all, defining the scope is a great place to start with these podcasts. We're talking about names of vulnerabilities, and I want to be clear, are we talking about vulnerabilities only? Are we talking about names of malware or threat actors? And did I accidentally conflate any of those in my intro? So there's only one thing I want to correct from your intro. So we'll start there. There's CVE IDs, not CVE numbers. That one caught me right away. So let's throw that out there. They're identifiers. Exactly. No objections. To me, we're talking about vulnerabilities. I'm not going to put the word software in there because I think some of the most famous named vulnerabilities are hardware vulnerabilities. Now whether or not they're actually hardware vulnerabilities or the firmware, which whether firmware is software or not, is I think an age old debate. They're all based in code, I guess, essentially. But I don't consider malware or threat actors to fall into the same group. I think that's a completely separate conversation. Those worlds have their own problems, but their problems, I think, are very unique and different from the problems that exist in the named vulnerability world. Yeah, that's fair. And we're both practitioners, but I alluded to in my intro that these names now they kind of go way beyond the security world. They are in your kind of regular news to BBC or CNN, picking news, mainstream news source. They'll mention some of these names and even invoke some of the historic names in order to talk about new vulnerabilities. So there is a lot of conflation that's kind of been done here. And I think it's a good distinction to make and maybe one that you can keep me on track with. Because for those listening, I had to remove WannaCry from my intro because I myself had taken the malware to mean the SMB vulnerability that it was targeting. So there certainly is some kind of bleeding over here, which I think we can address as it pops up. Let's start with our positions. And I think, like usual, we're going to be able to debate this. This has got many angles to it. But how do you feel generally about the process of naming names versus CVE IDs? I prefer CVEs. I think CVEs are logical. They're assigned everywhere. It's the year and an identifier number. I like CVEs. Everybody's on the same page when you're talking CVE. When you start to get into named vulnerabilities, you start to confuse things a little bit more. You start to wonder, are they talking about a specific vulnerability? Are they talking about something that somebody else used that isn't a real? Where did the name come from and how valid is the name? I guess is what I'm trying to say. And the reality is that a lot of these big vulnerabilities are created by marketing teams to promote a vulnerability that a company has found. And so they are designed to create hype. And hype isn't good in the vulnerability world. You want to operate based on fact. And you said it yourself. These make mainstream news. They make it to boards. They make it to C-level employees. They wouldn't normally talk about a CVE and what that means. But because it has a name, it takes on a life of its own once you name it. And whether or not that hype is valid, suddenly that's the thing that everyone wants you to focus on because it has been named. And for some reason in our minds, something that has been named is always going to be more important than something that hasn't been named. And I think that ends up causing a lot of problem when you consider how minor some of these vulnerabilities have been overall and how little impact they've actually had on the real world. So as you were talking, half a sci-fi reference came to mind that you have to be able to name something in order to control it, to have power over. And I can't remember where that's from, but hit us in the comments if you remember or what I'm paraphrasing. But have you always had this opinion that IDs over names? Because I don't know if you're a numerical savant, but I don't have that same... I can't pinpoint a number of a CVE ID, sorry, to then tell me exactly what kind of software it's in or even trigger my memory, even if I've been on a huge deep dive on the CVE ID or I've done numerous investigations off the back of it, I don't recognize the ID. So I don't, there are ones that I, you know, that do stick out in my mind that I come back to it. I'm like, if I see the CVE written out, I'm like, oh yeah, I remember what that is. Do I know them to recite them off the top of my head? Not usually. But a lot of the time you don't know that with some of the named vulnerabilities either. And I think the bigger problem is who decides what vulnerability gets a name. You know, if we had a CVE naming authority and we had rules around how vulnerabilities are named and we said vulnerabilities that have this amount of risk associated with them get a name and vulnerabilities that have no risk don't get a name, I'd probably be okay with that. But again, unfortunately it goes back to who creates the names and it's typically marketing teams who are building websites, you know, flashy graphics and icons and, and then the researchers information is put underneath. And the problem you have is you get a lot of vulnerabilities that are either no risk that get named or a lot of vulnerabilities that are academically significant, but have no practical application that get named because we've seen quite a few come out of academia that have been named, which is another place that seems to like to name them. I guess they probably end up getting more funding dollars for their research after they name a vulnerability and announce it. But because we don't have any centralized way of doing it, it becomes messy and we haven't hit that point of messiness yet in the vulnerability world. But, and I know it's one of the places you like to talk about, let's take threat actor naming completely different from vulnerability naming threat actor. Naming is one of the messiest things out there so much so that we saw two of the major players in that area come together and say, Hey, we're going to start releasing mappings of our names. And now even then not, we're going to start using the same names, which would make way more sense. We're just going to help you map our names to avoid as much confusion. And I don't, I want to avoid us ending up in that same place in the vulnerability world, because I think we've both seen how messy it is in the threat actor world. Yeah, definitely. And I could talk all day on the limitations and pros and which ones I like and don't when it comes to threat actor names. But that yeah, that does seem to be more of a recent the last kind of five years or so that's become a kind of battleground that researchers or more accurately, the marketing teams might be fighting over to kind of, yeah, I have an action figure from a trade show, I think I've mentioned before that is one of these threat actor profiles. And I think that kind of shows how far this is bled over into what's helpful from practitioners perspective and what's helpful from sales and revenue and leads or brand awareness perspective. But I did ask want to ask that question that did you always feel this way? Because I do think that we it has been maybe a sort of a slippery slope, as awareness has increased, mainly based on high profile breaches, and then the names that get slammed into the headlines, the marketing teams have encouraged researchers to really push naming of things. And maybe because I will put my marketing hat on those who've listened to many episodes know that I have had some experience in technical product marketing. So I will, I will represent that that angle later. But I think for now, if we could just maybe look at some of the vulnerability names to kind of go through that process of kind of where, you know, maybe ones we think are good names that we think have kind of been helpful or beneficial in some manner, and ones that have maybe completely broken that mold, so we can maybe lay out the problem a little bit better before we go behind as to why, why we're at this position that we're at. So I think one, for me, it's in the sock, when I was in working in the sock, when I'd see an alert come through, that would have a certain name in so let's use eternal blue. As an example, I instantly know what I might be what I'm gonna be looking for when I when I open this up, you know, I don't need to go and Google what the CV numbers is to kind of work out what it is, of course, that's there if I need to kind of go into the ins and outs. But if I've seen eternal blue, many, many times, it takes me right back right to where I kind of need to be. And that's why I think historically, these things have been helpful. And it's only in the last four years, I want to say that I started to feel like it has become a more of the marketing battleground. But the eternal blue straightaway tells me and I've really had to think about this name convention is quite subconscious. And initially, but blue tells me windows, typically what I think of anything that has a blue in the vulnerability like eternal, I just had to think about that one. You know, it's always there. I didn't read that that part seems a little bit less helpful, but at least I'm directed. In some way, my mind is jogged as to what I'm going to be looking at. So are there any examples that you think are fantastic that kind of fit that mold, and then maybe the ones that we outlined to kind of prove where the issue is? Probably the one that I think makes the most sense to me, if I have to think about them, is probably print nightmare. You know, right away, you know that that is going to be print related. And it's going to be problematic. And I, you know, I do think there are some that that makes sense to be named over the years. You know, some that we've had that definitely made sense. It's just, there's so many that don't. And I think that's the bigger problem I have. I mean, I've worked with people who have named vulnerabilities, they've they've put out pages for them. So I, you know, saying I'm against it, makes me probably a bit of a hypocrite, since I was working for a company that did that. But in that case, you know, they were variants of one that was already named. So they were given variant names. And I think that makes a little more sense to if you have a type of vulnerability or variations that play off the first one, and the first one has been named, I think it does make sense to name the subsequent ones. So you can say, hey, these are all related group them. But overall, I think the problem is, is we've seen too many vulnerabilities that are named that, and this is a word that I like to throw around a lot end up being nothing burgers. And I think that's the problem is that we just keep running into, you know, vulnerabilities that either we can't prove have ever been to me, if vulnerability is important enough to be named, it had better have been exploited at some point, or have presented real world risk. One of those things should probably be true. And we've seen many named vulnerabilities that have never been exploited in the real world. They've been exploited for research purposes, they've been exploited in labs with pristine conditions, you know, the academic world has exploited them. But we've never really seen them out there. And I mean, I want to go out there and say, you named vulnerabilities are not new. That's, that's, I think, the first thing. I think the difference is that a lot of the time what happened, you know, is the exploit was named, and the vulnerability that was there adopted the name of the exploit. And that brings me back to thinking when I first started playing in computer security, in the late 90s. And you had things like teardrop attack, or, you know, the ping of death, or Smurf, Fraggle. These were all attacks that you know, because you downloaded Smurf.c, you downloaded teardrop.c, you compiled them. And that was how you, you know, how those exploits spread around. And that was the file name. And so the the file name became the name of the vulnerability. But in terms of CVS, right, we've had CVS since 1999. They are 27 years, essentially, I think, as of September, it'll be 27 years. And it was only in 2014, I think that we started getting this, this marketing hype naming going on with Heartbleed being the first one. And even with Heartbleed, there's not a lot of, was it exploited? Probably. Is there a lot of evidence that exploitation occurred? Not really. You know, some of the other big ones. And it's interesting, because being in the vulnerability management space, we get requests for coverage. And you get a lot more requests for coverage, when a vulnerability has been named, than you do for a CVE. Again, risk doesn't matter. Active exploitation doesn't matter. It's got a name, and that name somehow gives it power. And that that means people request it like the number of requests I've seen for things like Spectre and Meltdown and Rowhammer. And names, right. But in reality, there's not a lot of exploitation. There's not a lot of breaches, you know, attributed to that. They are named vulnerabilities that exist, but they're not out there and not talked about that much. You know, even Print Nightmare, which I mentioned, wasn't necessarily as widespread as people expected it to be. Spring for Shell is another one, I think that some, but you know, not as far as the hype around it would have led you to believe. So I think there's a lot of them that that's my biggest problem is the practicality of real world exploitation or the risk that it actually presents to your environment. And again, like I said, at the start, I think I'm fine with naming things based on importance and risk and criticality. But randomly, because company ABC or company XYZ wants to name something. That's a that's a really lousy reason. Yeah. And I think that's the thing I like with the names is when they kind of tell me something about it. So that's kind of why yeah, I think night print nightmare is the print part does give me something it points me straight to print spoolers because of how many remote execution exploits we've seen in those. But nightmare doesn't really tell me anything apart from Oh, this sounds like they think it's going to be really, really bad. And we're probably in a state now where it's kind of boy who cried wolf scenario where if somebody does say this is the biggest exploit that is going to change the whole internet. There's so many vulnerable devices and they're being legitimate about it. How can you go from nightmare? Like how can you be more emphasized further? print hell? I don't know. But I think we've kind of gone to the very edge of, of, of hyping up these based on perceived impact or potential impact. And often that impact ignores the prerequisites or the steps that it takes to get to impact. So you mentioned spring for shell. So the shell tells me that there's a web shell that probably going to be able to be created as a result of this, and you're gonna get full remote code execution on here. And you can do do lots from that. So it's kind of there's a huge impact. It doesn't tell me if that's a kind of one and done exploit. It doesn't tell me how it can be mitigated if everyone is automatically vulnerable to it, or if they had to like expose an admin portal and have the standard password there. Maybe not the best example, but something to make it really open and basically go from. So it was that one spring for Joe, was that a Java based one, like the local spring framework? Okay. So often, I think they're based on like the the hype comes from the availability, like how many this go on? How many people are using the spring framework? How many people are running JavaScript? And okay, let's assume all of those are vulnerable. It doesn't take into account the extra steps that would mean the attack actually reached this this vulnerability. So yeah, I think that the hype is is real. But there may be is this a case of like, like what came first, because I think you point at 2014. And I'm trying to wrap my brain as to the event that caused that. But I always want stands out for me as the Apache struts remote code execution, the Equifax breach as being one of the ones that people started, I want to say people, I mean, outside of the security community, execs, and kind of less technical leaders start to take note because of kind of impact of that Equifax breach, and then be in a fund of finance or very easy to monetize it. So lessons started to be learned. And then that, I would say, was probably where we had a better balance of waiting to see what the impact was. And it either it was, it either happens after a breach, we kind of add the name on, or after it's been mass exploited in the wild, we add the name on. And now it's the other way around. It's like, oh, this smells a little bit like that. So it could be so let's let's whack the name on from the very beginning. Now, you've talked a lot about the cons there, the overhype. And so but I also want to maybe do some justice to that, that isn't more exposure on security issues a win for us? Haven't we been fighting for years about wanting to get budget approval from the board about the board wanting to care about certain vulnerabilities? And then are we being precious when the board ask us, hey, so and so in a in a networking event asked me about this new SMB goes vulnerability? What are we doing about that? Because it's all over the news cycles. So are you being a bit of a Scrooge? And actually, there are some wins and benefits that we've had here. Or is the pendulum completely taken us too far off the edge? No. There's so does security need exposure and acceptance at a broader scale? Yes. Do we need every board member and every C level employee to realize that security probably in many cases trumps almost everything else in their business and they need to acknowledge it and treat it properly and resource it properly and fund it properly? Yes. However, I have five words for you that I think sum up named vulnerabilities, the boy who cried wolf. And that's a problem. We need exposure that is good exposure. We need exposure that is realistic. And the problem is, is if you end up overhyping things that are insignificant, and don't impact people, what ends up happening is you start getting ignored when you have critical issues that people really do need to pay attention to. And so unfortunately, I think that's a little bit of what naming vulnerabilities has done for us is that people want to take their accomplishments and elevate them and make them seem important. And that's awesome. The people who find find vulnerabilities are absolutely brilliant people. Sure, some people stumble into them. But a lot of people are researchers who put a lot of time and effort and energy into it. And they want their credit and their do their credit. The problem, though, is that the rest of the world, the non security world, again, the name gives it power. And a lot of these things don't have the reach and the power that you'd expect them to. And so we end up in that boy who cried wolf scenario, quite often with named vulnerabilities. And that's only going to hurt our industry. In the long run, it's only going to hurt our security teams, when they start reacting to, you know, media hyped vulnerabilities, because they have names. And so I think it's actually very detrimental to us. That's totally fair. And I think that being asked about the latest vulnerability that's that's in new site was something that happened to us all the time in the sock. And we'd have to have a response to Oh, no, we don't have coverage for that. It's literally just came out, we don't even know what the proof of concept is. But I'm quite sure it's a derivative of another Apache stress scale in that example. So we're going to exist in content should be able to catch it. So those I think the people who are asking those questions, they want to get involved in security, or have they want to dip their toes in and they want to kind of have those conversations. But they don't always have all the they aren't completely well equipped in order to have the kind of the right security conversation. I think it's a perfect time for us to be having this conversation before the media kind of runs away, because I will, you said Boy Who Cries Wolf. And I think that means it's time for me to put my marketing hat on. Because let's be honest, it's the marketers, it's the sellers, it's maybe even execs who just want exposure, who are pushing the naming of it more so than the researchers, researchers will often, in my experience, and I work with the fortune intelligence research experts really closely, fire, the fire team, when they discover new things, and we create community threat intelligence content that we can push out on our blogs, and occasionally we'll reach out to news publications and advertise this to them. You know, sometimes the perceived searcher will tell me, oh, I'm calling it this because I found a string in the malware, or that tells me that's what they want to be, they want to call it, or, or I'm calling it this, because it kind of behaves in a certain manner. But often they give it to you. And they just say, you know, technique abusing, dislegitimate remote access software. And here it is type of thing. And then I know that we are all encouraged for Oh, what are you calling this? Oh, you don't have a name for it? Let's let's think about that. So that I think that it's fair that there, this is where all the pressure is coming. And maybe responsible disclosure hasn't expanded its scope into marketing in the same way it has in the kind of, you know, first disclosed it to the vendor, they can get a fix in before kind of going public. And then when it goes public, it's almost like gloves are off now, now go crazy, as long as you follow those first few steps. But it's, it's a symptom, it's, it's a symptom, not just of the marketing team, it's also what the publications want. We live in the three second, five second tension span. We are kind of, we don't when we're when we're dealing with PR, we're doing PR pitches, we don't I don't always get the most insightful questions back, tell me that this person understands security or technology. Those ones almost always it's the flavor of who are you hitting, who's being impacted by this, which verticals and and what size company, blanket response. But sometimes we get the more nuanced kind of things like, oh, this looks exactly like this one. And so there's a big difference between the level of understanding of the security of sort of security commentators or publications or just general news publications that are maybe exacerbating this problem, because then they'll take the most sensational article that you push out. And actually, you're incentivized sometimes to overhype things that you personally don't think, I'm not saying we do this, I think we find the balance really nicely. But there is clear temptation to kind of overstate the impact of this, because you know, it's going to be forgotten in 10 in a few weeks time. But you might get some extra clicks, some extra marketing leads. So how do we balance the pressures here, Tyler, and maybe if I'm if I'll represent marketing and sales, if you want to represent security here, and we can have it out for the last five minutes. I don't think you can balance them. Unfortunately, you either are. You're either in the hype camp or you're not. And some things warrant the hype, some things are critical enough that they need to be hyped up. But you're right, there's a lot in the news cycle that doesn't need to be. And unfortunately, the only way to get people to talk about it is to falsely hype it. And giving it a name is a great way to do that. Because again, names give them power. But I don't think we'll ever get away from that. You know, it doesn't matter what it is now people's attention spans are shrinking. Just on that as well as what's the pace of breaking something and the risk that another researcher is seeing the same thing, and we'll talk about it first. So maybe we push publicly sooner than we should, if we could have waited to see what the real impact would be. And so you don't have that complete data set. It's free market capitalism on vulnerability names. Yeah. I don't think we've seen a lot of named vulnerabilities that are being irresponsibly disclosed. Maybe there's there's an exception in the news right now. If you pay any attention attention to Nightmare Eclipse's GitHub, who has given us plenty of named vulnerabilities in the past little bit that that are being dropped without patches available. But I think in most cases, unless they've been detected in the wild, we have seen people say, Hey, look, this is a vulnerability, it has this name, we did work with the vendor, here's our disclosure data at the bottom of it. So I don't think the naming has anything to do with sort of rushing it out or breaking responsible disclosure as much as it's again, just it is a way to get those those eyes on the story, which is always what marketing wants to do. Right. And this is nothing new. I back in 20 years ago, actually, I was just scrolling through mailing lists and forms one night, and noticed that somebody had released a vulnerability that was pretty insignificant. What it was was if you had internet connection sharing turned on, somebody could send a request. So for anybody that doesn't know, used to be that Windows like Windows XP had internet connection sharing. And if you had two NICs in your computer, or you had a modem and a NIC, you could share your internet connection to other computers and your Windows XP computer would basically be your router. And at the time, the internet connections sharing or ICS, that service was tied to the Windows Firewall Service, they were either both on or both off because it was one service that started. Somebody shared an exploit that if you were the host behind it, so if you were using the Windows XP host as a router, there was a request you could send that would crash the service. And that meant that when internet connection sharing turned off, your firewall turned off. And so I noticed it at night, I sent it out to everybody. And I wrote a blog post about it for our company blog at the time, and just said, Hey, there's this, you know, this thing is circulating, be aware of it, because I had just come the year previous from from working in IT with college students, and it was very common, you had one network jack in your room, so you'd turn on internet connection sharing and put your other devices behind one of your computers. It was very common in dorm environments at the time. And what ended up happening was a journalist picked up my blog post and ran with it and called it the Windows Fallen Firewall and made it seem like people's firewalls were very easy to turn off. That led to that led to another journalist running a story about how we were spreading so much FUD and I should be fired. And I, to this day, will not speak to that journalist. But the one that that said it was all FUD. But, you know, that was an example of how it went from a technical blog post on a topic to a journalist headline to get attention to another journalist wanting to get attention and just shows how the issue can sort of exacerbate and blow up over time. And I think that that's what we're seeing with named vulnerabilities, you know, starting with Heartbleed in 2014. That's why I gave the 2014 date is that was Heartbleed. And we've just seen it grow, and they've become more and more prevalent every year. And it's, it's all about eyeballs and clicks and all of the things that are wrong with the internet. And it's, you know, it's, it ends up being kind of like social media. If you look at Reddit, right, everyone reads the headline and immediately comments, nobody reads the article anymore. Whatever the headline says is the truth, nothing but the truth. And so I think named vulnerabilities are a bit like that. Nobody bothers looking into the risk or the criticality or anything else. They see the name. Oh, no, it's got a name, we have to act on it. And suddenly you have security teams scrambling because they're bored and their C levels are yelling about it. Because it made CNN or the BBC or CBC, depending on your country. And that is just problematic. And the easiest way to stop that from happening is to either introduce a body for naming vulnerabilities, so that only the important ones get named properly, or to stop naming vulnerabilities. We're never going to stop naming them. And as we've seen from threat actors, we're never going to get people to agree on names. So we're stuck with what we have, but at least we can shed some light on how awful it is. Yeah, I think you're right to call out that this is kind of a symptom of all the worst parts of the internet and attention spans these days. Because it's not just vulnerability names, I can even think about in depth write ups by researchers when they're looking at certain vulnerability where they might have a tendency to overhype the impact. And even when they've done a fantastic breakdown of everything, they might ignore certain details or just do it just to be a bit sensationalist or a bit. Yeah, the world is ending. I think that often people in security, we can be a bit guilty of, of proclaiming that because kind of the world is ending for us every other week, and we've got to deal with it. But yeah, if this has been a really interesting exercise, because in doing so and do my research, I started thinking, what do I like about the naming conventions or that loosely form because there's no agreed name convention here, but they do some do seem to form and latching on to what you said about we probably need a confirmed way of doing this and agreed upon framework. Some of the bits I picked out as kind of key takeaways is ways you can use what the frameworks that the naming convention rules and schema that is kind of forming organically, but would really benefit from being nailed down. And I've come up with four points I want to share with with the listener. So, you know, when you see when you're reading an article in the news, sorry, vulnerability in the news, I think you can ask yourself these four questions and it will be helpful, but for you to take a step back and work out how big this impact is and then orchestrate your response accordingly. And one is, does the name describe the impact or the exploitability? Is it telling you that this is ubiquitous? Or is it telling you what the outcome could be? And then with a pinch of salt, looking to why they think that or why they're giving it that name? Is it boring from a famous vulnerability? This is a double edged sword in that if heart bleeds, everyone picked up heart bleeds on the news, and let's call it some Citrix bleed or whatever the bleed is to jump on the back of that hype. But actually also, if it is really, really closely linked, then that's going to help you and you can go and look at your previous defenses for said name vulnerability if they're still applicable or they have some overlap there for the new derivative. Is there, and we're condensed down to three, is this a class or a single bug? I think we are guilty of this pushing into almost names we're giving for techniques rather than names for vulnerabilities. And that distinction can be really hard to kind of square. So I think the more we use something, the more it kind of becomes its own technique, but we still give those words. So like bleed being a memory, a memory bleed issue. So it could be like a buffer overflow, or it could be data flowing elsewhere for exfiltration that makes it easier. That's helpful in telling us the kind of the format of the bug, but a shell. Yes, it takes the impact, but that's, that's really more of the kind of technique that we're highlighting rather than the bug of vulnerability. Any final words of wisdom or to attach on to that list for the readers at home, because we are not near defining a framework and I want to get us there. But for now, how can people temper expectations? For people who are thinking about naming vulnerabilities, I really want to, you know, sit down and argue the boy who cried wolf. Don't hype things that don't need to be hyped. But if you have a, you know, a legitimate issue, something that that is critical, something that doesn't need to be addressed. I think that there is some validity in giving it a name, because again, that gives it power. But people who are just hyping things to hype things because they want the attention, just stop. Yep. And we can all do a good job of that. Whether you're the researcher, whether you're the marketing person promoting it, or whether you're the news publication sharing it. The current trajectory, this will only get worse. So it's a good conversation to have and keep having. Great. Well, thank you very much, Tyler. It's been a pleasure to get you all to myself two weeks in a row. I think we are on the horizon of returning to some external guests again. But thank you, the listener, for taking the time to be with us today. This was the Art of Security podcast. My name is Josh Davis, and thank you, Tyler, regularly. We'll see you guys in the next two weeks. Transcribed by https://otter.ai
