Hi everyone, my name is Chloe Mostagi and I'm happy to be on the disclosure panel with you
for this wonderful biohacking village. And so before I get started, I just wanted to let you
know who I am so you have a better idea of basically what the content I'm going to share
with you. So I am the VP of Strategy over at Point3Security and when I'm not that, I'm an
ethical hacker advocate. And if you're wondering what is an ethical hacker advocate, basically I'm
trying to fight for rights for hackers and also to change the imagery and the wording that the
press tends to use about us in a very negative light. But when I'm not doing that, I also am
trying to push for diverse inclusion within the community. I am the president and co-founder of
WOSEC and when I'm not that, I'm also the founder of WeAreHackers, which used to be formally called
as LoneHackers, but WeAreHackers is a private online community of hackers who are underrepresented
genders. And yes, we hack at all different levels and have workshops and all that fun stuff. And
yes, I am a parent. If you're wondering what's a parent, it's basically a parent of any dogs, cats,
and hamsters, I guess, and bunnies or any of those kind of things. Anyway,
Shirlika and Luna, which are both some sheebs. And also I am the Hacker Book Club organizer and
what we do is one of those things where we read a new book every month written by someone in the
about the hacker community and the author and the people that are mentioned in the book do attend
our weekly meetups on Tuesday at 5 p.m pacific time. Anyway, enough about me. If you want to
follow me, feel free to. I'm on Twitter and Instagram. Let's go into the good stuff though.
So what usually when we see the word hacker or when we type in hacker in Google or whatnot,
we get like this these type of images, this dark hooded figure, but also we see these ones that
have whole cutout and you know. Anyway, let's just be honest with each other. This is really
annoying at this point because what's happening is that people are seeing us in this way.
Something that looks like a criminal. And it's not just that, but even if you type in
ethical hacker or criminal hacker, if you see on both sides of this, you get the exact same
imagery. So which is even more annoying because it looks like we're still having this situation
ongoing. And it's not the imagery either. It's also the words being used. The media, which is
press and marketing organizations, keep using the term hacker in a negative way when they should
be saying malicious actors or cyber criminals. But if you're wondering how does this imagery
impact us, I'm glad that you're asking because I'm one of those people that's obsessed with brains.
So we're going to talk about them. All right, so first things first that you should know about
when it comes to your brain is we're going to have to dive into the amygdala, which is an almond
shaped part of your brain within the temporal lobe. Now the thing to know about the amygdala,
it sorts who's like us, who's not like us. And because of that, it's the fear versus flight
mechanism. So if the person somehow has a connection like us or looks like us, we're like,
this is a friend versus if the person doesn't look like us or we have no association, never
had any conversation with someone that is that type of person, we see them as an enemy. And
because of that, that is how we have these things called socially constructed beliefs.
One in the media when they share hackers and imagery of this hooded figure or using the term
hacker, what is happening is socially constructed beliefs are now being implanted in other people's
minds that hackers are criminals and that all of us are criminals, we're bad people. And because
of that, it has created this fear in the public. Now to know about is that when the amygdala sees,
for example, let's put it this way, you know when we always tell someone that we're a hacker,
and usually the person takes a step back and kind of goes, or they're like the mouth drops,
or their eyes get a little big. They're nervous, but they don't want to come off that they are,
but they totally are. And you know it. And you're like, dang it, I should have gone the security
researcher term, but you did it. It's okay. Anyway, what happens is at that point,
what's happening is that person knows that now you're a hacker. And they've seen the images,
they've heard the words in the press and whatnot of hacker. And when they see you,
and you tell them you're a hacker, they're taking the step back because they're trying
to figure out something. If you are a friend or a foe. Now the thing to note about the amygdala
is that even though it sends that signal, it's completely subconscious. So you don't even know
that you have a fear of it. The only time when you know that it's a fear is if it comes in the
prefrontal cortex of your brain, which is right here. Anyway, so what it does is that it sends
a message that are saying warning, warning, there's a hacker near you. Be careful. It's a
criminal. They do bad, terrible things. Now the thing is, is that that person now has a choice
to react or to ignore it. Now the only way that you can question socially constructed beliefs and
biases is through stories and from meeting people within that community. The thing is,
when we're inside our bubble, we're protected from these things. We have our own beliefs and it's
constantly being verified that you are correct always. When we go outside our bubble, that's
when we realize you're not actually, you don't know everything. And to be comfortable with the
uncomfortable is always a hard thing. So what's the main takeaway if you're wondering, Chloe,
why are we still talking about the brain and the amygdala? The thing you need to understand is that
it's not permanent. These socially constructed ideas are never permanent. You have a choice
to learn about another perspective, but they have to hear the other perspective. And right now
in the press, we're not seeing that yet. And because of that, we're still being seen as
criminals. So, and because of this fear and the public perception, we still have a situation where
93% of the Forbes Global 2000 don't have a vulnerability disclosure program. And 60% of
hackers do not report vulnerabilities out of fear of being prosecuted. And laws that are preventing
like good hacking are such as the CFA and DMCA. And because of this stigma associated with being
a hacker and how the public sees us, it also increases the chances of having more malicious
attackers, not hackers, attackers. But I try to catch you there in that slide and see if you caught
it or not. But overall, what we need to know about is that there are legislation out there that is
hurting us still to this day. And what we need right now are some amendments. So, for example,
the anti-hacking laws, the Computer Fraud Abuse Act was actually created in 1984 because Ronald
Reagan watched this movie called War Games and panicked. As you can tell, many of the rules and
laws that have been created are usually stemmed from panic and fear based and not through empathy.
They never really had a conversation with the hacker community to say, hey, is this right or
wrong what we're doing here? And the thing is, is that we need to push more than ever some amendments
for this. Yes, we do believe that, you know, malicious actors should have to deal with prosecution.
But if we are going, you know, within scope, then we shouldn't be having to worry about being
prosecuted. If we go out of scope by accident, we shouldn't have to worry about being prosecuted.
However, if we go out of scope and we exploit, okay, yes, we did something bad with a malicious
intent. And anti-circumvention laws are the copyright acts. And basically seeing reverse
engineering is seen as a breach. Not a breach, but it's just wrong. It's not legal. So these are
things to consider and remember of. And of course, we have an acceptable use policy, which is every
time that you are on your iPhone or any of those things, it's like, please check this terms and
conditions. I know some of us try to read it, but it's really hard to understand because we're not
attorneys. So it makes it even harder for us to understand what we're reading. And also many of us,
English is not our first language. And so that's the other issue, is that there's all these things
that are set up for hackers ourselves to fall into a situation of being prosecuted. And it's scary.
But if you want to start changing things, there's one step that you can do right now, which is if
you go to change.org, there's this petition that was created, which basically tries to get all of
us to sign it. So then we can bring it and push for changes to happen. We need organizations to
start trusting us and have bilateral trust that they will not prosecute us if we report a vulnerability
and we don't exploit it. We're also asking for politicians to update. Update the laws that we have.
Creating amendments is one of those because it's the laws that they've created are preventing good
hacking. And also for the media to let them know that please, if you're reporting about the hacker
community, please keep us in a good light. But if it is someone who did something malicious, don't call
them a hacker. Call them a malicious actor or cyber criminal. And that's one of those important things.
But us as a community, we have to try to do our best to stay within scope and not exploit because
when one of us breaks that, it takes us 10 steps backwards. And I'm looking forward to the other
panelists sharing more about what on their side and what they're seeing when it comes to disclosure.
So let's start out by kind of getting a little bit more into the weeds here.
My focus in this area is going to be more on hospitals and the vulnerabilities involved with
hospitals. To start off with, here's a little bit about me. I don't really want to spend too much
time on this particular page other than to say I've got a lot of experience across a lot of
hospitals. It gives me a unique perspective to see some interesting patterns. And unfortunately,
I'm here to scare the crap out of you a little bit about how insecure hospitals really are.
And then hopefully I'll be able to motivate you guys to do something about that.
Let's first talk about the most important thing here, and that's inventory.
When I'm dealing with hospitals, particularly the ones that come into my environment where
we start supporting them for the first time, they never have an inventory. If we're lucky,
they've got a spreadsheet similar to one that St. Ellis here has. If you get a chance,
please participate in the CTF. That's actually the inventory list for the CTF that we used just
recently. And it's pretty accurate. It covers pretty much the same thing that I see at hospitals.
Now, there are some tools that kind of help us figure out inventories.
Lansweeper is my favorite, but there's also Case, SCCM, Configuration Manager,
and then you can get real manual with Nmap, Mascan. Those will kind of get you about 80%
of the inventory, but it's still going to be mostly accurate. And the reasons for some of that is
because there are things that are getting added and removed to the environment all the time,
and the spreadsheets never get updated. And there's always the fun one where there's
a grant that comes along, and the vendor comes in and installs the devices in the environment
and doesn't tell IT or IS, and all of a sudden IT and IS have to support these tools, and it's
kind of a mess. So starting out from the very basics, inventories is one of those vulnerabilities
that we kind of have to deal with and start figuring out how to get a better inventory
for hospitals. The next one we're going to move into is actually discovering vulnerabilities.
Now, I like to start out with an external scan to figure out all of the stuff that a hospital
has put out on the internet that they use to communicate over the internet. Generally speaking,
when those first hospitals come into our support area, they are very, very vulnerable,
and we have to start narrowing that down. You can see the little spreadsheet to the left there.
That's about a year ago, and I'm proud to say that most of those in the critical areas have
at least moved off. But when, like I said, when a new hospital comes in, they're very,
very vulnerable. Nobody knows what they've got out on the internet. It's always a fun
little situation. And there are a lot of tools that can be used to do this. I use Tenable.io
and the reference page. You'll get to see a whole bunch of different other ones.
But I also like to bring out Shodan.io and Census.io. Shodan.io is a website that you can
go to, Shodan.io, and you can search for medical devices on it and see how many are actually
published on the internet that you have access to. In the particular case here,
I put PAX in there, and there's about 700 plus medical devices published on the internet that
you have access to that you can see about. And if you click on the IP of that particular device,
you'll be able to see the CVs and all the things that are vulnerable for that device.
Kind of a scary little thing. Now, as bad as the external scan is, scannable IPs on the internet,
the internals are always much, much worse. Because hospitals usually design systems where
they have this nice, hard firewall that is supposed to protect them from all the different
types of things. And then once you get inside, it's not much security whatsoever. So it's like
that nice little M&M hard candy shell, soft inside. Nice and scary stuff. So how does this
kind of come about? Well, I kind of blame it a lot of it on availability. And then we're talking
about the CIA availability, confidentiality, integrity, and then availability. Availability
is king when it comes to hospitals. If you've ever seen a physician get upset about not being
able to access what they need right then and there, it's quite a terrifying experience.
They usually take it out on everybody. And rightfully so, because we're talking about life
and death here. So that tends to be one of the challenges that we have to deal with for patch
Tuesday that comes out, everything getting patched. How do you reboot something when it has to be up
for that surgery that's going to take place at six o'clock in the morning
the next day? And we could also talk about maybe N plus one and having server farms,
but hospitals are kind of cheap. And that leads to my next one where fast and cheap is far, far
more important than good or having it built accurate or done with quality. So the fast and
cheap is always going to win. Nobody really cares how good it is or the quality of it is.
They just want it set up and running and they don't worry about anything else.
Now, of course, that leads to all kinds of fun little problems because Microsoft is a
wonderful company that gets everything to work fairly well. That's kind of one of their goals.
Everything's got to work, but they turn on all the services by default.
And when you're pushing something out fast and cheap, you push it out with the default settings.
So here we are set up with all these services that we don't need that are running and they're
now vulnerable because they haven't been patched in at least six months or so.
The next one is kind of a more challenging one and probably the most important one,
both IT and IES. Really, we kind of suck at talking to humans. We're great at talking about
technology and working with computers and communicating along those routes. And the
staff, they don't talk tech at all. They talk human. They're worried about emotions and they're
worried about being able to understand people's needs and wants and desires and they don't care
about the technology. That's just the thing that's there that kind of gets in their way
and hopefully will help them out just a little bit. And then the last one I want to talk about
is there's really no accountability. There's also no incentive to do better or to fix all
these types of things. So it kind of to Chloe's point earlier there in her talk,
she mentions that there's all these different laws out there, but there's no laws about making sure
that medical devices or hospital devices are secure and not going to cause us problems.
And there's also no incentive. There are a few nice little things, hopefully Casey will
cover some of that stuff in his talk. So next I'm going to talk about my solution for this.
And the key word is communication. Now we as IT, information security, IS, we've got to do much,
much better at communication. We've got to figure out how to communicate with our target audience.
We've got to figure out how to deliver our message to our target audience. We've got to be able to
read our target audience and get better at understanding when our target audience understands
our message. And we may have to modify our message to get that across. Once we're able to effectively
communicate, you know, those horrible soft skills that nobody ever wants to work on because it's
boring and challenging and difficult. Once those are down, then we can start talking about ensuring
that integrity and confidentiality of data is maintained. And it's just as important, if not
more important than the availability of the data. And we'll be able to talk about how quality
is just as important, maybe more so, and even cheaper in the long run than getting something
out as fast as possible, as cheap as possible. And then we can also start convincing those
politicians to hold people accountable and people, meaning the CEO boards, all those people that
build corporations in order to avoid being accountable to different things. And we'll be
able to start building out some incentives to help us have reasons to do things rather than
reasons not to do things. Next, I want to talk about something that kind of scares me. Last year
at the Biohacking Village, there was a conversation going on, and I believe Beau had said this,
and it was about how physicians don't really care about security because there's no body
count associated with security. There's no direct correlation of a medical device killing people.
And to be honest, I think medical devices are being used to kill people.
And there's really no way to tell if they have or they haven't been used to kill people because
we don't have the technology in place to detect that. There's no SOCs, there's no SIMs, there's
no IPS, there's no logs, there's none of that good stuff. Not at least at hospitals. At hospitals,
they have a firewall and they have anti-virus type situations. And at hospitals, technology
is very, very far behind everybody else. Pagers are still being used, fax machines in multifunction
printers are being used to fax between floors. Just this morning, I had a fun conversation about
how a CD was being sent from one hospital to another hospital and how it's important to
verify the data on that CD, how it's important to make sure that there's no viruses on that CD,
and if they're going to be communicating through CDs, they should probably encrypt the data,
all of which I don't think any of that has been done.
Now, kind of to bring it back around, I posted a little image here. It's from 2004
about the arrest rates and percentage of crimes cleared. And as you can see,
murders are solved about 62% of the time. So even if
a murder is committed, then there's a pretty good chance, 40% chance that
whoever commits the murder is also going to be able to get away with it. And that's
just the way it is with all the legal and law enforcement areas. As I mentioned, it was 2004
when this particular one came out. If you do a search and check, that hasn't changed. It's still
right around 60%. So we need to do better. We need to start using a communication like I talked
about to start holding people accountable and just start providing incentives to ensure that
these medical devices aren't actually killing people. Got to figure it out.
Now here's a little scary thought for everybody. If hospitals have to invest in
these monitoring site solutions, then the hospitals are also going to have to invest
in ways to prevent that from happening. All of this is a huge cost effort and hospitals
don't make very much money. A lot of it is spent on administration and they would much
rather buy an MRI machine than they would spend the money on securing something. So I'm going to
drive home that we've got to set up some incentives. All right, let's pull up this
last slide because I don't want to end on too scary or say out of a note. Everybody's trying
their absolute best in everything that they're kind of doing. Hopefully we'll all keep trying
and hopefully we'll get better and learn more and just kind of do the best we can.
I'll also throw this up. Here's the references. I'm sure that at a certain point the slides will
become available and you will be able to click on the links and utilize the information in these.
Thanks for hearing me. I believe Casey's up next and we'll hear from him next.
All right, greetings DEF CON. Thank you for joining this talk and thanks to Eric and Chloe
leading into my section now. Who the heck is this guy? I am the founder, chairman, and CTO of
BugCrowd. My name is Casey Ellis. I've been in information security for about 20 years.
From a BugCrowd standpoint, and especially as it relates to vulnerability disclosure,
BugCrowd actually pioneered the crowdsource security as a service space. So, you know,
vulnerable disclosure and bug bounty predates us by a long way, which I'll get to in the talk.
We were the first to actually get in the middle and try to make it work better. So, you know,
pretty proud of that, but it means we've learned a lot about how that works from a process standpoint.
From a journey standpoint, for me, you know, I started life as a hacker. I got into Pentest as
a career, moved across into the dark side of security solutions and sales, and then broke
bad and became an entrepreneur, which eventually led to starting BugCrowd in 2012. And yeah,
you can see the, you know, the hack persona and the hustle persona on the side that pretty much
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.
So yeah, with respect to the talk, you know, when we started BugCrowd, it was really all about,
like, how do we do this? Well, there's this enormous community of white hats from all around
the world, which Eric's talked about, and some of the things that they can do. And, you know,
this incredible need for security feedback in all sorts of areas of cybersecurity. Like,
how do we make this easy to do it well? How can you connect that latent potential with the unmet
demands of security itself? And, you know, on this, like, if you look at it simplistically,
it's a fairly easy problem to solve. You just invite a conversation to happen and everything's
great. But it turns out there's a lot of devil in the detail, which is, you know, we did anticipate
that when we started off, but it's a lot of what we've been continuing to work on over the last
eight years. And Disclose.io, which is what I'm going to talk about today, is a product actually
of the policy and really the adoption of vulnerability disclosure component of that.
Like, at this point, we're a ways along from where we were even back in 2012. I think nowadays
vuln disclosure is becoming this normalized phenomena, and it's starting to become a lot
of social pressure around it, which I think is a really good thing. It's still the company,
the kind of thing, rather, that you're a bit special if you do, as opposed to being,
you know, abnormal or unusual if you don't do it. And really, Disclose.io is about flipping that,
but I'll not preempt myself anymore, and we'll get into a bit of backstory. So, in 95, Netscape
launched the Bugs bounty program. They've since dropped the S because it's cleaner, and that is
a Silicon Valley joke for anyone who missed it. There's lockpick bounty programs. There's all
sorts of other things that go back centuries, even, around getting security feedback through
a reward model. But Netscape's broadly accepted as the first kind of high-tech bug bounty program.
And really, with that, kind of almost the instantiation of being proactive around
vulnerability disclosure and actually inviting and engaging it as a part of your security process.
So, bug bounties and vulnerability disclosure, they're not the same thing. Don't let anyone tell you that they are.
But they look enough, they look similar enough in terms of how they operate that, you know, we put
that back down to kind of where this whole idea started to really gain momentum. You know, Bug
Crowd started in 2012, and in 2013, I've got these flipped around, but you get it. One of the
things that we noticed was, you know, legal teams don't seem to really understand how to write a
policy that is almost the opposite of everything they've written before it. So, you've traditionally
gone out saying, hey, if you're a hacker, go away, you're bad, and here's all of the legal stuff to,
you know, create a legal framework for us to say that to you. Now, we're starting to try to get our
heads around the idea that, you know, there's locksmiths as well as burglars out there, and we
actually want the help of the locksmiths. Legal teams don't know how to do that. It's still, I
believe, a net new kind of idea in the space of law. And the challenge is with legal teams, you
know, when they don't, when they're uncertain about what they're doing, they tend to write
war and peace. Like, they'll err on the side of verbosity. So, you end up with these great big,
long, confusing briefs, and that's the first part of the problem. The second part is that hackers
don't read those things in the first place. They should, but it's the yielder problem. You know,
I think you get a subset of the community who actually really do dig in, and we're very grateful
for them. But you've got to expect the behavior from the internet that people are just going to
click through, look for the thing to do next, and go, which is certainly true also in this space.
And the challenge is that when you talk about, you know, the anti-hacking laws and some of the
provisions that have been invoked to chill security research that Chloe was talking about earlier,
you know, the CFIA makes screwing this up as a hacker potentially a felony crime. And the same
is true for similar laws in other countries. So in 2014, we thought, all right, let's try to
untangle this one and solve it. So we released the Open Source Vulnerability Disclosure Framework
in partnership with Jim Dinaro and the folk over at Cypher Law out of DC. And that was awesome.
It was basically this idea of, like, how do we, you know, kind of compress down the really
important things that need to be in a brief like this to the point where people can theoretically
just copy paste and get it right like 90% of the time. At the same time, Katie, Art, a bunch of
others in InDisclosure were working on the ISO standards. They got released to paying customers.
So there was this kind of convergence on trying to solve this problem of standardization. Fast
forward to 2018, what we did was basically take some of the, well, actually kind of capitalized
on some of the attention that was around this concept of legal safe harbor. Thank you to Amit
for really pushing that forward and her legal bug bounty initiative. And then Dropbox and a couple
of other folks that were going on took the OSVDF and legal bug bounty, merged them, and put them
all under Disclose.io. Bug crowd added it as default and off we went from there. So that's
the backstory. And I think with respect to CFAA, you know, it's important to keep in mind that it
is in active use. I personally believe that there should be laws in place that address
computers as a vector to commit a crime. But, you know, as Chloe called out, if it's not clear
what side of the law you're on, especially when you're trying to help, then there's a chilling
effect that means that security feedback doesn't pass from A to B. And that's always bad. So we're
trying to solve that problem. So really what Disclose.io is about is like, how do we make
this idea of vuln disclosure, how do we make the adoption of a vulnerability disclosure program go
viral? And doing it with best practice. How do we make that into something that is not this huge
push from companies like Bug Crowd and people in the researcher community? Not this like reactive,
oh crap, I got tweeted at, what do I do now experience for folk on the vendor side? Something
that, you know, the internet collectively is leaning into and doing well. And that really is
the mission of Disclose.io. It's a healthy and ubiquitous internet immune system and props to
Karen Elazari, Amit's sister, for I think making that concept of hackers operating as the immune
system of the internet popular in her TED talk. Feels like a billion years ago at this point, but
it was a little while back. You know, I think that's true. I think, you know, the healthcare
sector and the internet in general's rejection of security input or its inability to identify
that input as important and good, but then its rejection of that input is kind of like an auto
immune deficiency in a lot of ways. And, you know, this is what we're trying to solve. Like,
how do we get it to the point where hackers are functioning as the, like the T-cells of the
internet and the internet as an organism, as a body is able to cooperate with that and actually
have, you know, everything grow up and be big and strong as a byproduct.
The mission of Disclose.io is to drive vulnerability disclosure adoption,
as I probably made clear at this point, but doing that through safety, simplicity,
and standardization. So if that's what you remember about this project, that's going to be
kind of the key takeaway because it does involve everyone. It is open source. You know, I'm
known for bug crowds, sitting in front of a big bug crowd logo, and this is kind of the commercial
concept construct for starting this project. But at this point, we have basically spun it out
into its own thing. It's very much something that we want everyone to participate in,
regardless of whether they're a customer of my company or not. So that's kind of the goal here.
So what is it? How are we doing it? How do you unscrew a 30-year-old problem on the internet?
Glad you asked. So there's three main components to it. There's the terms,
the purpose of the terms is to make it easy. How do we eliminate the friction of understanding
and adopting B2B language in a way that benefits hackers and companies? And the overall outcome of
that is ideally standardization of what those terms should look like. Eventually, ideally,
to the point where things like CFAA, DMCA, and others start to come under the right kind of
pressure to be reformed, to actually accommodate for good faith in our space. I think that's the
utopian goal. We're a ways off from that. And there's a lot of other things for the legal folk
to be occupying themselves with right now. But in the meantime, we can do our part.
The second piece is the list, which is to aggregate adoption and really to drive adoption as well.
The whole idea there is network effect, which is that kind of virality piece I was talking about
before. How do we get it all into the one spot in a way that basically creates this critical mass of
best practice that people are actually drawn to? And the third piece is the logo, which is
really normalization. I'll go into these in a second because I'm kind of getting ahead of it.
But how do we promote best practice? I think VDP is a little bit unique in terms of security things
that a company can do because a non-technical user can understand it. They might not get
blockchain-enabled, AI-powered, next-gen endpoint something, something. But the idea of neighborhood
watch for the internet, especially when you're talking about a safety-critical space like
medical, anyone can get that. And we're at a point in time where I think the average human is more
concerned about the risk that they have when they're buying a product than ever before. So this
becomes something that's actually a benefit aside from the security benefit and the fact that
it's just the right thing to do. The goal with this is for it to almost become like the green
padlock for SSL. And I say that fully mindful that people started to remove the green padlock
because it has been normalized. If this whole idea of VDP adoption can go through that same arc,
I would be incredibly happy. And I think pretty much everyone in this space would benefit from
it as well as the internet itself. So, all right, the terms. It is a collection of boilerplate,
full disclosure templates. Some folks just copy-paste it. With the OSVDF, the initial
incarnation of this, we noticed the language popping up everywhere. It was getting translated
into different languages. That document has grandfathered into policies all over the internet
at this point. And that's just the thing that people do. So, okay, you can do that. Or you can
use it as a foundational framework or a starting point for new versions, which is one of the reasons
that it's open source. We've actually taken input from programs who've looked at the policy,
said, hang on, here's an edge that a lot of people have that you probably haven't considered
that we're going to write in. You should consider it, issued a pull request, and we've actually
merged that into the language over time. It's open source, as I keep saying, because I want
to really stress that point. It's licensed under CCA 4.0, so anyone can use it. And some of the
represented in the NASCAR section here are the kind of people that are helping out.
This isn't an endorsement from them of the project itself, but it's the kind of folks that are
participating on an individual level to making that language better and driving this forward.
These are the kind of folks that are actually rocking up and assisting. So that's the other
benefit of open source. It's not just, you know, Casey the Bush lawyer from Australia's opinion
on how to do this as well. It's all sorts of different folks that are actually coming in and
making the whole thing more and more effective over time. And honestly, like, this is the
interesting part, I find, is that it's actually kind of hard to do. You know, one of the things
that's a challenge, frankly, that needs to be overcome, because it's a function of how it works,
is that not every hacker is a lawyer. In fact, most aren't, I would say. And many of them,
I would say most, are English as a second language. So you've got to be able to actually
articulate what the hell you're trying to do in this brief in a way that if they do read it,
they can understand what's okay and what's not. So you've got to balance this readability and brevity
with legal completeness. Obviously, you want to provide safety to whatever degree you can
without going overboard and having it turn into this 12-page read-fest. And the safety that's
provided by the clauses in this type of thing need to be bilateral. They need to protect the
company that's putting it up on their policy. And it needs to, more importantly, I think in
context of this talk, protect that hacker as they're doing research. Or even, you know, the
concerned citizen who's found a bug, not as a product of security research, that just wants
to send it across and doesn't know if that'll get them sent to jail or not. So at the moment,
it's covering US, Canada, the Netherlands, and Belgium. And we wrote one for the 2020 US
presidential elections. That was tough because there's obviously a lot to consider there. That's
the sort of problem sets that we're trying to tackle with these terms and with the goal of
making it easy and standardized. The list itself is this true community-powered vendor-agnostic
directory of all known BDPs and bug-banning programs. At the moment, we've got, you know,
what kind of legal protections afforded by the program, what kind of rewards does it offer.
We're about to integrate support with security.txt. And I think calling it at the disclosure models
and timelines, if it's a coordinated vulnerability disclosure model, that's going to be different for
every organization. So we've accommodated that in there as well. Again, open source licensed under
CCA. So that brings us to the seal. This is like the green padlock part that I was talking about
at the front. What we've done at this stage, this will continue to evolve, but where it's up to at
this point is dividing out what we're referring to as safe harbor, or as popularly, I think at
this point, referred to as safe harbor. What that's really talking about is what kind of legal protections
are available to the researcher that have been proactively included by the program owner into
the program. And we've broken it into partial safe harbor and partial, like a partial compliance
statement and a full safe harbor or a full compliance statement. The difference between
those two things, I think is quite important. For partial, what we're referring to as partial
safe harbor, essentially, it's a good faith statement. So it's this idea that, hey, we agree
not to lower up and cause you a hard time if you play by these rules, which is better than
there being nothing there, right? Because that's when, you know, there's, I think the risk can be
quite high. And there's even recently examples of where that sort of thing's gone wrong.
That statement in of itself is a good start. The problem is that you're still potentially
technically committing a crime as you conduct security research. And that's the part where
there's still, I think, a decent amount of exposure. I liken it to, you know, in California,
on the highways, the speed limits 60 miles an hour, but everyone drives at 80 and you don't
get pulled over, right? And that's because there's this sort of social contract. It's not quite,
that would be no safe harbor because it's not written down anywhere, but kind of everyone knows.
It's sort of the same thing. You could get pulled over for that, but you just don't.
Full safe harbor would be the analog to actually increasing the speed limit to what people will
drive at and putting it on the speed sign. So at that point, there's no recourse for you to be,
you know, issued a speeding ticket in that context. I'm doubling down on this driving
metaphor, but I think it's a neat way to explain it. And to basically get full compliance in
context of Disclose.io, there needs to be provision against anti-hacking laws. So authorization is
typically the hinge term. It certainly is with CFAA and the same is broadly true around the world.
Exemption against any circumvention laws like DMCA, which is very relevant to medical device
research. Exemption against acceptable use or TOS violation because you're breaking the thing and
that shouldn't mean that you're breaking the law if you're doing security research. And a general
acknowledgement of good faith as well. And this is the part where, you know, we'll get to how this
all works because ideally, and we've started to see this happen, but this is where everyone can help.
An organization initiates a Vulnerable Disclosure Program. It gets added to the list. People see
that and look at it, then say, oh, well, where are you at with these safe harbor clauses? Where are
you at with the legal protections that you're giving researchers to actually try to help you
out here? The organization's like, oh, I didn't even really think of that because oftentimes that's
true. They go back, look through the boilerplate stuff, you know, work out what they're going to
include or how they're going to adapt their policies. It gets updated in the list. And at
that point, they're issued with the logo. Should an organization actually take that logo and use it
to promote the fact that they've got a VDP or promote the fact that this is part of their
cybersecurity process? At that point, hackers see it and they start to help out, which is good.
Customers see it and they trust them more, which is good. The part I like best is that their peers
from a vertical standpoint see it and ask themselves, why am I doing that? I should
probably do that too. Like if, you know, we're in a vertical with five players in it, four are doing
it, one's left out, that one looks like a schmuck and no one wants to be that company. So it's
basically increasing lateral social pressure to adopt vulnerability disclosure and actually do
this well. And, you know, it feels too soon to be talking about... I was actually talking about this
in context of virality and network effect before COVID broke out. But, you know, without disrespecting,
I think the pain that that's causing a lot of people right now, I think it actually illustrates
the idea pretty effectively. Like how do we take this concept of doing the right thing,
making people more secure, doing the right thing by hackers, and just generally improving the
security of the internet and actually make that viral? That's really the goal that we've got here.
So how does it relate to medical security? What can we achieve in 2020? The first, and this is a
call for help, is to adapt the terms to the medical device sector in particular. I think
the medical sector in general would be great too. You know, I think the election security
revision that we did, it took a lot of work and a lot of thoughtfulness from people that are
involved in that space because there's a lot of edge cases that are specific that needed to be
considered and factored in and then you needed to simplify that. So you can't just add crap on
because that violates the simplicity design goal of the terms. So lawyers that are up for that,
please do reach out. As people adopt full disclosure in medical security, we want to
see at least 30% of them with this full authorization statement. Ideally higher,
like I'd love to see it get to 100% at some point in the future, but 30% seems like a great place to
start. Across the thousand-odd programs that we're tracking at the moment, compliance is about
at about 13%. I think last time I checked. So, you know, there's a gap there, but it's a
bridgeable gap. So I think that's a good goal. And I think specific to COVID, you know, this is
something that we've been pushing on commercially as bug crowd, but also just in general at a policy
level. You know, how can we use this to basically unscrew the problem of COVID contact tracing,
both from a security and privacy standpoint, but then also from an adoption standpoint?
You know, one of the things that's preventing people from adopting rightly or wrongly,
or perhaps rightly and wrongly from adopting contact tracing applications is they don't
trust the security implication. They don't trust the privacy implication. They don't trust the
government, the folks that wrote it, like whatever the individual excuse or reason might be.
It's sort of similar to, you know, the conversation before around like, this is
Neighborhood Watch for the internet. If there's transparency, if there's like this known kind
of group of people that are constantly working to help improve this stuff for their own safety
as hackers and as members of this community, all of a sudden, you know, we solve all of those
problems with really the one shot, you know, obviously providing the issues are getting fixed,
which we're not addressing in this. We are just talking about vulnerability intake and policy.
That whole vulnerability management pieces is very much a separate but adjacent subject. I
don't want to confuse the two there, but you can sort of see the model here. If all of a sudden
a government or an agency is turning around saying, cool, this is our solution. These are
the concerns that we know you have. This is how we're addressing them. And by the way, the
should make you more confident. If that drives up adoption rates of safe and privacy conscious
contact tracing applications, I think that's part of what makes that particular model of pandemic
management work, which is something we need to be thinking about right now. I personally hate
that type of solution in any time other than this. I got asked a lot of questions about it and said,
yeah, in any other time I'd run screaming from something like contact tracing, I'd recommend
that absolutely everyone else do the same thing. But we haven't really dealt with the kind of
things that we're dealing with before with technology available as a potential solution.
So I think this is a really practical application of it. So help wanted. Lawyers, help us translate
the terms. If you want to translate it into a language that you speak in and a jurisdiction
where you can be considerate of the particular anti-hacking and anti-circumvention laws that
apply, that would be fantastic. We'd appreciate that. We want to see as much of that happen as
possible. For hackers, contribute to the list. If there's something missing or if there's a detail
that's incorrect, submit a pull request and actually use that list. The idea of it is to
help you guys and girls and everyone else who's involved in hacking to be able to look at the
target space that's out there that's actually wanting your help and giving you an opportunity
to do that. If you want to work on paid programs, go for it. If you want to work on BDPs and
verticals that you're passionate about, do it. The goal of the list is to get all of that
information in the one spot and make it easy and shareable to everyone and contributions
power that. For organizations that might be watching, start talking to your security team,
start talking to organizations like Bugcrowd, start talking to hackers about what you need
to do to take steps towards being proactive about launching a vulnerability disclosure program and
actually engaging the feedback of the hacker community. I think a thing to call out here is
you're probably going to get it anyway. And I think that's sort of where this is all going.
This idea of the internet being a feedback loop is very quickly becoming normalized.
So you can either be reactive to this trend or you can be proactive. And I think being
proactive is a better bet. And then include Safe Harbor. And for everyone in the mix, spread the
word. Again, this is the reason that we open sourced it. This is the reason that we created
this particular brand and this particular logo around the idea. We didn't want this to be purely
tied to a commercial initiative. We think this is something that should happen anyway. And I'm
speaking as Bugcrowd right now. This is the kind of thing where I think the more input we get,
the more it gets spread around, the more people get involved, and the more people adopt it, the
better off we all become. And I think that's something that we can all be a part of.
That is my spiel on Disclosure. I really appreciate everyone for attending this talk.
Thank you to Chloe and to Eric for their sections in the talk. And tying it all together, I think
this whole ecosystem of the relationship between the hacker community and hacker feedback loops
and the current and future state of security overall and safety as a byproduct of that in
the medical sector. Hopefully, we've given you all something to think about today.
And now we're going to do some Q&A.