Good morning, everyone, and welcome to the Packard Hacking Village at Debt Fund 25 in Las Vegas, Nevada.
First and foremost, on a personal note, we cannot thank you enough for all the support, for your contributions, for all these years.
If it wasn't for all of you and for your support, we would not be here. It's such a big village and such a strong support. So we are very, very, very grateful for that.
The Wallachian mission is and has always been on security awareness.
This year, the Packard Hacking Village have a number of events and learning opportunities,
including the venerable
Appalachian
Packard Detective, which is a Neapolitan, and Captor the Package.
We also have the fantastic
Slave of DJs to keep the village entertained.
Okay? Even nice and
entertained and lively.
This year, Cheap City and Honeypots
are back. We are also
very excited that we have something
new in store for this year.
Hands-on workshops.
There is a tremendous demand
for training and
continuous
training.
We hope that you will take advantage of the many opportunities here at the Packard Hacking Village and ultimately at DepCon to learn, to collaborate, and to be inspired.
And of course, here we are at the Speaker workshops.
This is a very special year for this event, the Speaker workshops and the Packard Hacking Village.
This is the fifth anniversary of the Packard Hacking Village.
the Speaker Workshops. We are going to kick it off right off the bat with a very, very special keynote.
Dan Gere said in this keynote at Black Act 2014, and I quote,
Titan security is now a riveting concern, a top issue in many venues more important than this one.
Or in that way he said bluntly at the 11th poll last year in 2016 in New York City, and I quote,
We are now in a national security crisis, cyber security crisis.
So what does this have to do with the keynote this morning?
There are maybe not many people starting to enter or study cyber security, which is very, very welcoming to see.
However, the body of knowledge is now too deep.
It's too deep and intimidating to grasp, and history can be easily forgotten.
How did we get into this mess in the first place?
In May of 1998, a group of hackers testified in front of a panel of U.S. senators.
They had the group of Locke, based out of Boston, Massachusetts.
One of the members of Locke testified for the 12th time, for twice awful.
Locke warned that the Internet, the software, and the hardware
are not safe and secure.
Security is an afterthought.
Their warning was a disaster porthole, and as we all know, tragically ignored.
On a side note, please read the wonderful Washington Post article,
A Disaster Porthole and Ignored.
Their warning and efforts also took a way from many of our careers
and lifestyles in this field,
including mine.
And why many of us are here today at Desmond.
It is my fantastic honor to introduce you all to the keynote we had this morning
at your conference speaker workshop for twice awful.
Thank you very much, and thank you for that warm, warm, very warm welcome.
And it's a pleasure to be here speaking today.
My first time speaking at the Packet Hacking Village.
And, you know, since it was the 25th anniversary of DEFCON,
I've been coming since DEFCON 4.
I think I missed a few along the way, but I thought, you know,
why not have a bit of a retrospective to talk about how we got here
and what an impact hackers had on the security industry,
and really made the security industry what it is today.
It would be very, very different if it wasn't for the input of people
who are doing independent research and taking that hacker mindset.
So I'll start off where Ming started off here with,
this was the picture of the gang of us testifying before the Senate in May 1998.
If you can't recognize me,
my hair's a little different.
I still have the goatee.
It was a little bigger back then, but you might, you probably can't see it,
but on the placards there in the front, you can see
Tan, KingPing, Mudge, Walt Mons, Maze Road.
And there's kind of an interesting aspect to this is
when we got invited to come speak,
we said, well, we'll only do it under our hacker aliases.
And they said, why?
And they said, because we have data.
We have data jobs.
And back in 1998, if you were called a hacker
and you had hands-on keyboards at some IT,
in an IT admin responsibility,
they might say, we don't want someone like that with that kind of responsibility.
You might lose your job.
And so that was the mindset back then because it hadn't changed yet.
I don't think you'd have that today if you said,
hey, I call myself a hacker and I go to DEF CON.
They'd probably say, hey, we need to give you more responsibility.
But back then, it wasn't like that.
But how did we get to this point?
This is around 1998.
Things had to happen before that, before we got invited.
And what I like to say is we made trouble.
We got noticed.
And how did we do that?
We made people upset.
We didn't break the law, as far as I can talk about today.
But we did make people upset.
People didn't like the idea of full disclosure.
Microsoft really didn't like that.
They didn't like us putting out documentation
how their password storage mechanism sucks.
They didn't like that because then all their customers,
including banks and the DOD,
would say,
your software is insecure.
It sucks.
Fix it.
And that costs them money.
It makes them look bad.
So by causing trouble and causing pain for other organizations,
we actually raised a lot of awareness
to the kind of problems that were out there.
And we kind of stumbled upon this.
I can't say that there was a master plan.
We just started taking our research
and instead of just sort of posting it to bug track
and being very academic about it,
we decided that we really should be more consumer advocate focused.
We should take the research,
instead of being just pure technical research,
we should think of it as vendors are doing bad things
that are harming consumers.
And that really started around 1995 or so.
And it changed it from like,
oh, I know how to break into your system,
to wait a minute,
the vendors are shipping code
that is causing this problem for their customers.
And I think that was a big sort of paradigm shift
that caused hackers to be that force
that was siding with the user.
If you fight for the user,
you know, what is that, the Tron line?
And so by sort of causing trouble,
we got noticed.
And that is how the Senate came to us saying,
you know, you guys have an angle on this
that's different than what we're hearing from big vendors.
It's different than what we're hearing
from the government accounting office,
which is really just going through a checklist saying,
you didn't figure this correctly,
you didn't figure this correctly.
And that's how the government thought about it.
And we,
we basically said,
hey, the vendors can do better.
They can ship things that are secure by default.
They can ship things that aren't,
aren't as broken.
The problem was the vendors didn't know how to do that yet.
But we'll get,
we'll, we'll, we'll get it.
So now I just want to go back
to what the computer security was
before hackers came onto the scene
and started to inject themselves into the dialogue.
Um,
we had the famous orange book,
Common Criteria,
which was,
um,
basically a lot of things that you should do
to build a secure system.
You know, you need all those features and functionality.
You need your encryption,
your authorization,
you need your logging and your auditing
and all of that.
Um,
but it left out,
it left out the fact that there could be mistakes
in the software.
That the engineers might actually make mistakes.
That was,
that,
they didn't even think about that.
It's not in,
this is not in that book at all.
Who has software that has bugs in it?
Software has always had bugs in it.
Yet,
this was completely ignored in the orange book.
It's like,
it's like the software was perfect.
You'd have great security if you followed the orange book
if you made perfect software.
Well, we all know that doesn't exist.
Right?
So,
um,
that was just a gaping,
gaping,
gaping huge hole
that hackers came on the scene and said,
you guys have this gaping hole
in the way you're building systems.
You're building systems with bugs in them.
And we're gonna exploit those bugs
and we're gonna bypass all of your controls.
Um,
the other,
the other,
uh,
aspect of the way computer security was,
was thought of was,
was CERT.
And,
uh,
CERT was formed after the Morris worm
in order to,
you know,
basically put information out there
when they knew,
when there was attacks that happened.
The problem was,
this was really a government funded
and a government organized with a government mindset.
And,
and the mindset back then was
sort of like the intelligence communities today
is like,
yeah,
we'll hoover up a lot of information.
We'll analyze it
and then we'll give out the information to you
that we think you should have.
Right?
So basically CERT was,
they wanted to be in control
of
vulnerability information,
weaknesses in,
in software,
uh,
weaknesses in configuration.
They wanted to be in control
and manage
how the public knew about weaknesses.
So if you reported something to CERT in 1993,
it might just go into a black hole.
And they might stop communicating with you.
They said,
hey,
we're the good guys.
Send the information to us
and we'll make sure
that security gets better.
But what we found out
was we would send them information
and we didn't know what,
what,
what happened to it.
We didn't even know
if they contacted the vendor.
We don't even know
if the vendor patched the software
or what patch was available
to fix the issue
we might have told them.
So it was a total black hole
and it didn't work.
So that government mindset
of closed,
controlled information,
um,
just doesn't work
when it comes to,
uh,
comes to securing our,
our world.
So in 1993,
I was just starting to get into
security.
I was involved with The Loft
at that time
and I got introduced
to this paper,
Improving the Security of Your Site
by Breaking Into It.
And to me,
this was
a,
a,
a seminal paper.
Um,
if you've never read it,
go out there and read it
because this is what really,
they really codified,
really,
how,
how the hacker mindset
can be used
to secure systems.
Basically,
what this paper said was,
why don't you study
how your systems
are being compromised,
see,
look at the technique
they're using
to compromise the system,
and then,
basically,
test all your other systems
to see if they have
that problem.
It,
I mean,
it seems completely obvious
today,
right?
But back in 1993,
this was actually
a new concept.
People who did security
for a corporate network
did not do this.
They didn't do this at all.
And so,
um,
what,
what Dan Farmer
and Weeti Venema did
was they started collecting
information about
how systems were compromised.
It was a trust violation
with,
you know,
exploiting trust
with our hosts.
Was it a weak password?
Um,
was it,
was it a,
a well-known bug?
And they started
to script these up
and,
um,
put them,
put them together.
And,
um,
what they really did was
they made
information security
a participatory sport.
There was this give and take
between the attacker
and the defender
where the attacker learns,
the defender can learn
from the attacker.
And,
um,
uh,
so studying the way
attackers behave
or simulating
how an attack might happen
or practicing
red teaming,
right,
um,
were all things
that hackers brought
to the table.
And they made security
an active participatory,
uh,
activity
as opposed to a static
configure,
configuration
of features
and,
and technology.
Um,
so around this time
we started to see
the first,
the first hacker tools.
You know,
we have so many tools today.
It's completely awesome
how many people
write great tools
and put them out there.
But these are some
of the very first ones,
um,
that,
that came to the table.
Um,
you know,
I,
I,
I was looking sort of
for the,
what was the first,
you know,
hacker mindset
kind of tool.
And I,
I think it really was Crack
by Alec Muffet.
He came up with the idea
that,
um,
you could test the strength
of your passwords
and see if they're guessable.
Right?
It makes perfect sense,
right?
Like,
why not
see if your users
are using weak passwords
and tell them to fix it?
Right?
But again,
it takes that hacker mindset
to do that.
The normal security
person's mindset
didn't do that.
It took the hack,
hacker mindset
to kind of change that.
And this was a radical
notion back then.
Again,
it seems completely obvious
today,
but it really was
a radical notion.
It was so radical
that Randall Schwartz,
who was
assistant administrator
at Intel,
got fired
for running Crack
on the systems
that he was responsible for.
He was responsible
for the security
of the system.
He ran Crack
because he had read
about the tool.
He understood it.
It made sense.
I'm gonna see
if any of my users
are using,
uh,
guessable passwords.
And someone caught him
running this process
and doing this
and,
and he,
he got fired
and charged
with a felony
for running a security
tool,
uh,
a hacker tool.
Right?
It wasn't considered
a security tool.
Um,
this example here
is,
uh,
a program called
Satan
that Dan Farmer
and Weedsy Venema
wrote.
And they were
automating
all the things
that they were learning
from attackers.
Like I was saying,
you know,
secure your network
by breaking into it.
They said,
why don't we automate that
and why don't we
script it up?
So,
uh,
Dan,
um,
wrote this tool
and released it
and he called it Satan.
I'm
not sure
exactly what it is.
System administrator
toolkit
or something like that.
And,
uh,
once he released it,
he got fired
from his job
at SGI.
He was,
uh,
he was a programmer
at SGI
and they saw
that he released
a hacker tool
and he said,
we can't have a hacker
working at our company
that's releasing
these bad hacker tools.
This was really
the first vulnerability
scanner.
Um,
and,
uh,
now it's a huge market.
It's a standard thing
that you do.
But there was someone
who had the right
to first one
and the person
who wrote the first one
got fired.
So,
I,
I think some of the theme
that I'm trying to bring
across is progress
is made by people
who are making trouble.
They're doing things
that other people
don't like.
They don't like the idea
that these tools
are out there
that can break
into their system
because they don't understand.
Um,
and,
you know,
over the past,
you know,
20 years,
we've gotten more people
to understand,
but there's still things
that we have to do
to make trouble
to keep pushing,
pushing the envelope.
Um,
and then,
Hobbit wrote,
um,
Netcat in 1996,
um,
which,
if you haven't played
with Netcat,
at least read
the readme file.
It's,
it's just an awesome,
um,
look into
the mind
of someone
deconstructing
TCPIP
and sockets.
As far as I know,
no one's been fired
directly for using
Netcat,
but,
who,
things could still happen.
And then,
on the information
resources side,
who was sharing
the information
about all this,
all these issues,
how attackers
were working?
It was the hacker community.
It was Bug Track,
which started in 1993,
the same year
it started
in 1993.
And,
and that,
that really was the birth
of a new form
of information sharing
that wasn't controlled
by the government,
wasn't controlled
by CERT.
It was
people talking
to other people.
And,
that's,
that's really what started
the openness
that we needed
to,
uh,
to secure,
to secure our environment.
The,
the next step
in this was
hackers starting
to write commercial software.
This was
hackers sort of
moving into
the commercial space.
And I,
I think really
one of the first,
the first,
uh,
commercial software
written by a hacker
was,
uh,
the Internet Security Scanner
by,
uh,
by Chris Klaus.
And,
uh,
we at the Loft
started to think,
hey,
we could make
a piece of software
that is targeted
at system administrators.
You know,
most,
most,
you know,
tools that hackers write
for other hackers
are,
are command line tools.
You know,
Alec Muffet's crack
was a command line tool.
What we learned was
Windows,
Windows NT administrators
can't use that.
Right?
So,
we,
we,
uh,
we open sourced
our command line version,
but we built a,
a version with the GUI,
um,
so that actual
Windows NT administrators
could use it.
And,
and we,
and we sold that.
And we said,
hey,
wait a minute,
we can actually make money,
um,
you know,
building the tools
to help secure systems.
So this again
was another change
of,
of,
of just becoming more
of the security industry
at the time.
And then around,
um,
1998,
um,
we started to,
uh,
really interface
with Microsoft.
And we really started
to tell Microsoft
what was wrong
with their
networking protocols,
what was wrong
with the way that
we were building things.
And we came up
with the notion,
much like,
um,
uh,
Dan Farmer
and,
and Weetzie's,
uh,
notion of improving
your network
by breaking into it.
We said,
well,
wait a minute,
what about improving
the security of a product
by breaking into it?
So instead of looking at
the whole network
and finding the weaknesses
in the network,
why not look at,
isolate,
look at one piece
of software,
put that software
in,
in a lab environment
with your debugger,
your,
your packet capture,
and,
you know,
and,
uh,
other,
other reverse engineering tools,
and start to think,
hey,
we can actually secure
software by trying
to break into the software.
So,
to me,
this was sort of
the beginning
of,
of the process
that we,
that a lot of companies
use today
to actually try to secure
their software
before they ship
their software
But,
at the same time,
the security industry
still isn't,
isn't,
isn't woken up.
If you were,
if you were,
uh,
working and doing security
in,
like,
1998,
1999,
um,
they,
they're still doing this.
They're selling
security features.
That,
that's,
that's the only thing
that they knew how to do
to secure a network.
Or,
or selling compliance.
And we all know
that this is just,
gets bypassed,
bypass all those things,
and you ignore
all the compliance issues.
Right?
Like,
you don't even,
you don't even look at the book
and say,
hey,
let's see if they check
this box.
I'm gonna attack
and see if they check
that box.
That's just not
how the hacker mindset works.
It's,
it's,
it's,
so,
compliance is completely
orthogonal to the,
to the hacker process.
So,
in 2000,
um,
we decided to
basically,
a lot of people
came out,
and this is what we did
at the Loft.
We said,
let's take all the things
we're,
we're doing here,
the tools we're building,
the processes we're using
to reverse engineer software,
to pen test networks,
let's see if we can just do this
as a business.
And,
uh,
you know,
the,
the headlines were,
were pretty,
you know,
uh,
you know,
we're gonna use good hackers
to,
to fight,
fight the bad hackers.
Um,
the simple,
easy boxes,
right,
for the,
for the general public.
But,
the idea was
that,
uh,
we were gonna take all the things
that we were doing,
um,
that we had sort of,
um,
created over the last few years,
and we were gonna sell those
as services,
um,
to customers.
So,
I don't think we were the,
you know,
the,
the first,
you know,
company to do,
do commercial pen testing.
Um,
but,
it,
it definitely put it on the map
that,
uh,
that,
that you could use these techniques
to secure your network
and secure your software.
So,
some of the things
that we different,
did different
that other security consultancies,
uh,
weren't doing at the time,
but seemed
totally normal today.
This was completely new.
We conducted
our own vulnerability research.
It was a consultant,
consultancy
that had people going out
and pen testing
and people back at,
back at that,
back at the office,
um,
building tools
and doing,
research.
So,
um,
and,
uh,
we came up with the concept
of,
we can help you secure
your application
by breaking into it
for you
and telling you
how we did it.
Um,
and then other companies
started to follow.
You've probably heard of
Gardens,
went to VeriSign,
Foundstone,
uh,
went to McAfee.
I think McAfee still calls
their,
uh,
their,
their adversarial,
um,
security services
Foundstone.
And then,
shortly after that,
we had all kinds of
worms
that were,
that were affecting
Microsoft,
excuse me,
Microsoft products.
Code Red,
SQL Slammer,
I mean,
basically,
uh,
it,
it was,
it was pretty much
of a,
a disaster.
If you were in,
in,
in,
in Windows NT Admin
or Windows 2000 Admin
in 2002,
you were,
you were like patching IIS,
like,
on a monthly basis
just so you didn't get
wormed,
a worm attack.
It was really bad.
So,
Bill Gates came out with
the Trusted Computing Memo.
And,
he said,
um,
we're going to stop
everything.
We're going to stop
building software
the way we used to build it.
We're going to train
all of our engineers
on writing
secure software
because they,
they had a book,
um,
Writing Secure Code,
I think it's called.
We're going to train them
on,
on,
on that.
And then we're going to
build secure software.
Um,
the problem was,
they all read the book
and they all got the training
and then they went back
to their desks
and they still didn't know
how to build secure software.
They thought they could do it,
but they couldn't.
They didn't,
they didn't have
the capability
of,
of,
uh,
of making sure
that the software
they were releasing
was actually secure.
And,
uh,
because there was nothing
in their,
in their,
uh,
they had secure,
secure coding guidelines
but there was nothing
in their process
which was adversarial
in nature.
There was no process
of testing.
There was no process
of attacking.
So,
they,
they didn't
actually know
how to write
secure software.
So,
what did Microsoft do?
They hired a company
started by hackers
to come and teach them
how to
to secure their software. So Microsoft hired AtStake. I was there for months at a time,
helping them write, completely rewrite IIS, helping them secure Exchange, SQL Server.
We taught them how to threat model. They had no concept of threat modeling at the time.
You know, Microsoft likes to talk about how they have stride and they have all these threat
modeling standards. They learned it from hackers. Hackers taught them how to do that. What was
the hacker mindset for trying to break into a piece of software? So this came from hackers.
They didn't understand exploiting heap overflows. Their engineers just didn't get it. We had
to teach them that because they weren't going to fix buffer overflows on the heap because
they didn't think it was exploitable. They didn't have any concept of fuzzing software.
Dave Itell, who's now founder of Immunity, wrote the spike fuzzer while on the right
on the Microsoft campus because he wanted to fuzz the software that we were testing
for Microsoft. And he said, let me write a general purpose fuzzer called spike. And
then he later open sourced it. One kind of funny aspect of this was Dave wanted to do
this using his Linux laptop. And Microsoft explicitly said, you can't bring a Linux laptop
onto the Microsoft campus.
Dave We had to get special permission from some senior vice president. And it had to
only be in this room. And it was tightly controlled. They were afraid that if a little of that
software, that GPL software somehow got onto the Microsoft network, their lawyers had them
so scared that all their software would be GPLed. It was like the GPL virus is what they
called it. And they thought that using a Linux laptop was a really scary thing. You know,
now it's now, you know, Azure, you can spin up Linux boxes, right, so it's taken them
a long time to get over it. We taught them how to do things like find the attack surface.
We would do threat modeling with the engineers, and they would tell us about all the inputs
into the program, what other components it talked to. And then we would run something
like Sysinternals process explorer. And we'd be like, you didn't mention this namepipe,
you know. You didn't mention that it read from this file. And then we would run a list
And the people who built the software
didn't actually understand how their software worked
because they were calling into libraries
that were doing things that they didn't understand.
So we taught them how to go to the ground truth
to actually look at what the software was doing, right?
Take a reverse engineering process.
They could only think with a forward engineering process.
And so they didn't even,
the engineers at Microsoft
didn't even know how their software worked.
And so we taught them how to do that.
It's really interesting that Microsoft
actually ended up buying the company
that made Sysinternals.
And then this was sort of finally,
you know, we look at the Microsoft SDLC
as the standard, they like to say,
we have a great process for building software securely.
And they were the main contributors to ISO 2734,
which is the process
for building a software.
Where did they learn most of the stuff that's in there?
They learned it from hackers.
So we could say that if you think your software
is more secure today than it was, you know, 15 years ago,
it's because hackers taught software vendors
how to secure their software.
So, you know, basically I take this to about 2003 or so,
where sort of the modern era of security
and building software started.
And down to where we are today.
So penetration testing once was a scary thing
that you hired hackers for.
And, you know, you had to get special permission for it.
It's now a requirement, right?
If you're a financial services,
you have some certain compliance,
you need to pen test your applications, right?
So now it's a requirement.
People have a product security response team
to communicate with hackers, right?
And developers are using hacker technology.
And they're using the same techniques
as they build the software to test it
in order to make sure that that software is secure.
So today we really do have securing your product
by trying to break into it.
And I'm also happy to say that bug bounties came
because the idea of someone poking around in your software
and informing you about it became a legitimate good thing
that companies wanted to reward.
So this is really full circle from 20 years ago.
When if you, you know, there are people that would report bugs
and they would be threatened,
like Mike Lynn was threatened from Cisco.
And Dmitry Skylarov was threatened,
well, arrested because from,
he came to DEF CON about 15 years ago.
He was arrested because he was going to talk about bugs in DRM.
So we've come full circle from people notifying
of vulnerabilities.
And, you know, potentially getting arrested to today.
It's a, you know, it's all, it's all a good thing.
So now I want to take us to today.
And where have we come?
Where have we come today?
You know, it still looks pretty bad out there.
I mean, if you see what Petya ransomware worm
was able to do on modern, you know, modern networks,
huge companies like Maersk and FedEx,
the Ukrainian government,
it's still probably, it's still pretty bad out there, right?
The really crazy thing is nation states
are pretending to be hackers.
I don't know for sure if a nation state
released Petya or not Petya, what you want to call it.
But I find it very interesting that whatever their motives
and what they were trying to do,
they were trying to look like criminal hackers, right?
So this is now, we've, we've,
we've come to this point that this is just a part that the,
even people that are, you know,
doing offensive operations for governments,
they want to look like us, right?
They want to look like the people that go to DEFCON.
They think that that's a, that's how you,
that's how you hide yourself.
And today hackers are insiders, right?
We could be sellouts, we could be insiders,
whatever you want to call it.
I put the names of some of the companies up here
that people have disclosed.
I know that the three other guys up there,
I know where they work, but they,
they like to keep it a little bit,
a little bit on the down low.
Some people are still really paranoid.
But hackers, hackers are insiders.
You know, Mudge worked for DARPA.
You know, he was a government employee working for DARPA,
funding, using his insider position for,
to use DARPA funds to fund hacker style projects
like Charlie Miller and Chris Vlasic hacking the Jeep,
was funded through, through DARPA.
So now that we're insiders, we're really in powerful
positions to actually change, you know, change things.
And that's, that's a good thing.
You know, it was basically Windows Snyder and Katie
Masuris who over time got Microsoft to even do a bug
bounty program, right?
And they, they, they came from the hacker community.
And we all know insiders are more powerful, right?
But we're getting old.
We're getting older.
Right, we're old insiders, right?
We need the next generation to keep doing what, what we did.
Right, we need people to still keep making trouble.
And I do still pe, still see people out there making trouble.
I don't know, you, most people have probably heard of Justine Bone and
her company MedSec, which caused a lot of trouble for
St. Jude Medical Devices by selling their,
their, their, their, their, their, their, their, their, their, their, their, their,
their research around how their pacemaker had vulnerabilities that could kill someone,
selling their research to a hedge fund that shorted the stock.
That's making trouble.
That's trying to change things up.
They didn't do anything illegal.
Right, they, there is a lawsuit out there, but I think they'll probably be okay.
And they brought a new mindset into thinking about how should we,
how can we fix the market around cybersecurity for a long time.
It's been.
There is.
a vendor-customer relationship where the vendor decides how much security they're
gonna put in their products and the consumers have no visibility into it.
And, you know, it's kind of a, it's kind of a lemon market right?
Like you, you, the consumer has no power over
making their world a more secure place, and in, in, in general the average person.
And, and, what MedSec did was by bringing in the investor community
brought in another party, they brought in the owners of the companies.
The investors who own, part of the investment market and people.
of these public companies and brought them to the table and woke them up to say, hey,
maybe the security of these products is going to change how much money I make with this
company.
So it's not the people who are the employees of the company that, you know, were necessary
and in control.
Now, what MedSec did was brought in this other party, the investor community, and we're
starting to see more of that now.
Now, Ponemon Institute came out with a report showing how stocks dip after major vulnerabilities
are announced, and the study broke down how much it dipped and for how long the stock
dipped, and it turned out that companies that had a very good security, mature security
posture and had a really good response, their stock dipped less, half as much, and for half
as much time, whereas companies that were very immature from a security perspective
and had a really good response, their stock dipped less, half as much, and for half
and had a really bad response, their stock dipped twice as much and lasted twice as longer.
My analysis on that is the investor community sees the vulnerability from the mature company
as, you know, a black swan, right?
It's something that, oh, it happened, it happens to everybody, but it's not going to be a
regularly occurring event.
But when it happens to a company that doesn't have a good response and can't talk about
how they're securing their software, the investor community thinks, well, this is going to
happen again and again and again.
This is going to happen again and again and again.
This is actually going to damage the brand and hurt the company.
So we're starting to get the investors that own these companies to think about security.
So it's still early days, but I think that that's an interesting new angle.
So what I want to ask you to do is to make me nervous.
I want you to go out there and do something.
I don't want you to break the law, but I want you to do something.
I want you to do something that, after you do it, I say, I don't know if that's a good idea.
That was my reaction to when I first saw the MedSec incident.
I said, really, are we going to go down this path?
This is going to tarnish the research community.
This is going to make hackers look bad.
And then I thought about it, and I said, maybe we should give this a chance.
Maybe we should let this play out.
Maybe there's some big benefit down the road to this.
Someone's trying something.
But it made me nervous at the beginning.
It really did.
And so that's my call to you, is to do something that makes me nervous.
Because I've been doing this a long time.
I've seen a lot.
I made other people nervous.
But do something that makes me nervous, and I think that will be pushing the envelope.
So I just want to finish here with something a little bit practical,
and a way that we all can influence.
And that is the concept of security champions.
Now, I'm in the application security business.
I help companies build secure software.
And part of it is to build that security culture.
The security team can't do it all.
You know, pen testers can't do it all.
Hackers can't do it all.
We have to enlist the masses.
We have to get them to understand the security mindset.
And so the notion of security,
the security champion is, you know, take the example of a company that builds software.
In every development team or every scrum team in that company,
identify an individual who has the aptitude and the interest
in maybe learning a little bit more about security.
So their software developer is their day job.
Get them interested in security.
Give them some extra training.
You know, do some reverse engineering with them.
Do a capture-the-flag exercise with them.
Get them interested in security.
And if you can get, you know, one person in each development team interested in security,
it has a huge impact across the organization.
Because there's just not enough security people,
and there's a lot of people building software out there.
And I think you can take this to other places to educate people.
So I think that is something that we all have a responsibility to do where we work or in our lives is
to educate people.
And I think that is something that we all have a responsibility to do where we work or in our lives is to educate.
Because it can't be an us and them, you know.
I know it's called the wall of sheep, and there's a bunch of sheep out there,
and then there's the wolves, right?
But it would be great if we could get some of those sheep more educated.
So with that, I'm going to end it there.
This is my contact info if you want to contact me.
I don't know, Ming, if I went over time, if we have any time for questions.
We do have time for a few questions.
And if you have a question for Chris, and please have, you know,
we definitely welcome you because this is a fantastic opportunity right now.
The mic is all yours.
Hey, good morning.
Thanks for taking the time to speak with us.
Chris, my name's David.
I'm from New York.
I just, I wanted to ask you, I've read news articles,
and talk about how difficult it is for companies to keep themselves secure,
that they're effectively gladiators in this pit, going against everyone out there,
malicious and hacktivists and all the like.
Have you heard any theories or any proposals that are convincing
for how companies can share their data potentially with one another,
to say we found this vulnerability, this is something perhaps to look for in your work,
and kind of help bridge that gap and help them unify?
So what you're really talking about is information sharing.
And I'm a huge proponent of fully open information sharing.
I don't like all these little pockets of groups, government groups,
or just financial services groups, where they share stuff amongst themselves.
I think that's incredibly inefficient.
Right?
The idea of DEF CON, the idea of bug track, were to make information sharing completely open.
So I think we should have as open as possible, right?
Information sharing.
I don't care if the adversaries get the information, too.
As long as the defenders work on that information, it's better.
The problem with open information sharing is the adversaries take advantage of it,
and the defenders don't.
If the defenders took advantage of it, it would be fine.
So I'm all for as much open information sharing as we can have.
Thank you.
Anyone else for a question?
Thanks, Chris.
Do you think that yourself, other members of LOFT, and other individuals in the early 90s and late 90s
received the reward and recognition that they should, given what they did for the security sector today?
And just for the record, I don't, unless you convince me otherwise.
You know, I don't know.
I think I'm a pretty humble guy.
I don't need any more reward.
I've been very successful in my career.
I've met a lot of great people.
I get to stand up here and talk with you and meet you, so I'm fine myself.
I don't think I need a Presidential Medal of Honor or anything like that.
Do you agree with that as well?
Some of them probably would have a different answer, yeah.
So really quick.
What spaces do you think really need to be made nervous these days?
Could you repeat the end?
Sure.
What places or what sectors do you think really need to be made more nervous these days?
I missed the last part again.
No problem.
What places or what sectors do you think really need to get,
really need to be made more nervous right now?
Oh, okay.
I was missing the nervous word.
That's a good question.
I know the government is already nervous.
I think it's the IOT sector.
I don't think they're getting quite the feedback loop that they need to.
I think that, you know, people are just shipping products,
and ignoring things.
I think the noise level has to be raised there.
You know, we saw the Mirai botnet was sort of a wake-up call.
I don't think that changed how people are manufacturing these inexpensive IOT devices,
that, you know, it might cost $50, but it causes a world of hurt, you know?
Sort of like dumping your toxic waste in the swamp, right?
Just because something is cheap doesn't, to do,
or make, doesn't mean it doesn't have really bad consequences.
So, yeah, let's make them nervous.
Anyone else?
Maybe one more?
One more?
One more question?
Absolutely welcome.
Absolutely welcome.
Hi, Chris.
Thanks for the talk.
It was a great talk.
I want to ask you, sometimes when you get a software,
you want to reverse.
When you look at the agreement, one of them is,
do not reverse engineer.
Do you observe it and sit on your hand,
or you just go ahead and do it anyway?
I would go and do it anyway.
I think, you know, you can't ask for permission, right?
They're not going to give you permission.
So I would go ahead and do it anyway.
You know, as a,
as a company, it's something that I can't do at work.
I need to follow those rules myself.
But I don't think we would have gotten anywhere
with making better products unless people did that.
So, again, that's along the lines of making people angry.
Can you share with us where WeldPond came from,
or is that completely taboo?
No, it's, I can share.
It's actually a fairly boring story.
But quickly.
So the first BBS I connected to that,
it had a requirement.
I think it was called The Works in Lexington, Massachusetts.
Jason Scott was the guy who does textfiles.com.
Jason Scott, you probably all know, was the sysop.
And the BBS was set up that it said no real names.
You can't use your real name on the BBS.
You got to put in a fake name.
So I signed up for an account.
I was like, oh, I just,
I don't want to spend time thinking of some cool name.
You know, so all I did was I looked above my desk
and I had a map of the Boston area.
And I just put my finger up there,
and I put my finger on WeldPond,
which is a, it's a pond in Dedham, Massachusetts.
And that's where I came up with the name.
I didn't think I'd be using it 24 years later.
So that's where it came from.
No.
Thank you so much, Chris.
Thank you so much.
I, when we received this, when we received the CFP,
we were like, oh, my God.
You know, it's a tremendous honor for you
to give the keynote here at the Packet Hacking Village
and Speaker Workshops.
I cannot, personally, I cannot thank you enough
for everything that you've done for not only the community here,
but also for me personally
and my career as well, too.
And I'm totally very, very grateful for that.
So thank you for everything that you've done
for the community and for me personally.
And I also want to say a very special thank you
to each and every one of you here who was at this talk.
Just looking at this room right now,
now, this is my 11th DEF CON.
And it really, really does feel like going back to the old days
when I first got, when I got to a talk at Alexis,
not Alexis Park, but at the Riviera.
I mean, DEF CON talks, if you, if you, you know,
if you could believe,
were just as big.
So just like going back to the old days.
Thank you all so much.
Thank you, Chris.