 So Damon, I don't know, you've spoken at Source Boston, you've spoken at DEF CON, didn't you give a 101 in DEF CON two years ago? I think that's how I first was introduced to you. Well, okay, without much ado, I'm just going to go to the next slide. My pleasure to introduce to you Damon Small. Thank you, Ming. So as you can see, I did not go through my normal pre-presentation routine that I normally go through, but that's fine. This will make this much more interesting, I think. So yeah, my name is Damon Small. Some folks know me as Chef. Thanks for coming out to see me. And the title of my slide is Layer 8 and Why People Are the Most Important Security Tool. And I'm realizing, as usual, I'm a little short for that podium, so I'll wander around a bit. Sorry in advance to the cameraman. So first of all, I want to say special thanks to, well, The Wall of Sheep, who sponsors the packet hacking village. It's been a privilege of mine to be a volunteer staffer for the last three years. I love DEF CON and I love this venue. It's a lot of fun, a lot of work, but a lot of fun. Of course, my employer, who is helping me be out here, so shout out to my boss and the rest of the NCC folks that I work with, and my wife and editor. My wife gets to go through all these slide decks that I do, and she takes out the mistakes and makes them suck a little bit less. So thanks, Hun, for reading through it. Last but not least, you. Every time I get accepted to present somewhere after the excitement wears off, you then wonder, like, oh, God, is anyone going to show up? Especially, you know, it's in the afternoon. It's been a long day. So people have shown up, so thank you very much to all of you for sitting through this. And I mentioned that my employer was helping me be out here, which I'm very, very grateful for. So you'll have to sit through a short commercial. I work for the NCC group. We're a large global cybersecurity company, 35 offices. That number in the lower right is incorrect. We released our annual financials a couple weeks ago, and we actually did 244 million pounds in revenue last year. So it was a good year. We have a lot of services. We do a lot of things. We've got 2,000 geeks globally and a lot of offices. And enough about them. Let's talk about me. My name is Damon. Like I said, tech director for NCC group in North America. I've been in IT since 1995, and I started focusing on Infosec in 2001. The dot-com bubble had burst around 2000, so that was a good time to kind of change my career a little bit. And I think I got lucky and thought back then that, well, security is probably going to be a problem for a while, so that's a good area to go into. And I think I was right. Louisiana native Go Tigers. Any LSU fans here? Oh, really? Right on. That was unexpected. I studied music at LSU. I was in Tiger Band and all that. Went to grad school in 05. Spent most of my career in blue team. And I've worked in the healthcare, DOD, aerospace, and oil and gas industries. There's a nice picture of me, which reminds me of a joke. How do you know when someone is a DEF CON speaker? They'll tell you. There you go. Shout out to my buddy Dennis, who's spoken on the big stage three times. All right, so let's get into it. How did this slide deck come to be? I'll tell you a little story about that. I'm a bit of a digital pack rat, and I ran across a white paper that I had written about a decade ago, I believe it was. And I found this old white paper and I thought, well, this is going to be comical because this is old material and it's probably not aged very well and it's not going to make any sense. And I read the white paper and I was shocked to discover that it was actually still quite relevant, particularly in the context of the wall of sheet. Because if you've been over across the hall and you've seen what we do with packet detective and capture of the packet and some of the training we do, we're very much about, you know, basic skills that are important for everybody in InfoSec regardless of what your role is. And especially since our capture of the packet contest is, you know, it's a CTF basically, but you're finding telemetry on a network as it's flying across. So as we get into this, I think you'll see why I thought, hey, the wall of sheet is the perfect venue for this. So yeah, the techniques are simple and old but remain very useful. I like telling stories, so I thought this was an interesting narrative. And WannaCry had just happened when I started putting this slide deck together and a lot of the techniques I'll talk about from the incident from a decade ago are still quite relevant. So quick poll of the audience. How many folks in here on some regular basis will use tools like TCP dump or wind dump to examine network traffic? A few hands, what about something like some of the PS tools stuff like PSXAC or things like that? Yeah, some other hands. I mean, so those are tools that have been around for a while, right? They're not new, but we'll see how, I think they'll be interesting as we get into this. So to start off, I mean, if you work in any kind of IT department, you know, you've got people, time and money are limited and you face a myriad of decisions every day to try and figure out what tools, what technical controls are you going to use? You've got to make purchasing decisions to try and figure out which are the right widgets for your environment. And you have to remain fiscally responsible though, right? So you can't buy everything. But I wonder sometimes if in business, if we spend too much time worrying about which widget to get and we don't spend enough time looking at the human beings that we have in our IT teams and our InfoSec teams. So to start off, the first case study I'll go through, the name of the white paper was actually called Finding the Needle. And so to set it up, it was December 2004 and primary firewall of a healthcare provider failed. And it failed over to the backup firewall. And of course, the networking team was keenly interested in trying to figure out why the failure had occurred. And they noticed a large volume of traffic on port 135. And there was also a periodic burst of internet bound traffic on various ephemeral ports. So there was a lot of traffic on the perimeter on 135 and lots of other high TCP port traffic. So they were trying to figure out, okay, based on that information, what is going on? Of course, a lot of folks immediately suspected something malicious, some malicious software. But we had several technological limitations to deal with. Namely, I heard the previous speaker was talking about spoofed IP addresses and things. So it's kind of funny that that came up. But some of the source IP addresses were spoofed, so obviously they weren't valid packets. So we couldn't figure out from where they were coming. This healthcare provider also had a lot of third party supported systems that they themselves didn't have access to. So they were tenants on their network, but they didn't have control over them. At the time, this shop had something like 8,000 workstations, but healthcare environments are very difficult to manage. And antivirus wasn't necessarily fully functional on all of those machines. And again, many of those were third party supported. Some of this should sound familiar to my two buddies down there. Yeah, it doesn't, okay. And lastly, the networking team at the time. And again, this was what you're going to say this was a long time ago. They had protocol analyzers, but the protocol analyzers were really good at giving you trends over time, but they weren't really good at giving you visibility into real-time traffic on the network. So they were having a hard time sorting out what was going on. So due to these limitations, they couldn't really troubleshoot any further than just saying, yep, something had gone. Horribly wrong. So in that last bullet point there, they begrudgingly engaged the InfoSec team. And I say begrudgingly, at the time, network teams weren't really keen to let anybody else look at their infrastructure or work on it. And the InfoSec team back a decade or more ago was viewed as the guys that managed access and identity. It was really yet. And we had told them, look, we've got some pretty cool tools. We could help you out. But no, you're not a network person. You can't get on there. So after they figured out they were kind of stuck, they engaged us and said, okay, will you help us out? And we were happy to. So what we needed to know was this. From where the traffic came to where it was going, what was causing it and how to get rid of it. Those are very basic questions, right? I mean, that shouldn't be a huge problem. But we couldn't answer those four questions. So I'm going to step through how the creativity of the human beings involved in this, using very basic tools and techniques, were able to answer those questions where the network team was unable to. So the first thing, we had some detective methods. We had commercial antivirus, of course, on the network, but I've already mentioned that it wasn't fully functional on some workstation. So we couldn't depend on it for 100% visibility into our entire environment. We had an IPS and it was giving us some information. I'll touch on that a little more. But interestingly, the most useful thing we had was wind dump, which of course is the windows load of TCP dump that we use on Unix all the time in Linux. So all we did was we got access to a span port near the perimeter so we knew we would see all the traffic. And we just simply ran wind dump looking for destination port 135. That was it. So simple, but it was a capability that we didn't have in other parts of the organization. But from that, we were able to figure out which hosts were generating all that traffic on port 135, which as it turns out was the malicious software trying to propagate to other hosts. So now that we started gathering a list of who the bad guys were, who the bad hosts were, we were able to target individual machines that were infected and try and clean the mess up. We found various self-propagating worms that took advantage of the RBCDcom buffer overflow, and there was also an LSAS buffer overflow at the time, so there was like two different self-propagating softwares exploiting two different vulnerabilities on our network. Now a pause just to say that that is a bad day. One piece of malicious software is no good and two is twice as no good. It looked like Blaster and Sasser, and patches existed, but recall that this was 2004. It's hard to get patches installed on a large environment today. It was even harder back then, and in 2004 we were still going through the narrative of trying to decide, oh, we patch every quarter whether we need to or not. That's enough, right? And even now we still struggle with trying to figure out, well, I mean, it's got to be monthly, right, because that's when Patch Tuesday is. So yeah, the point is we were not patched at all. So just, I'm sure most of us, if not all of us in here are familiar with botnet worms, but just to give a little context before I move forward here, I'll say that a lot of times they'll do command and control through, in these cases, these specific examples that we're using Internet Relay Chat, I think there was a period of time where the only people that ever used Internet Relay Chat was malicious software. So the worm logs into an IRC channel and receives instructions from the bad guy, and then the bad guy can use the zombie computers for other bad things, right? I mean, I'm pretty sure we're all familiar with this. But interestingly, the traffic from the worm propagating and also logging into the IRC channel caused so much traffic that it crippled our network. So we had some information. We knew where the bad traffic was coming from, but we still needed to gather more data. So like I said, we had problems with antivirus not giving us complete data. It really wasn't helping us. We enabled the IRC login event rules on the IPS. You may be wondering why weren't they enabled in the first place, and who knows, tuning devices is hard. And by turning on the IRC login event rules on the IPS, we found three different IRC channels that the malicious softwares were using. Of course, I've obfuscated the IP addresses, but there they are, the three different ones that existed. But because we were blocking the IRC login events, we actually created another problem for ourselves, which was the IPS existed on the external interface of the firewall, such that the firewall had translated the addresses to a routable IP address before the IPS saw it, so at the point at which the IPS blocked the traffic, all I saw was the NAT address. And to figure out what the IRC 1918 address was, you had to go through the firewall logs and look at the NAT tables, and that was a huge pain and very time-consuming. And it was then that we realized that note to self, you should probably put the IPS on the internal interface of the firewall, otherwise position such that you can see the 1918 addresses before they're translated. Again, it was 2004, IPSs were new and exciting back then, so we were still sorting a lot of things out. So, what did we do? Wind up to the rescue again. So we already knew what those three IRC channels were, so it was trivial to, as you see there, to set up a string that would look for any traffic going to any three of those hosts. And we quickly, so we started seeing all kinds of traffic, and it was like, great, so we're seeing more traffic, but if you've ever done wind dump, you know, stuff flies by, and yes, you can write it to disk and grab it and those sorts of things. But we still weren't having very much luck on quickly figuring out where the infected hosts were. So, here's another tool. Anybody use Snort or something similar? Sure you do. Yep. So it's really easy. You can see the syntax there. I mean, it's so easy. I could write that. And all we did is say that, look, we set up a variable that included the three IP addresses of the botnets we are interested in, and we told Snort to just alert us any time it saw traffic going to there. And it was a lot easier to generate a list of infected hosts using this technique rather than going through a bunch of, you know, wind dump logs. So interestingly, as we were going through the logs of the alerts, we would capture packets. Again, shout out to Wallachie. And we started seeing all sorts of interesting things, which is the militia software actually logging in to the IRC channel and getting ready to receive commands from the bad guy. So I won't walk through this, but this is one of those artifacts that during an incident response or during an investigation, you'll stumble across data like this and you get, I don't know, I thought it was kind of cool. And that was one of those moments when I was reading it, you know, more than 10 years after I had written it, and I was like, huh, that's interesting. We can also see, yeah, so the militia software continues to get logged in. There were, on the second line, there were 4,253 invisible users. So I mean, I reckon that means that's how many other devices had logged in. So I mean, by today's standards, that's not a large botnet, but it was still, you know, pretty interesting to see that. And here towards the end of the conversation, it appears that the bad guy sent a command to our host to begin scanning that 10.32 network was part of our network, and it was scanning, looking for port 445 being open, presumably to find other hosts that were potentially vulnerable. In this case, I believe that would have been the LSAS buffer overflow. So we actually saw as we were looking at this traffic, you know, the actual evidence of the malicious activity going on. And of course, for a, you know, bad guy, you know, a malicious user to be successful at what he's doing, he's got to, you know, find other hosts and exploit them. So we see the scan starting here, and then we see where the software actually found other malicious hosts, and there they are. So that was useful because, you know, while the exploit was still taking place, we already knew who those hosts were. And then we see the bad guy continuing on to sending other commands. It looked like this might have been a sin flood against ports 6667 and other ports, so maybe this is somebody that, you know, the malicious actor was interested in taking down or something. But, you know, and meanwhile, you know, our firewall is falling over, and now, you know, we got computers on our network launching sin floods against other people. So that sucked. But so we figured out a bunch of things using very, very simple tools. We figured out a lot of information that other, you know, as I said, other parts of our organization were not able to figure out. So now that we knew all this stuff, now it's time to kind of clean up the mess and try and get rid of it. But again, antivirus was largely non-functional. We had third-party devices. Oh, and it being a hospital system, we had biomedical devices. Now, if we had more time, this is where I'd go on my rant about FDA 510K and why biomedical device manufacturers don't want to patch their devices because they think the federal government won't let them do it. And it's not true. But suffice to say, there were devices that had, you know, those base computers in them. Actually, I will tell a part of this story. So while this was happening, you know, I have the microphone. I get the change in my mind. So we had, it was either UHF or VHF radios or whatever. So we were on the radio and we're seeing traffic coming from some device and we knew what Ethernet port it was on. So therefore the engineers were able to tell us what room it was in. So I get on the radio and I was like, there's someone in hospital, blah, blah, blah. Go to room 67 and turn off the computer that's in there because it's making a lot of noise and breaking things. And the guy radios back and said, okay, I'm in this room and there's no computer here. I was like, dude, that's not possible. I mean, I'm looking at the traffic. I know the Ethernet port is in that room. There's got to be a computer in there turning off. And you're like, look. And I said, you know, where are you? Physically, where are you? I'm telling you there's no bloody computer in here. So I told the engineer, turn off that Ethernet port. I don't know what that device is, but turn it off. We'd been talking to the hospital administration the whole time during this thing, so they knew that stuff was going on. So we disabled the port, took the machine offline, and within about 90 seconds my phone rings and it's the director of the ED at the hospital. And he says, hi, our only X-ray machine just went offline. So I'm putting the entire hospital on drive-by. Drive-by meaning they can't accept new patients because they don't have an X-ray machine. So if an ambulance was on the way to that hospital, they get to turn around and go somewhere else because they can't admit new patients. And so the director continued and said, what did you just do? And I was like, I mean, nothing. Well, I mean, I turned off a network port, but, you know, it was a Windows box and you said it was an X-ray machine. That can't be an X-ray machine. And he said, no, no, no, actually it runs Windows XP. Huh. So I get back on the radio and I ask the desktop guys, like, so you said there was a big box in there. Apparently it's an X-ray machine. Does it have a screen on it or something? And he goes over there, poke, poke, poke. I'm like, huh, it runs Windows XP. I'm like, oh, God, we just turned off the only X-ray machine in this entire hospital. So then the trick was, you know, do you turn it back on so you can admit patients? Because I, you know, I'm a computer geek. I'm not in the business of making life and death decisions, right? That's why I went into computer science and not medicine. So we turned the machine back on and I told him, I was like, look, man, if I see it start propagating outside the organization, we'll have no choice but to turn it off. So, you know, your call if you want to put somebody in there. So anyway, that was like, you know, early in my career and one of the worst moments I had, because you think as, you know, in computer, you know, if you're an IT or infosec or whatever, you know, I'm dealing with, you know, packets and computers and, you know, if a computer doesn't, isn't doing what I want it to do, you just turn the damn thing off, you know, I have to worry about it. And then, you know, so I turned the damn thing off and now I got, you know, people in ambulances getting rerouted. And so I chose to leave healthcare, of course. And got into consulting instead. So all right, I told that story. Thanks for sitting through that. So now that we knew who the infected host were talking to and we knew who the infected host were, now we needed to try and figure out, you know, what actual software is doing this and how do we get rid of it. So if you look at some of these logs from Snort, the blue bits, of course, that's an IP address. So we knew which hosts were infected and then it also told us which port was being used on the red bits there. So we had a port. So we have a little more information now. So now it's time to find the offending process. Anyone ever use F port? It's a great tool. There's other tools that will give you the same information. This is one of many ways to find this information out. But we had access to the remote machines. Again, disclaimer, this was 2004. Everybody had local admin on every machine, because why not? So it was easy to run F port and figure out. So I knew that, what was that number, 1303. So if you look at all the processes, look, process 1420, sure enough, was using port 1303. And look at that. The executable associated with it is W32 USB 2.exe. So of course they gave it a file name that would make it easy to overlook and not know what you're seeing. So now we knew what piece of software was doing all this. Great. So how do we stop it? Well, thankfully, malicious software back then was much, much less sophisticated than it is today. So we could use another tool called PS Kill, Process Kill. You give it a UNTIL. You give it a UNTIL. So we could use another tool called PS Kill, Process Kill. You give it a UNC path to an IP address. You give it the name of the process. Again, W32 USB 2. And it kills it. It's a lot harder to do now. A lot of malicious software, it will protect itself and reinstall itself and you can't necessarily just stop the process and delete it. But again, the point is these were very, you know, simple techniques we were using to overcome technical deficiencies that we had. So we went through this. And to be fair, this is a very much a manual process and a sufficiently large organization this would not likely scale. Very well you could script it, I imagine, and still be useful. But as we went through this process, we found several. So I had mentioned that there were two vulnerabilities that were being exploited. I was told there was one, two, three, four different infected files with a variety of different malicious softwares. As you see there, Spybot, Wootbot, Randex, Spybot, Arbot, and the list goes on. I think the message here is there was a lot of these types of softwares being used around that time. And I'm not sure that we ever figured out who patient zero was, you know, how that stuff got inside our network. It was a variety of things that were eating us up, not just one thing. So the lesson here, knowing which screw to turn. So there's a story. I have no idea if it's true or not, but it's very interesting and I like to believe it's true. Where a machinist was hired to fix an electric generator that it wasn't working. And this was, you know, way back in the 20th century somewhere. And so the machinist walked in, looked at the device, turned a screw, and then the generator started working again and he submitted his invoice for $10,000. And of course the client was like, I mean, $10,000, you turned a screw. You know, you got to itemize that invoice and tell me what are you charging me for because that seems like an awful lot of money. So he said, fine. I charged you $1 for turning the screw and I charged you $9,999 for knowing which screw to turn. So as I've walked through what we did, hopefully none of you are sitting there thinking, wow, that was really impressive that they knew how to use very, very basic security tools that everybody in this room probably knows how to use. But we were in an incident response situation where our other response techniques had failed and we felt like we just happened to know which screw to turn and the huge win in our case was not that anything we did was necessarily amazing, but it was very effective and it overcame several challenges. Understanding the nature of the problem and the context of the incident based on the collective experience of all of us involved is what resulted in the malware eventually being eradicated. And as I mentioned in the beginning of this, if you go over to packet detective or capture the packet, a lot of these techniques are very, very similar to what you're still doing today. And so it's, I think, even though they're not the exciting, you know, kind of layer seven sorts of things that are coming ever more popular, they're still very, very relevant. So one more case study that goes over some very similar things involved a web dev vulnerability that existed. It was back in 2003. I think it was on the weekend I got a call from one of my buddies that had a new server he had deployed in the DMZ and answered the phone and he's like, hey man, do you want to see a dead body? All right, recall we worked for a hospital system so I wasn't sure if that was a euphemism or... Yeah, so I didn't know where it was, I was like, what do you mean? And he's like, yeah, I got a server in the DMZ and there's a problem with it. I noticed that the C drive was filled up. Like, okay, what filled it up? Well, I don't know. So yeah, then it became interesting. He looked at the C drive of his machine that he had deployed and it's probably very difficult to see but none of that stuff had anything to do with making sick people healthy. So we immediately thought, okay, well what does the network profile of this box look like? So we scanned it and there was three... We pretty much knew what everything... Oh look, FTP was on there. Yeah, okay, again, you know, 2003, don't be a hater. So we knew what everything was except those bits in red. We weren't sure what that... Ports 1978, 2003 and 3460. So those were the ones we knew, just a quick in-map and we knew, okay, those are the things we need to look at first to figure out what's going on. So F port, again, saved us. We ran F port on it and figured out that port 2003 was being used by a process called WinNGNT not to be confused with the legitimate Windows process called WinN... Oh now I can't remember. It spelled different, trust me. Oh, there it is, right there. I should read my own slides. WinNGMT, not NT, okay. So, all right, that didn't... We knew that was sketchy, we didn't know what it was going to do, well, of course, we telneted over to port 2003 to see what it was. And apparently the bad guy wasn't done configuring his server but we had, you know, it responded with a banner and it had... It was, you know, once it was set up it would have had server statistics and, you know, this was a rogue FTP site that was on our server in the hospital. So that was kind of neat. And I'm glad... I think, goodness, I'm a digital pack rat and I saved all of this information. Here I am, you know, 15 years later talking about it. We continued to look around the server to see what was interesting there. We found a file called rb.bat and apparently that was the install script that was used and you can see it installs some things, starts some services up. And so, yeah, I'm not going to talk through the technical details of it. It's interesting that we found artifacts left over by the bad guy. And so this is a well-known technique probably for most folks in here but the hacker was kind enough to patch our system once he or she was done. So you can see here that the script stops the vulnerable service, modifies the registry such that that service was no longer vulnerable to the web dev buffer overflow, imported some information and then restarted the service at some point. I think we all know why they do that but, again, back in 2004, that was a bit non-intuitive. You know, why did the bad person take the trouble to patch our server after you attacked it? Well, of course, the answer is because the bad guy didn't want anybody else to also compromise that server and gain access to the server's resources. So at least we knew that machine would only get owned once, I guess, you know. But, of course, any malicious software can only continue to exist if it finds other victims. So as we continued to look through the logs and whatnot that had left been left behind, it began looking for new victims. So you can see it was looking for other hosts that had web dev enabled. I obfuscated those because those were not RFC 1918 IP addresses. They were routable IP addresses which meant the hospital that I worked for was attacking other people out on the open internet, which means that you're going to start getting angry phone calls from ISPs and whatnot wondering what you're doing. Excuse me. Lastly, that hacker was nice enough to leave behind his calling card. I started Googling some of the key words on there and they started redirecting to a lot of TLDs that I have no interest in communicating with. If anyone would like to research that further and let me know who these people are or who they were, but like I said it was a lot of domains I didn't want to visit. Again, none of those techniques were mind blowing or complex or anything but it was just very simple techniques that a couple guys on the weekend we went through and figured some interesting things out. But there is another side of the coin. I've talked about how people can be the most useful security tool but sometimes we're the problem as well and this is a much shorter part of this slide Dex, I don't panic we're getting close to the end. Thank you for still being here. It was on a red team exercise and we had a very complex nine-step attack chain and I'll show you a picture of the attack chain just to make the point that this was really hard. But many times during that nine-step attack chain we got very, very lucky because the reason the attack chain worked was because of human error on the part of the client. For example, we gained access to a workstation on which the administrator left credentials and a spreadsheet on his desktop. This was last year this was 2016 when this happened don't leave your creds in a spreadsheet unencrypted and I didn't put this in the slide deck but also do not name the spreadsheet credentials.csv You don't have to be a very clever red teamer to figure out that that's a file I'm going to open and then we went through the attack chain once we had domain admin we during the readout the client is like we were in domain admin for three days before anyone said anything you should probably monitor the DA group and they said we do. So why didn't you notice that we had created an account for ourselves in the group and they said because the monitoring system that checked DA had failed. So you need a monitoring system for the monitoring system and that sounds funny in everything but it's true if you've got one box that does a critical thing so that was human error as well they had a bad design and whomever was responsible for that system hadn't checked it apparently because it wasn't doing its job. This has been sanitized but this looks amazing but again I'm making the point that if it weren't for a couple of key failures by people then we would not have been successful. The cynical point of view is that people a lot of times there are processes, there are technical controls, there are things in place that will stop bad things from happening but we're not perfect and sometimes we make mistakes and this is what happens. So to start to wrap it up and I just copied and pasted this directly from the white paper I mentioned that I wrote so we had several technological challenges we used commercial and freely obtainable tools and we overcame the obstacles in a resourceful and cost efficient manner so the point is problems can be solved creatively I really do speak English I promise using limited resources and so we have to regularly evaluate commercial products to use inside our organizations but properly trained personnel can be more valuable to an organization than any hardware or software device so what can we do as information security professionals now this is where the conversation usually begins and you may or may not agree with me and if you don't agree with me that's awesome because then you can tell me your opinion and maybe I can learn something today I think we should spend on people first in technology if you build a team around a set of technologies that you deploy then when those technologies change you may be left with the wrong team for your organization so I advocate for building the team first and making sure they're enabled to adapt as the technology changes because it's the people that are more important I think when you're ready to spend on technology make sure you consider the skills of the people you already have you might make a decision to deploy a certain technology based on your support model or maybe you know if you're going to deploy a certain technology then you will have to include training to get your people the appropriate skills to support it and that's identify those gaps understand what's going to it's not just buying the widget with all due respect to any sales folks that might be here just because someone says oh yeah this product's easy to support and doesn't require any training that's rarely true right and work outside your organizational silos I think this is less of a problem these days but I mentioned in the beginning slides that our networking team was reluctant to engage the infosec team because we were in a different silo I think that's less of a problem these days but you know just be aware of the capabilities that exist in your organization outside of the one in which you work so that's my story I'm sticking to it many thanks alright so I know putting up a QR code in front of an infosec crowd is probably a wildly unpopular idea you can trust me there's nothing malicious in there so go ahead and scan it everybody scan it right now so anyway that's me that's my email address on Twitter I am Damon Small comments or questions before I guess this is where Ming gets up and says comments or questions so any comments and questions please thank you Ming nothing alright so I'll be around I will be over there with the wall of sheep most of the time I'm happy to talk about this more if anyone has any comments or questions later on you want to ask me or catch me please do thank you for sitting through this enjoy the rest of DEF CON 25 thank you