[00:00.000 --> 00:05.140] Hi everyone, my name is Chloe Mostagi and I'm happy to be on the disclosure panel with you [00:05.140 --> 00:11.740] for this wonderful biohacking village. And so before I get started, I just wanted to let you [00:11.740 --> 00:16.320] know who I am so you have a better idea of basically what the content I'm going to share [00:16.320 --> 00:21.480] with you. So I am the VP of Strategy over at Point3Security and when I'm not that, I'm an [00:21.480 --> 00:26.980] ethical hacker advocate. And if you're wondering what is an ethical hacker advocate, basically I'm [00:26.980 --> 00:32.760] trying to fight for rights for hackers and also to change the imagery and the wording that the [00:32.760 --> 00:37.300] press tends to use about us in a very negative light. But when I'm not doing that, I also am [00:37.300 --> 00:42.020] trying to push for diverse inclusion within the community. I am the president and co-founder of [00:42.020 --> 00:47.140] WOSEC and when I'm not that, I'm also the founder of WeAreHackers, which used to be formally called [00:47.140 --> 00:54.960] as LoneHackers, but WeAreHackers is a private online community of hackers who are underrepresented [00:54.960 --> 01:01.000] genders. And yes, we hack at all different levels and have workshops and all that fun stuff. And [01:01.000 --> 01:08.140] yes, I am a parent. If you're wondering what's a parent, it's basically a parent of any dogs, cats, [01:08.140 --> 01:12.460] and hamsters, I guess, and bunnies or any of those kind of things. Anyway, [01:12.460 --> 01:17.980] Shirlika and Luna, which are both some sheebs. And also I am the Hacker Book Club organizer and [01:17.980 --> 01:24.660] what we do is one of those things where we read a new book every month written by someone in the [01:24.660 --> 01:29.780] about the hacker community and the author and the people that are mentioned in the book do attend [01:29.780 --> 01:36.800] our weekly meetups on Tuesday at 5 p.m pacific time. Anyway, enough about me. If you want to [01:36.800 --> 01:40.600] follow me, feel free to. I'm on Twitter and Instagram. Let's go into the good stuff though. [01:41.460 --> 01:47.180] So what usually when we see the word hacker or when we type in hacker in Google or whatnot, [01:47.180 --> 01:53.060] we get like this these type of images, this dark hooded figure, but also we see these ones that [01:53.060 --> 01:59.700] have whole cutout and you know. Anyway, let's just be honest with each other. This is really [01:59.700 --> 02:05.700] annoying at this point because what's happening is that people are seeing us in this way. [02:05.740 --> 02:10.900] Something that looks like a criminal. And it's not just that, but even if you type in [02:10.900 --> 02:16.940] ethical hacker or criminal hacker, if you see on both sides of this, you get the exact same [02:16.940 --> 02:23.560] imagery. So which is even more annoying because it looks like we're still having this situation [02:23.560 --> 02:30.160] ongoing. And it's not the imagery either. It's also the words being used. The media, which is [02:30.160 --> 02:37.020] press and marketing organizations, keep using the term hacker in a negative way when they should [02:37.020 --> 02:44.320] be saying malicious actors or cyber criminals. But if you're wondering how does this imagery [02:44.320 --> 02:51.120] impact us, I'm glad that you're asking because I'm one of those people that's obsessed with brains. [02:51.300 --> 02:55.160] So we're going to talk about them. All right, so first things first that you should know about [02:55.160 --> 03:00.420] when it comes to your brain is we're going to have to dive into the amygdala, which is an almond [03:00.420 --> 03:07.240] shaped part of your brain within the temporal lobe. Now the thing to know about the amygdala, [03:07.240 --> 03:11.900] it sorts who's like us, who's not like us. And because of that, it's the fear versus flight [03:11.900 --> 03:17.340] mechanism. So if the person somehow has a connection like us or looks like us, we're like, [03:17.340 --> 03:23.020] this is a friend versus if the person doesn't look like us or we have no association, never [03:23.020 --> 03:29.360] had any conversation with someone that is that type of person, we see them as an enemy. And [03:29.360 --> 03:35.180] because of that, that is how we have these things called socially constructed beliefs. [03:35.180 --> 03:41.380] One in the media when they share hackers and imagery of this hooded figure or using the term [03:41.380 --> 03:46.880] hacker, what is happening is socially constructed beliefs are now being implanted in other people's [03:46.880 --> 03:54.920] minds that hackers are criminals and that all of us are criminals, we're bad people. And because [03:54.920 --> 04:03.320] of that, it has created this fear in the public. Now to know about is that when the amygdala sees, [04:03.320 --> 04:09.400] for example, let's put it this way, you know when we always tell someone that we're a hacker, [04:10.260 --> 04:15.820] and usually the person takes a step back and kind of goes, or they're like the mouth drops, [04:15.820 --> 04:20.520] or their eyes get a little big. They're nervous, but they don't want to come off that they are, [04:20.520 --> 04:24.720] but they totally are. And you know it. And you're like, dang it, I should have gone the security [04:24.720 --> 04:30.160] researcher term, but you did it. It's okay. Anyway, what happens is at that point, [04:30.160 --> 04:35.860] what's happening is that person knows that now you're a hacker. And they've seen the images, [04:35.860 --> 04:39.480] they've heard the words in the press and whatnot of hacker. And when they see you, [04:39.480 --> 04:42.940] and you tell them you're a hacker, they're taking the step back because they're trying [04:42.940 --> 04:50.800] to figure out something. If you are a friend or a foe. Now the thing to note about the amygdala [04:50.800 --> 04:55.100] is that even though it sends that signal, it's completely subconscious. So you don't even know [04:55.100 --> 04:59.720] that you have a fear of it. The only time when you know that it's a fear is if it comes in the [05:00.340 --> 05:05.340] prefrontal cortex of your brain, which is right here. Anyway, so what it does is that it sends [05:05.460 --> 05:11.740] a message that are saying warning, warning, there's a hacker near you. Be careful. It's a [05:11.740 --> 05:19.720] criminal. They do bad, terrible things. Now the thing is, is that that person now has a choice [05:19.720 --> 05:27.460] to react or to ignore it. Now the only way that you can question socially constructed beliefs and [05:27.460 --> 05:33.700] biases is through stories and from meeting people within that community. The thing is, [05:33.700 --> 05:38.100] when we're inside our bubble, we're protected from these things. We have our own beliefs and it's [05:38.100 --> 05:43.140] constantly being verified that you are correct always. When we go outside our bubble, that's [05:43.140 --> 05:48.040] when we realize you're not actually, you don't know everything. And to be comfortable with the [05:48.040 --> 05:54.760] uncomfortable is always a hard thing. So what's the main takeaway if you're wondering, Chloe, [05:54.760 --> 05:58.840] why are we still talking about the brain and the amygdala? The thing you need to understand is that [05:59.480 --> 06:05.820] it's not permanent. These socially constructed ideas are never permanent. You have a choice [06:06.280 --> 06:11.620] to learn about another perspective, but they have to hear the other perspective. And right now [06:11.620 --> 06:17.560] in the press, we're not seeing that yet. And because of that, we're still being seen as [06:17.560 --> 06:25.920] criminals. So, and because of this fear and the public perception, we still have a situation where [06:25.920 --> 06:31.680] 93% of the Forbes Global 2000 don't have a vulnerability disclosure program. And 60% of [06:31.680 --> 06:38.940] hackers do not report vulnerabilities out of fear of being prosecuted. And laws that are preventing [06:39.600 --> 06:48.820] like good hacking are such as the CFA and DMCA. And because of this stigma associated with being [06:49.060 --> 06:54.920] a hacker and how the public sees us, it also increases the chances of having more malicious [06:55.560 --> 07:01.120] attackers, not hackers, attackers. But I try to catch you there in that slide and see if you caught [07:01.120 --> 07:07.420] it or not. But overall, what we need to know about is that there are legislation out there that is [07:07.420 --> 07:13.560] hurting us still to this day. And what we need right now are some amendments. So, for example, [07:13.560 --> 07:19.560] the anti-hacking laws, the Computer Fraud Abuse Act was actually created in 1984 because Ronald [07:19.560 --> 07:24.460] Reagan watched this movie called War Games and panicked. As you can tell, many of the rules and [07:24.460 --> 07:30.380] laws that have been created are usually stemmed from panic and fear based and not through empathy. [07:30.380 --> 07:35.020] They never really had a conversation with the hacker community to say, hey, is this right or [07:35.020 --> 07:40.800] wrong what we're doing here? And the thing is, is that we need to push more than ever some amendments [07:40.800 --> 07:46.800] for this. Yes, we do believe that, you know, malicious actors should have to deal with prosecution. [07:47.020 --> 07:52.800] But if we are going, you know, within scope, then we shouldn't be having to worry about being [07:52.800 --> 07:58.700] prosecuted. If we go out of scope by accident, we shouldn't have to worry about being prosecuted. [07:58.700 --> 08:04.280] However, if we go out of scope and we exploit, okay, yes, we did something bad with a malicious [08:04.280 --> 08:11.400] intent. And anti-circumvention laws are the copyright acts. And basically seeing reverse [08:11.400 --> 08:18.300] engineering is seen as a breach. Not a breach, but it's just wrong. It's not legal. So these are [08:18.300 --> 08:23.380] things to consider and remember of. And of course, we have an acceptable use policy, which is every [08:23.380 --> 08:29.100] time that you are on your iPhone or any of those things, it's like, please check this terms and [08:29.100 --> 08:33.660] conditions. I know some of us try to read it, but it's really hard to understand because we're not [08:33.660 --> 08:41.180] attorneys. So it makes it even harder for us to understand what we're reading. And also many of us, [08:41.180 --> 08:46.320] English is not our first language. And so that's the other issue, is that there's all these things [08:46.320 --> 08:54.480] that are set up for hackers ourselves to fall into a situation of being prosecuted. And it's scary. [08:55.660 --> 09:00.680] But if you want to start changing things, there's one step that you can do right now, which is if [09:00.680 --> 09:07.840] you go to change.org, there's this petition that was created, which basically tries to get all of [09:07.840 --> 09:13.600] us to sign it. So then we can bring it and push for changes to happen. We need organizations to [09:13.600 --> 09:18.440] start trusting us and have bilateral trust that they will not prosecute us if we report a vulnerability [09:18.440 --> 09:25.700] and we don't exploit it. We're also asking for politicians to update. Update the laws that we have. [09:25.700 --> 09:31.000] Creating amendments is one of those because it's the laws that they've created are preventing good [09:31.000 --> 09:36.940] hacking. And also for the media to let them know that please, if you're reporting about the hacker [09:36.940 --> 09:42.560] community, please keep us in a good light. But if it is someone who did something malicious, don't call [09:42.560 --> 09:48.260] them a hacker. Call them a malicious actor or cyber criminal. And that's one of those important things. [09:48.260 --> 09:53.740] But us as a community, we have to try to do our best to stay within scope and not exploit because [09:53.740 --> 10:01.060] when one of us breaks that, it takes us 10 steps backwards. And I'm looking forward to the other [10:01.060 --> 10:07.720] panelists sharing more about what on their side and what they're seeing when it comes to disclosure. [10:08.280 --> 10:12.940] So let's start out by kind of getting a little bit more into the weeds here. [10:12.940 --> 10:19.160] My focus in this area is going to be more on hospitals and the vulnerabilities involved with [10:19.160 --> 10:25.060] hospitals. To start off with, here's a little bit about me. I don't really want to spend too much [10:25.060 --> 10:31.580] time on this particular page other than to say I've got a lot of experience across a lot of [10:31.580 --> 10:37.780] hospitals. It gives me a unique perspective to see some interesting patterns. And unfortunately, [10:37.780 --> 10:43.600] I'm here to scare the crap out of you a little bit about how insecure hospitals really are. [10:43.600 --> 10:47.900] And then hopefully I'll be able to motivate you guys to do something about that. [10:48.060 --> 10:52.560] Let's first talk about the most important thing here, and that's inventory. [10:53.840 --> 11:00.200] When I'm dealing with hospitals, particularly the ones that come into my environment where [11:00.200 --> 11:04.860] we start supporting them for the first time, they never have an inventory. If we're lucky, [11:04.860 --> 11:12.100] they've got a spreadsheet similar to one that St. Ellis here has. If you get a chance, [11:12.100 --> 11:19.080] please participate in the CTF. That's actually the inventory list for the CTF that we used just [11:19.080 --> 11:24.640] recently. And it's pretty accurate. It covers pretty much the same thing that I see at hospitals. [11:25.540 --> 11:29.900] Now, there are some tools that kind of help us figure out inventories. [11:30.520 --> 11:35.300] Lansweeper is my favorite, but there's also Case, SCCM, Configuration Manager, [11:35.300 --> 11:40.500] and then you can get real manual with Nmap, Mascan. Those will kind of get you about 80% [11:40.500 --> 11:47.880] of the inventory, but it's still going to be mostly accurate. And the reasons for some of that is [11:49.620 --> 11:53.420] because there are things that are getting added and removed to the environment all the time, [11:53.420 --> 11:59.020] and the spreadsheets never get updated. And there's always the fun one where there's [12:00.340 --> 12:07.620] a grant that comes along, and the vendor comes in and installs the devices in the environment [12:07.620 --> 12:15.360] and doesn't tell IT or IS, and all of a sudden IT and IS have to support these tools, and it's [12:15.360 --> 12:21.780] kind of a mess. So starting out from the very basics, inventories is one of those vulnerabilities [12:21.780 --> 12:25.160] that we kind of have to deal with and start figuring out how to get a better inventory [12:25.160 --> 12:30.700] for hospitals. The next one we're going to move into is actually discovering vulnerabilities. [12:30.700 --> 12:36.560] Now, I like to start out with an external scan to figure out all of the stuff that a hospital [12:36.560 --> 12:42.800] has put out on the internet that they use to communicate over the internet. Generally speaking, [12:42.800 --> 12:49.340] when those first hospitals come into our support area, they are very, very vulnerable, [12:49.340 --> 12:55.100] and we have to start narrowing that down. You can see the little spreadsheet to the left there. [12:55.120 --> 13:00.240] That's about a year ago, and I'm proud to say that most of those in the critical areas have [13:00.240 --> 13:06.120] at least moved off. But when, like I said, when a new hospital comes in, they're very, [13:06.120 --> 13:10.620] very vulnerable. Nobody knows what they've got out on the internet. It's always a fun [13:10.620 --> 13:17.580] little situation. And there are a lot of tools that can be used to do this. I use Tenable.io [13:17.580 --> 13:20.740] and the reference page. You'll get to see a whole bunch of different other ones. [13:20.740 --> 13:30.100] But I also like to bring out Shodan.io and Census.io. Shodan.io is a website that you can [13:30.100 --> 13:35.320] go to, Shodan.io, and you can search for medical devices on it and see how many are actually [13:35.320 --> 13:39.780] published on the internet that you have access to. In the particular case here, [13:39.780 --> 13:45.060] I put PAX in there, and there's about 700 plus medical devices published on the internet that [13:45.060 --> 13:49.820] you have access to that you can see about. And if you click on the IP of that particular device, [13:49.820 --> 13:53.780] you'll be able to see the CVs and all the things that are vulnerable for that device. [13:53.780 --> 14:01.560] Kind of a scary little thing. Now, as bad as the external scan is, scannable IPs on the internet, [14:01.560 --> 14:06.000] the internals are always much, much worse. Because hospitals usually design systems where [14:06.000 --> 14:10.600] they have this nice, hard firewall that is supposed to protect them from all the different [14:10.600 --> 14:17.000] types of things. And then once you get inside, it's not much security whatsoever. So it's like [14:17.000 --> 14:23.220] that nice little M&M hard candy shell, soft inside. Nice and scary stuff. So how does this [14:23.220 --> 14:30.700] kind of come about? Well, I kind of blame it a lot of it on availability. And then we're talking [14:30.700 --> 14:36.260] about the CIA availability, confidentiality, integrity, and then availability. Availability [14:36.260 --> 14:42.820] is king when it comes to hospitals. If you've ever seen a physician get upset about not being [14:42.820 --> 14:48.740] able to access what they need right then and there, it's quite a terrifying experience. [14:48.740 --> 14:53.060] They usually take it out on everybody. And rightfully so, because we're talking about life [14:53.060 --> 15:00.640] and death here. So that tends to be one of the challenges that we have to deal with for patch [15:00.640 --> 15:05.080] Tuesday that comes out, everything getting patched. How do you reboot something when it has to be up [15:05.080 --> 15:08.320] for that surgery that's going to take place at six o'clock in the morning [15:08.320 --> 15:14.840] the next day? And we could also talk about maybe N plus one and having server farms, [15:14.840 --> 15:20.280] but hospitals are kind of cheap. And that leads to my next one where fast and cheap is far, far [15:20.280 --> 15:27.280] more important than good or having it built accurate or done with quality. So the fast and [15:27.280 --> 15:33.020] cheap is always going to win. Nobody really cares how good it is or the quality of it is. [15:33.020 --> 15:37.340] They just want it set up and running and they don't worry about anything else. [15:38.600 --> 15:42.980] Now, of course, that leads to all kinds of fun little problems because Microsoft is a [15:42.980 --> 15:48.360] wonderful company that gets everything to work fairly well. That's kind of one of their goals. [15:48.360 --> 15:53.120] Everything's got to work, but they turn on all the services by default. [15:53.120 --> 15:56.920] And when you're pushing something out fast and cheap, you push it out with the default settings. [15:56.920 --> 16:01.020] So here we are set up with all these services that we don't need that are running and they're [16:01.020 --> 16:06.160] now vulnerable because they haven't been patched in at least six months or so. [16:07.560 --> 16:14.180] The next one is kind of a more challenging one and probably the most important one, [16:14.180 --> 16:20.040] both IT and IES. Really, we kind of suck at talking to humans. We're great at talking about [16:20.040 --> 16:26.480] technology and working with computers and communicating along those routes. And the [16:26.480 --> 16:32.420] staff, they don't talk tech at all. They talk human. They're worried about emotions and they're [16:32.420 --> 16:37.940] worried about being able to understand people's needs and wants and desires and they don't care [16:37.940 --> 16:41.680] about the technology. That's just the thing that's there that kind of gets in their way [16:41.680 --> 16:47.140] and hopefully will help them out just a little bit. And then the last one I want to talk about [16:47.140 --> 16:53.820] is there's really no accountability. There's also no incentive to do better or to fix all [16:53.820 --> 17:00.600] these types of things. So it kind of to Chloe's point earlier there in her talk, [17:00.600 --> 17:06.580] she mentions that there's all these different laws out there, but there's no laws about making sure [17:06.580 --> 17:15.770] that medical devices or hospital devices are secure and not going to cause us problems. [17:17.020 --> 17:20.460] And there's also no incentive. There are a few nice little things, hopefully Casey will [17:20.460 --> 17:26.600] cover some of that stuff in his talk. So next I'm going to talk about my solution for this. [17:26.600 --> 17:33.280] And the key word is communication. Now we as IT, information security, IS, we've got to do much, [17:33.280 --> 17:38.740] much better at communication. We've got to figure out how to communicate with our target audience. [17:38.800 --> 17:43.280] We've got to figure out how to deliver our message to our target audience. We've got to be able to [17:43.280 --> 17:49.700] read our target audience and get better at understanding when our target audience understands [17:49.700 --> 17:56.120] our message. And we may have to modify our message to get that across. Once we're able to effectively [17:56.120 --> 18:00.420] communicate, you know, those horrible soft skills that nobody ever wants to work on because it's [18:00.420 --> 18:05.620] boring and challenging and difficult. Once those are down, then we can start talking about ensuring [18:05.620 --> 18:13.020] that integrity and confidentiality of data is maintained. And it's just as important, if not [18:13.020 --> 18:19.200] more important than the availability of the data. And we'll be able to talk about how quality [18:19.200 --> 18:25.880] is just as important, maybe more so, and even cheaper in the long run than getting something [18:25.880 --> 18:31.920] out as fast as possible, as cheap as possible. And then we can also start convincing those [18:31.920 --> 18:38.980] politicians to hold people accountable and people, meaning the CEO boards, all those people that [18:39.840 --> 18:45.380] build corporations in order to avoid being accountable to different things. And we'll be [18:45.380 --> 18:52.680] able to start building out some incentives to help us have reasons to do things rather than [18:52.680 --> 19:00.440] reasons not to do things. Next, I want to talk about something that kind of scares me. Last year [19:01.010 --> 19:06.320] at the Biohacking Village, there was a conversation going on, and I believe Beau had said this, [19:06.320 --> 19:13.880] and it was about how physicians don't really care about security because there's no body [19:13.880 --> 19:20.820] count associated with security. There's no direct correlation of a medical device killing people. [19:21.200 --> 19:24.320] And to be honest, I think medical devices are being used to kill people. [19:25.820 --> 19:31.240] And there's really no way to tell if they have or they haven't been used to kill people because [19:31.240 --> 19:38.440] we don't have the technology in place to detect that. There's no SOCs, there's no SIMs, there's [19:38.440 --> 19:45.640] no IPS, there's no logs, there's none of that good stuff. Not at least at hospitals. At hospitals, [19:45.640 --> 19:52.660] they have a firewall and they have anti-virus type situations. And at hospitals, technology [19:52.660 --> 19:59.840] is very, very far behind everybody else. Pagers are still being used, fax machines in multifunction [19:59.840 --> 20:07.160] printers are being used to fax between floors. Just this morning, I had a fun conversation about [20:07.160 --> 20:13.900] how a CD was being sent from one hospital to another hospital and how it's important to [20:13.900 --> 20:20.300] verify the data on that CD, how it's important to make sure that there's no viruses on that CD, [20:20.300 --> 20:25.720] and if they're going to be communicating through CDs, they should probably encrypt the data, [20:25.720 --> 20:28.520] all of which I don't think any of that has been done. [20:30.460 --> 20:35.060] Now, kind of to bring it back around, I posted a little image here. It's from 2004 [20:35.060 --> 20:39.820] about the arrest rates and percentage of crimes cleared. And as you can see, [20:39.820 --> 20:44.740] murders are solved about 62% of the time. So even if [20:46.920 --> 20:51.840] a murder is committed, then there's a pretty good chance, 40% chance that [20:53.240 --> 20:57.100] whoever commits the murder is also going to be able to get away with it. And that's [20:57.100 --> 21:03.160] just the way it is with all the legal and law enforcement areas. As I mentioned, it was 2004 [21:03.160 --> 21:08.220] when this particular one came out. If you do a search and check, that hasn't changed. It's still [21:08.220 --> 21:17.340] right around 60%. So we need to do better. We need to start using a communication like I talked [21:17.340 --> 21:23.760] about to start holding people accountable and just start providing incentives to ensure that [21:23.760 --> 21:27.740] these medical devices aren't actually killing people. Got to figure it out. [21:27.740 --> 21:33.420] Now here's a little scary thought for everybody. If hospitals have to invest in [21:35.160 --> 21:39.500] these monitoring site solutions, then the hospitals are also going to have to invest [21:39.500 --> 21:46.960] in ways to prevent that from happening. All of this is a huge cost effort and hospitals [21:46.960 --> 21:53.140] don't make very much money. A lot of it is spent on administration and they would much [21:53.140 --> 21:58.820] rather buy an MRI machine than they would spend the money on securing something. So I'm going to [21:58.820 --> 22:04.280] drive home that we've got to set up some incentives. All right, let's pull up this [22:04.280 --> 22:08.500] last slide because I don't want to end on too scary or say out of a note. Everybody's trying [22:08.500 --> 22:12.840] their absolute best in everything that they're kind of doing. Hopefully we'll all keep trying [22:14.640 --> 22:21.440] and hopefully we'll get better and learn more and just kind of do the best we can. [22:22.000 --> 22:26.500] I'll also throw this up. Here's the references. I'm sure that at a certain point the slides will [22:26.500 --> 22:33.200] become available and you will be able to click on the links and utilize the information in these. [22:33.540 --> 22:38.000] Thanks for hearing me. I believe Casey's up next and we'll hear from him next. [22:38.320 --> 22:43.980] All right, greetings DEF CON. Thank you for joining this talk and thanks to Eric and Chloe [22:43.980 --> 22:50.180] leading into my section now. Who the heck is this guy? I am the founder, chairman, and CTO of [22:50.180 --> 22:54.760] BugCrowd. My name is Casey Ellis. I've been in information security for about 20 years. [22:55.720 --> 23:00.620] From a BugCrowd standpoint, and especially as it relates to vulnerability disclosure, [23:00.620 --> 23:05.880] BugCrowd actually pioneered the crowdsource security as a service space. So, you know, [23:05.880 --> 23:09.860] vulnerable disclosure and bug bounty predates us by a long way, which I'll get to in the talk. [23:09.860 --> 23:13.780] We were the first to actually get in the middle and try to make it work better. So, you know, [23:13.780 --> 23:18.920] pretty proud of that, but it means we've learned a lot about how that works from a process standpoint. [23:18.920 --> 23:24.460] From a journey standpoint, for me, you know, I started life as a hacker. I got into Pentest as [23:24.600 --> 23:30.220] a career, moved across into the dark side of security solutions and sales, and then broke [23:30.220 --> 23:35.780] bad and became an entrepreneur, which eventually led to starting BugCrowd in 2012. And yeah, [23:35.780 --> 23:40.540] you can see the, you know, the hack persona and the hustle persona on the side that pretty much [23:40.540 --> 23:45.620] sums up who I am and how I do what I do. So now you know me. That's where to find me as well. [23:46.540 --> 23:52.180] So yeah, with respect to the talk, you know, when we started BugCrowd, it was really all about, [23:52.180 --> 23:56.980] like, how do we do this? Well, there's this enormous community of white hats from all around [23:56.980 --> 24:02.720] the world, which Eric's talked about, and some of the things that they can do. And, you know, [24:02.720 --> 24:08.620] this incredible need for security feedback in all sorts of areas of cybersecurity. Like, [24:08.620 --> 24:14.740] how do we make this easy to do it well? How can you connect that latent potential with the unmet [24:14.740 --> 24:21.060] demands of security itself? And, you know, on this, like, if you look at it simplistically, [24:21.060 --> 24:25.520] it's a fairly easy problem to solve. You just invite a conversation to happen and everything's [24:25.520 --> 24:30.740] great. But it turns out there's a lot of devil in the detail, which is, you know, we did anticipate [24:30.740 --> 24:34.500] that when we started off, but it's a lot of what we've been continuing to work on over the last [24:34.500 --> 24:39.880] eight years. And Disclose.io, which is what I'm going to talk about today, is a product actually [24:39.880 --> 24:47.540] of the policy and really the adoption of vulnerability disclosure component of that. [24:47.540 --> 24:54.100] Like, at this point, we're a ways along from where we were even back in 2012. I think nowadays [24:54.100 --> 24:59.980] vuln disclosure is becoming this normalized phenomena, and it's starting to become a lot [24:59.980 --> 25:05.160] of social pressure around it, which I think is a really good thing. It's still the company, [25:05.160 --> 25:11.200] the kind of thing, rather, that you're a bit special if you do, as opposed to being, [25:11.200 --> 25:16.140] you know, abnormal or unusual if you don't do it. And really, Disclose.io is about flipping that, [25:16.140 --> 25:22.500] but I'll not preempt myself anymore, and we'll get into a bit of backstory. So, in 95, Netscape [25:22.500 --> 25:28.960] launched the Bugs bounty program. They've since dropped the S because it's cleaner, and that is [25:29.040 --> 25:35.900] a Silicon Valley joke for anyone who missed it. There's lockpick bounty programs. There's all [25:35.900 --> 25:40.180] sorts of other things that go back centuries, even, around getting security feedback through [25:40.360 --> 25:48.040] a reward model. But Netscape's broadly accepted as the first kind of high-tech bug bounty program. [25:48.040 --> 25:54.460] And really, with that, kind of almost the instantiation of being proactive around [25:54.460 --> 25:58.940] vulnerability disclosure and actually inviting and engaging it as a part of your security process. [25:58.940 --> 26:04.000] So, bug bounties and vulnerability disclosure, they're not the same thing. Don't let anyone tell you that they are. [26:04.700 --> 26:09.620] But they look enough, they look similar enough in terms of how they operate that, you know, we put [26:09.620 --> 26:14.980] that back down to kind of where this whole idea started to really gain momentum. You know, Bug [26:14.980 --> 26:19.920] Crowd started in 2012, and in 2013, I've got these flipped around, but you get it. One of the [26:19.920 --> 26:26.460] things that we noticed was, you know, legal teams don't seem to really understand how to write a [26:27.300 --> 26:32.200] policy that is almost the opposite of everything they've written before it. So, you've traditionally [26:32.200 --> 26:38.360] gone out saying, hey, if you're a hacker, go away, you're bad, and here's all of the legal stuff to, [26:38.360 --> 26:43.220] you know, create a legal framework for us to say that to you. Now, we're starting to try to get our [26:43.220 --> 26:47.840] heads around the idea that, you know, there's locksmiths as well as burglars out there, and we [26:47.840 --> 26:52.620] actually want the help of the locksmiths. Legal teams don't know how to do that. It's still, I [26:52.620 --> 26:59.080] believe, a net new kind of idea in the space of law. And the challenge is with legal teams, you [26:59.080 --> 27:02.480] know, when they don't, when they're uncertain about what they're doing, they tend to write [27:02.480 --> 27:08.300] war and peace. Like, they'll err on the side of verbosity. So, you end up with these great big, [27:08.300 --> 27:13.000] long, confusing briefs, and that's the first part of the problem. The second part is that hackers [27:13.000 --> 27:18.120] don't read those things in the first place. They should, but it's the yielder problem. You know, [27:18.120 --> 27:22.340] I think you get a subset of the community who actually really do dig in, and we're very grateful [27:22.340 --> 27:26.220] for them. But you've got to expect the behavior from the internet that people are just going to [27:26.220 --> 27:31.680] click through, look for the thing to do next, and go, which is certainly true also in this space. [27:31.960 --> 27:36.840] And the challenge is that when you talk about, you know, the anti-hacking laws and some of the [27:36.840 --> 27:41.960] provisions that have been invoked to chill security research that Chloe was talking about earlier, [27:41.960 --> 27:47.360] you know, the CFIA makes screwing this up as a hacker potentially a felony crime. And the same [27:47.360 --> 27:52.960] is true for similar laws in other countries. So in 2014, we thought, all right, let's try to [27:53.580 --> 27:59.680] untangle this one and solve it. So we released the Open Source Vulnerability Disclosure Framework [27:59.680 --> 28:06.720] in partnership with Jim Dinaro and the folk over at Cypher Law out of DC. And that was awesome. [28:06.720 --> 28:11.380] It was basically this idea of, like, how do we, you know, kind of compress down the really [28:11.380 --> 28:15.600] important things that need to be in a brief like this to the point where people can theoretically [28:15.600 --> 28:22.760] just copy paste and get it right like 90% of the time. At the same time, Katie, Art, a bunch of [28:22.760 --> 28:27.120] others in InDisclosure were working on the ISO standards. They got released to paying customers. [28:27.120 --> 28:32.360] So there was this kind of convergence on trying to solve this problem of standardization. Fast [28:32.360 --> 28:39.280] forward to 2018, what we did was basically take some of the, well, actually kind of capitalized [28:39.280 --> 28:45.400] on some of the attention that was around this concept of legal safe harbor. Thank you to Amit [28:45.960 --> 28:51.980] for really pushing that forward and her legal bug bounty initiative. And then Dropbox and a couple [28:51.980 --> 28:57.840] of other folks that were going on took the OSVDF and legal bug bounty, merged them, and put them [28:57.840 --> 29:03.320] all under Disclose.io. Bug crowd added it as default and off we went from there. So that's [29:03.320 --> 29:07.840] the backstory. And I think with respect to CFAA, you know, it's important to keep in mind that it [29:07.840 --> 29:14.680] is in active use. I personally believe that there should be laws in place that address [29:15.220 --> 29:20.880] computers as a vector to commit a crime. But, you know, as Chloe called out, if it's not clear [29:21.920 --> 29:25.900] what side of the law you're on, especially when you're trying to help, then there's a chilling [29:25.900 --> 29:30.620] effect that means that security feedback doesn't pass from A to B. And that's always bad. So we're [29:30.620 --> 29:35.560] trying to solve that problem. So really what Disclose.io is about is like, how do we make [29:35.560 --> 29:41.380] this idea of vuln disclosure, how do we make the adoption of a vulnerability disclosure program go [29:41.380 --> 29:47.200] viral? And doing it with best practice. How do we make that into something that is not this huge [29:47.200 --> 29:53.460] push from companies like Bug Crowd and people in the researcher community? Not this like reactive, [29:53.460 --> 29:58.820] oh crap, I got tweeted at, what do I do now experience for folk on the vendor side? Something [29:58.820 --> 30:04.640] that, you know, the internet collectively is leaning into and doing well. And that really is [30:04.640 --> 30:10.860] the mission of Disclose.io. It's a healthy and ubiquitous internet immune system and props to [30:10.860 --> 30:17.380] Karen Elazari, Amit's sister, for I think making that concept of hackers operating as the immune [30:17.380 --> 30:23.620] system of the internet popular in her TED talk. Feels like a billion years ago at this point, but [30:23.620 --> 30:29.780] it was a little while back. You know, I think that's true. I think, you know, the healthcare [30:29.780 --> 30:36.320] sector and the internet in general's rejection of security input or its inability to identify [30:37.040 --> 30:42.720] that input as important and good, but then its rejection of that input is kind of like an auto [30:42.720 --> 30:46.920] immune deficiency in a lot of ways. And, you know, this is what we're trying to solve. Like, [30:46.920 --> 30:50.600] how do we get it to the point where hackers are functioning as the, like the T-cells of the [30:50.600 --> 30:56.600] internet and the internet as an organism, as a body is able to cooperate with that and actually [30:56.600 --> 31:01.300] have, you know, everything grow up and be big and strong as a byproduct. [31:02.380 --> 31:07.320] The mission of Disclose.io is to drive vulnerability disclosure adoption, [31:07.320 --> 31:12.380] as I probably made clear at this point, but doing that through safety, simplicity, [31:12.380 --> 31:16.700] and standardization. So if that's what you remember about this project, that's going to be [31:16.700 --> 31:22.920] kind of the key takeaway because it does involve everyone. It is open source. You know, I'm [31:22.920 --> 31:27.580] known for bug crowds, sitting in front of a big bug crowd logo, and this is kind of the commercial [31:27.580 --> 31:32.480] concept construct for starting this project. But at this point, we have basically spun it out [31:32.480 --> 31:37.400] into its own thing. It's very much something that we want everyone to participate in, [31:37.400 --> 31:41.700] regardless of whether they're a customer of my company or not. So that's kind of the goal here. [31:42.460 --> 31:50.160] So what is it? How are we doing it? How do you unscrew a 30-year-old problem on the internet? [31:50.180 --> 31:55.420] Glad you asked. So there's three main components to it. There's the terms, [31:55.420 --> 31:59.980] the purpose of the terms is to make it easy. How do we eliminate the friction of understanding [31:59.980 --> 32:07.060] and adopting B2B language in a way that benefits hackers and companies? And the overall outcome of [32:07.060 --> 32:12.460] that is ideally standardization of what those terms should look like. Eventually, ideally, [32:12.460 --> 32:19.860] to the point where things like CFAA, DMCA, and others start to come under the right kind of [32:19.860 --> 32:24.800] pressure to be reformed, to actually accommodate for good faith in our space. I think that's the [32:24.800 --> 32:29.260] utopian goal. We're a ways off from that. And there's a lot of other things for the legal folk [32:29.260 --> 32:34.500] to be occupying themselves with right now. But in the meantime, we can do our part. [32:34.640 --> 32:41.340] The second piece is the list, which is to aggregate adoption and really to drive adoption as well. [32:41.660 --> 32:45.420] The whole idea there is network effect, which is that kind of virality piece I was talking about [32:45.420 --> 32:52.240] before. How do we get it all into the one spot in a way that basically creates this critical mass of [32:52.240 --> 32:57.640] best practice that people are actually drawn to? And the third piece is the logo, which is [32:57.640 --> 33:02.640] really normalization. I'll go into these in a second because I'm kind of getting ahead of it. [33:02.640 --> 33:11.340] But how do we promote best practice? I think VDP is a little bit unique in terms of security things [33:11.340 --> 33:16.820] that a company can do because a non-technical user can understand it. They might not get [33:16.820 --> 33:23.780] blockchain-enabled, AI-powered, next-gen endpoint something, something. But the idea of neighborhood [33:23.780 --> 33:27.620] watch for the internet, especially when you're talking about a safety-critical space like [33:27.620 --> 33:34.140] medical, anyone can get that. And we're at a point in time where I think the average human is more [33:34.140 --> 33:39.120] concerned about the risk that they have when they're buying a product than ever before. So this [33:39.120 --> 33:43.720] becomes something that's actually a benefit aside from the security benefit and the fact that [33:43.720 --> 33:48.280] it's just the right thing to do. The goal with this is for it to almost become like the green [33:48.280 --> 33:55.460] padlock for SSL. And I say that fully mindful that people started to remove the green padlock [33:55.460 --> 34:01.640] because it has been normalized. If this whole idea of VDP adoption can go through that same arc, [34:01.640 --> 34:06.340] I would be incredibly happy. And I think pretty much everyone in this space would benefit from [34:06.340 --> 34:12.620] it as well as the internet itself. So, all right, the terms. It is a collection of boilerplate, [34:12.620 --> 34:18.980] full disclosure templates. Some folks just copy-paste it. With the OSVDF, the initial [34:18.980 --> 34:23.680] incarnation of this, we noticed the language popping up everywhere. It was getting translated [34:23.680 --> 34:30.440] into different languages. That document has grandfathered into policies all over the internet [34:30.440 --> 34:35.160] at this point. And that's just the thing that people do. So, okay, you can do that. Or you can [34:35.160 --> 34:39.700] use it as a foundational framework or a starting point for new versions, which is one of the reasons [34:39.700 --> 34:44.760] that it's open source. We've actually taken input from programs who've looked at the policy, [34:44.760 --> 34:49.040] said, hang on, here's an edge that a lot of people have that you probably haven't considered [34:49.040 --> 34:53.520] that we're going to write in. You should consider it, issued a pull request, and we've actually [34:53.520 --> 34:58.620] merged that into the language over time. It's open source, as I keep saying, because I want [34:58.620 --> 35:04.420] to really stress that point. It's licensed under CCA 4.0, so anyone can use it. And some of the [35:04.940 --> 35:10.260] represented in the NASCAR section here are the kind of people that are helping out. [35:10.740 --> 35:14.620] This isn't an endorsement from them of the project itself, but it's the kind of folks that are [35:14.620 --> 35:20.020] participating on an individual level to making that language better and driving this forward. [35:20.020 --> 35:24.020] These are the kind of folks that are actually rocking up and assisting. So that's the other [35:24.020 --> 35:29.040] benefit of open source. It's not just, you know, Casey the Bush lawyer from Australia's opinion [35:29.040 --> 35:33.360] on how to do this as well. It's all sorts of different folks that are actually coming in and [35:33.360 --> 35:39.780] making the whole thing more and more effective over time. And honestly, like, this is the [35:39.780 --> 35:44.840] interesting part, I find, is that it's actually kind of hard to do. You know, one of the things [35:46.800 --> 35:50.680] that's a challenge, frankly, that needs to be overcome, because it's a function of how it works, [35:50.680 --> 35:57.200] is that not every hacker is a lawyer. In fact, most aren't, I would say. And many of them, [35:57.200 --> 36:01.560] I would say most, are English as a second language. So you've got to be able to actually [36:01.560 --> 36:05.660] articulate what the hell you're trying to do in this brief in a way that if they do read it, [36:05.660 --> 36:10.060] they can understand what's okay and what's not. So you've got to balance this readability and brevity [36:10.600 --> 36:15.660] with legal completeness. Obviously, you want to provide safety to whatever degree you can [36:16.340 --> 36:23.480] without going overboard and having it turn into this 12-page read-fest. And the safety that's [36:23.480 --> 36:28.200] provided by the clauses in this type of thing need to be bilateral. They need to protect the [36:28.200 --> 36:32.840] company that's putting it up on their policy. And it needs to, more importantly, I think in [36:32.840 --> 36:38.160] context of this talk, protect that hacker as they're doing research. Or even, you know, the [36:38.160 --> 36:42.940] concerned citizen who's found a bug, not as a product of security research, that just wants [36:42.940 --> 36:47.300] to send it across and doesn't know if that'll get them sent to jail or not. So at the moment, [36:47.300 --> 36:52.860] it's covering US, Canada, the Netherlands, and Belgium. And we wrote one for the 2020 US [36:52.860 --> 36:59.920] presidential elections. That was tough because there's obviously a lot to consider there. That's [36:59.920 --> 37:04.560] the sort of problem sets that we're trying to tackle with these terms and with the goal of [37:04.560 --> 37:11.220] making it easy and standardized. The list itself is this true community-powered vendor-agnostic [37:11.220 --> 37:16.860] directory of all known BDPs and bug-banning programs. At the moment, we've got, you know, [37:16.860 --> 37:21.240] what kind of legal protections afforded by the program, what kind of rewards does it offer. [37:21.240 --> 37:27.940] We're about to integrate support with security.txt. And I think calling it at the disclosure models [37:27.940 --> 37:32.800] and timelines, if it's a coordinated vulnerability disclosure model, that's going to be different for [37:32.800 --> 37:38.800] every organization. So we've accommodated that in there as well. Again, open source licensed under [37:38.800 --> 37:44.020] CCA. So that brings us to the seal. This is like the green padlock part that I was talking about [37:44.020 --> 37:48.080] at the front. What we've done at this stage, this will continue to evolve, but where it's up to at [37:48.080 --> 37:54.340] this point is dividing out what we're referring to as safe harbor, or as popularly, I think at [37:54.340 --> 37:59.400] this point, referred to as safe harbor. What that's really talking about is what kind of legal protections [37:59.400 --> 38:05.120] are available to the researcher that have been proactively included by the program owner into [38:05.120 --> 38:11.080] the program. And we've broken it into partial safe harbor and partial, like a partial compliance [38:11.080 --> 38:15.980] statement and a full safe harbor or a full compliance statement. The difference between [38:15.980 --> 38:21.540] those two things, I think is quite important. For partial, what we're referring to as partial [38:21.540 --> 38:26.120] safe harbor, essentially, it's a good faith statement. So it's this idea that, hey, we agree [38:26.120 --> 38:32.580] not to lower up and cause you a hard time if you play by these rules, which is better than [38:32.580 --> 38:38.120] there being nothing there, right? Because that's when, you know, there's, I think the risk can be [38:38.120 --> 38:42.540] quite high. And there's even recently examples of where that sort of thing's gone wrong. [38:43.180 --> 38:47.800] That statement in of itself is a good start. The problem is that you're still potentially [38:48.460 --> 38:54.160] technically committing a crime as you conduct security research. And that's the part where [38:54.160 --> 38:59.160] there's still, I think, a decent amount of exposure. I liken it to, you know, in California, [38:59.960 --> 39:04.880] on the highways, the speed limits 60 miles an hour, but everyone drives at 80 and you don't [39:04.880 --> 39:10.240] get pulled over, right? And that's because there's this sort of social contract. It's not quite, [39:10.240 --> 39:14.880] that would be no safe harbor because it's not written down anywhere, but kind of everyone knows. [39:15.660 --> 39:20.460] It's sort of the same thing. You could get pulled over for that, but you just don't. [39:20.460 --> 39:25.440] Full safe harbor would be the analog to actually increasing the speed limit to what people will [39:25.440 --> 39:32.860] drive at and putting it on the speed sign. So at that point, there's no recourse for you to be, [39:32.860 --> 39:36.720] you know, issued a speeding ticket in that context. I'm doubling down on this driving [39:36.720 --> 39:42.460] metaphor, but I think it's a neat way to explain it. And to basically get full compliance in [39:42.460 --> 39:49.080] context of Disclose.io, there needs to be provision against anti-hacking laws. So authorization is [39:49.080 --> 39:53.860] typically the hinge term. It certainly is with CFAA and the same is broadly true around the world. [39:54.620 --> 39:59.780] Exemption against any circumvention laws like DMCA, which is very relevant to medical device [39:59.780 --> 40:06.180] research. Exemption against acceptable use or TOS violation because you're breaking the thing and [40:06.180 --> 40:10.680] that shouldn't mean that you're breaking the law if you're doing security research. And a general [40:10.680 --> 40:15.720] acknowledgement of good faith as well. And this is the part where, you know, we'll get to how this [40:15.720 --> 40:20.980] all works because ideally, and we've started to see this happen, but this is where everyone can help. [40:21.760 --> 40:27.180] An organization initiates a Vulnerable Disclosure Program. It gets added to the list. People see [40:27.180 --> 40:33.480] that and look at it, then say, oh, well, where are you at with these safe harbor clauses? Where are [40:33.480 --> 40:38.740] you at with the legal protections that you're giving researchers to actually try to help you [40:38.740 --> 40:44.000] out here? The organization's like, oh, I didn't even really think of that because oftentimes that's [40:44.000 --> 40:48.900] true. They go back, look through the boilerplate stuff, you know, work out what they're going to [40:48.900 --> 40:52.740] include or how they're going to adapt their policies. It gets updated in the list. And at [40:52.740 --> 40:59.360] that point, they're issued with the logo. Should an organization actually take that logo and use it [40:59.360 --> 41:03.800] to promote the fact that they've got a VDP or promote the fact that this is part of their [41:03.800 --> 41:08.780] cybersecurity process? At that point, hackers see it and they start to help out, which is good. [41:09.200 --> 41:14.600] Customers see it and they trust them more, which is good. The part I like best is that their peers [41:14.600 --> 41:20.360] from a vertical standpoint see it and ask themselves, why am I doing that? I should [41:20.360 --> 41:26.540] probably do that too. Like if, you know, we're in a vertical with five players in it, four are doing [41:26.540 --> 41:32.000] it, one's left out, that one looks like a schmuck and no one wants to be that company. So it's [41:32.000 --> 41:37.960] basically increasing lateral social pressure to adopt vulnerability disclosure and actually do [41:37.960 --> 41:45.060] this well. And, you know, it feels too soon to be talking about... I was actually talking about this [41:45.060 --> 41:53.800] in context of virality and network effect before COVID broke out. But, you know, without disrespecting, [41:53.800 --> 41:57.220] I think the pain that that's causing a lot of people right now, I think it actually illustrates [41:57.220 --> 42:03.780] the idea pretty effectively. Like how do we take this concept of doing the right thing, [42:03.780 --> 42:08.860] making people more secure, doing the right thing by hackers, and just generally improving the [42:08.860 --> 42:13.680] security of the internet and actually make that viral? That's really the goal that we've got here. [42:14.360 --> 42:19.920] So how does it relate to medical security? What can we achieve in 2020? The first, and this is a [42:19.920 --> 42:25.700] call for help, is to adapt the terms to the medical device sector in particular. I think [42:25.700 --> 42:34.060] the medical sector in general would be great too. You know, I think the election security [42:34.760 --> 42:38.740] revision that we did, it took a lot of work and a lot of thoughtfulness from people that are [42:38.740 --> 42:43.360] involved in that space because there's a lot of edge cases that are specific that needed to be [42:43.360 --> 42:47.820] considered and factored in and then you needed to simplify that. So you can't just add crap on [42:47.820 --> 42:53.880] because that violates the simplicity design goal of the terms. So lawyers that are up for that, [42:53.880 --> 42:58.880] please do reach out. As people adopt full disclosure in medical security, we want to [42:58.880 --> 43:03.660] see at least 30% of them with this full authorization statement. Ideally higher, [43:03.660 --> 43:08.860] like I'd love to see it get to 100% at some point in the future, but 30% seems like a great place to [43:08.860 --> 43:13.800] start. Across the thousand-odd programs that we're tracking at the moment, compliance is about [43:13.800 --> 43:20.220] at about 13%. I think last time I checked. So, you know, there's a gap there, but it's a [43:20.220 --> 43:27.000] bridgeable gap. So I think that's a good goal. And I think specific to COVID, you know, this is [43:27.000 --> 43:31.800] something that we've been pushing on commercially as bug crowd, but also just in general at a policy [43:32.340 --> 43:39.840] level. You know, how can we use this to basically unscrew the problem of COVID contact tracing, [43:39.840 --> 43:43.980] both from a security and privacy standpoint, but then also from an adoption standpoint? [43:44.080 --> 43:48.620] You know, one of the things that's preventing people from adopting rightly or wrongly, [43:48.620 --> 43:53.760] or perhaps rightly and wrongly from adopting contact tracing applications is they don't [43:53.760 --> 43:58.100] trust the security implication. They don't trust the privacy implication. They don't trust the [43:58.100 --> 44:04.200] government, the folks that wrote it, like whatever the individual excuse or reason might be. [44:05.240 --> 44:12.160] It's sort of similar to, you know, the conversation before around like, this is [44:12.160 --> 44:17.200] Neighborhood Watch for the internet. If there's transparency, if there's like this known kind [44:17.200 --> 44:21.660] of group of people that are constantly working to help improve this stuff for their own safety [44:21.660 --> 44:26.480] as hackers and as members of this community, all of a sudden, you know, we solve all of those [44:26.480 --> 44:31.940] problems with really the one shot, you know, obviously providing the issues are getting fixed, [44:31.940 --> 44:36.640] which we're not addressing in this. We are just talking about vulnerability intake and policy. [44:36.640 --> 44:42.760] That whole vulnerability management pieces is very much a separate but adjacent subject. I [44:42.760 --> 44:46.740] don't want to confuse the two there, but you can sort of see the model here. If all of a sudden [44:47.100 --> 44:51.760] a government or an agency is turning around saying, cool, this is our solution. These are [44:51.760 --> 44:55.440] the concerns that we know you have. This is how we're addressing them. And by the way, the [44:56.060 --> 45:04.020] should make you more confident. If that drives up adoption rates of safe and privacy conscious [45:04.020 --> 45:08.840] contact tracing applications, I think that's part of what makes that particular model of pandemic [45:08.840 --> 45:13.360] management work, which is something we need to be thinking about right now. I personally hate [45:13.360 --> 45:19.840] that type of solution in any time other than this. I got asked a lot of questions about it and said, [45:19.840 --> 45:24.980] yeah, in any other time I'd run screaming from something like contact tracing, I'd recommend [45:24.980 --> 45:30.280] that absolutely everyone else do the same thing. But we haven't really dealt with the kind of [45:30.280 --> 45:34.460] things that we're dealing with before with technology available as a potential solution. [45:34.460 --> 45:41.660] So I think this is a really practical application of it. So help wanted. Lawyers, help us translate [45:41.660 --> 45:47.160] the terms. If you want to translate it into a language that you speak in and a jurisdiction [45:47.160 --> 45:51.560] where you can be considerate of the particular anti-hacking and anti-circumvention laws that [45:51.560 --> 45:56.180] apply, that would be fantastic. We'd appreciate that. We want to see as much of that happen as [45:56.180 --> 46:01.520] possible. For hackers, contribute to the list. If there's something missing or if there's a detail [46:01.520 --> 46:06.040] that's incorrect, submit a pull request and actually use that list. The idea of it is to [46:06.040 --> 46:11.940] help you guys and girls and everyone else who's involved in hacking to be able to look at the [46:11.940 --> 46:16.860] target space that's out there that's actually wanting your help and giving you an opportunity [46:16.860 --> 46:21.540] to do that. If you want to work on paid programs, go for it. If you want to work on BDPs and [46:21.540 --> 46:26.200] verticals that you're passionate about, do it. The goal of the list is to get all of that [46:26.200 --> 46:31.500] information in the one spot and make it easy and shareable to everyone and contributions [46:32.150 --> 46:40.100] power that. For organizations that might be watching, start talking to your security team, [46:40.100 --> 46:44.640] start talking to organizations like Bugcrowd, start talking to hackers about what you need [46:44.640 --> 46:49.880] to do to take steps towards being proactive about launching a vulnerability disclosure program and [46:49.880 --> 46:55.180] actually engaging the feedback of the hacker community. I think a thing to call out here is [46:55.180 --> 46:59.920] you're probably going to get it anyway. And I think that's sort of where this is all going. [47:00.440 --> 47:05.780] This idea of the internet being a feedback loop is very quickly becoming normalized. [47:06.580 --> 47:10.840] So you can either be reactive to this trend or you can be proactive. And I think being [47:10.840 --> 47:16.940] proactive is a better bet. And then include Safe Harbor. And for everyone in the mix, spread the [47:16.940 --> 47:22.400] word. Again, this is the reason that we open sourced it. This is the reason that we created [47:22.400 --> 47:28.740] this particular brand and this particular logo around the idea. We didn't want this to be purely [47:28.740 --> 47:32.960] tied to a commercial initiative. We think this is something that should happen anyway. And I'm [47:32.960 --> 47:38.820] speaking as Bugcrowd right now. This is the kind of thing where I think the more input we get, [47:38.820 --> 47:43.060] the more it gets spread around, the more people get involved, and the more people adopt it, the [47:43.060 --> 47:46.920] better off we all become. And I think that's something that we can all be a part of. [47:46.940 --> 47:54.060] That is my spiel on Disclosure. I really appreciate everyone for attending this talk. [47:54.060 --> 48:00.460] Thank you to Chloe and to Eric for their sections in the talk. And tying it all together, I think [48:00.460 --> 48:06.260] this whole ecosystem of the relationship between the hacker community and hacker feedback loops [48:06.260 --> 48:12.980] and the current and future state of security overall and safety as a byproduct of that in [48:12.980 --> 48:17.540] the medical sector. Hopefully, we've given you all something to think about today. [48:18.120 --> 48:19.560] And now we're going to do some Q&A.