A man who needs very little introduction,
although I don't know if he needs more time.
Are you ready?
All right.
So this is Mudge, and he looks different than he used to.
I remember a few years ago, I was standing at, I think,
one of the CTF parties on the balcony at DEF CON,
and hanging out there having a cigarette,
looking over everything.
And he walks out to me.
And he walks up to me, he's like, hey, how's it going?
You know, we've met a few times, but not a lot.
And we're yapping away.
And I'm sorry, but I meet a lot of people at conferences,
and I don't remember names very well, or who they are,
or anything like that.
And it happens.
And so he's talking to me, and I'm kind
of doing this blank stare, like, yeah, yeah, no, it's good.
Yeah. It's like, do you know who I am?
I'm like, I don't remember at all.
It's like, it's Mudge.
And I'm like, oh my, the last time I saw him,
hair down to here and everything.
It was, you know, in the loft, and at stake was all going on.
I don't think I'd seen you for three or four years.
And then he shows up with a polo shirt on, which was disturbing.
Yes. Honest to God, a polo shirt, short hair.
It was kind of frightening.
I jumped back a little bit.
I've never worn a polo shirt.
Never will wear a polo shirt.
Never will wear.
Button down, maybe.
Okay, okay.
I mean, that was a little hazy, too, it was Vegas.
But anyway, so Mudge has a proper job now.
And he's doing some really good work down at DARPA.
So we're really happy to have you here tonight.
And without further ado, I'll turn it over to you.
So here you go.
Thanks.
Thank you.
Thank you very much.
So first off, let me say this is really the first conference
I've spoken at as an actual senior official of the DOD.
And that's really kind of messed up to begin with right there.
They were willing to have me.
I don't know who's worse off in this going on.
But for the opportunity, I said I had opportunities to talk
at a whole bunch of conferences, a lot of large ones overseas.
And the one I actually wanted to talk at was ShmooCon.
And the reason is, and I'll go into this a little bit at the end of the talk here, is
that this is the community I came from.
This is the community I still relate to.
And all of the efforts that I'm trying to do in the government are influenced by that.
And trying to figure out ways that when I was running the loft, or when we were doing
the loft, I was the front person for it, it drove me nuts because I said, we're doing
really good stuff.
We're publishing it all out.
We're not trying to screw anybody over.
And god damn, everybody needs what we're trying to do with explaining how some of these problems
work, how they're fixed, how they're not fixed.
And why can't we get some government or some organization, not some government, somebody
in our government.
Yeah, to actually fund this sort of research, the type of stuff you're seeing here at ShmooCon.
And that's what I'm ultimately trying to do.
And that's ultimately why I took the position that I'm in, because it's a tremendous resource.
What I'm going to give as a talk is called an analytic framework to cybersecurity.
And I was asked to put this together by the director of the agency to work with some of
the other folks there.
Because I went up and I had some concerns about the way forward that our country and
in fact the world is going on cyber.
And she said, that's great, Mudge.
You've got six weeks.
Put together a plan forward and you're going to brief the deputy secretary of defense.
By the way, it better be good.
So at month three or month four of me being at DARPA, it was almost the end of my tenure
as a program manager at DARPA.
But long behold, six weeks later, after pretty much nothing but 16 hour days, no weekends,
a wife that was really, really probably taking the worst of it with me just being frazzled
there, we put something together.
Now this is not the full brief, but this is the large chunks of it.
Hopefully it gives you the spirit.
And this is what we've been giving to senior management.
And this is the message that we've kind of taken on some areas and issues that we see
and that we're trying to address.
So it is designed for higher level, kind of like that management level.
So some of it might be slightly soft, but there is tech stuff in it, unlike a lot of
the other briefs that I've been seeing that are saying cyber's scary, so invest more money
in it.
But not really giving you a way of understanding whether your investments are paying off or
whether they're the right thing or whether you're just continuing to tread water in the
middle of the ocean.
So with that said, I'd like to kind of go into this.
The first thing that we start out with is taking a look at what we're hearing in other
briefings within the government, what we're hearing in briefings from the private sector,
and what we're reading in the news and the media.
Not surprisingly, a lot of that stuff is the same thing that you and I as a person are
all hearing individually.
It doesn't matter whether you're in the government or not.
One of the first things that we hear is, I have to talk around this one only slightly,
is that it's trivial or it's easy to compromise our architectures and that it happens frequently.
Nobody's going to deny this because you can't go for a day or two without looking at some
media article about a compromised system.
So I wanted management to understand this a bit more personally and a bit more real.
So I went out and grabbed a couple friends of mine, some old colleagues who have a company
that's local, and we took a DoD system and I said, look, what can we do in about three
days' time?
And in about three days' time we had, I should say they had, they did all the heavy work.
I just sat there and asked them to do it.
That's kind of the position that I'm in now.
They did all the real work.
Two remote bypasses, 25 plus local escalations and bypasses, and this was on something that
we spend millions and millions and millions of dollars a year on just for the licenses
and to keep it up to date.
So that kind of drove at home saying this is a very complex environment, and yes, it's
not bullshit that these things are too complex, too large, and they have too many attack surfaces
to actually be able to configure and control and manage in mass.
The other thing that we're hearing is that users are a weak link.
Now the picture on the left with the array of USB keys was a tip of the hat to something
that the Deputy Secretary of Defense talked about in a Foreign Affairs article or an article
for Foreign Affairs Magazine where he talked about a previously classified but then declassified
because of the way he released it incident called, I've got to make sure I use the right
one.
Buckshot Yankee.
This is why they normally don't let much go out and give public talks so far.
What it was is we have a lot of different systems, and in Buckshot Yankee what happened
was there was somebody who took a USB stick that had an infected virus on it.
In this case it happened to be Agent.Bits, which was relatively well known.
There are signatures for it in most of the commercial virus software and plugged it into
a Cipronet system.
Now for those who don't know, Cipronet is the secret IP routed network for collateral
secret communications and lo and behold there's a virus loose on Cipronet.
Now why did that happen?
Well we airgapped these systems and we airgapped them intentionally to stop bad stuff from
going on them, just such a fashion.
But we oftentimes don't think about the sort of mission and environment that they're deployed
in.
So you have somebody, some Sergeant, some Corporal that's over in a forward deployed
area who's got people yelling at him or her saying, you know, get that information over
on the system, we need it right now.
And you're going, I got a USB stick, I can get the information, I can move it across
there, but policy says I really shouldn't.
You know, you're trying to accomplish a mission, the mission's going to take priority in those
situations.
Another area where we're hearing that users are a weak link is in password security.
Now I know a little bit about password security.
And in fact it's kind of humorous because I've now stumbled across environments where
you have to have a password for Microsoft Windows that is a minimum of 15 characters
in length.
And I said, wow, that's interesting, 15 characters.
That's kind of a magic number as far as Microsoft is concerned with Landman versus MTLM because
in Landman, you know, it's seven characters and then seven characters both against the
same key.
So an eight character, nine, 10, 11, 12, 13, 14 character password is no stronger than
a seven character password.
It's only when you get to 15 and try this, this is nice, a little dialogue box pops up
on your Microsoft product saying, warning, warning, we are about to make basically an
MTLM only hash.
This will not be backwards compatible with other systems using Landman.
And I've seen this in commercial organizations.
It's an interesting way of trying to get rid of the legacy requirement rather than just
going in and turning off the Landman hash.
So now I find myself and other people have to use 15 character long passwords, which
I probably did to myself.
So karma is a real bitch.
But the fact that certain organizations don't change having weak password hashes in their
systems is more so.
And I noticed there's going to be a really good talk with a panel talk on passwords as,
you know, what you have or what you know.
Looking forward to that one.
Some guys will crack me if you can.
You'll recognize one of these slides up here too soon.
So 15 character password, what am I going to do?
Well, I don't know too many 15 letter words.
So I'm not German.
Germans have no problem with this.
So I'm probably going to take two words and put them back to back.
Okay.
I'm at the 15 letter mark, but wait, there's more.
You need a number.
No, you can't use that one.
You need a number as well.
I'm going to have to change this thing every 40 some odd days.
This is going to, okay, I'll just put the number at the end.
You know, okay.
And each time I'll just rev it up.
It still says, you know, nope, nope, that's not strong enough password.
You've got to have special characters.
Amper, sand, at sign, hash.
I'll put it in between the two words.
And I have to have a mixed case as well, uppercase and lowercase.
Well, we're no longer in the Landman domain.
That's good.
So I might capitalize one, the first word or the second word or maybe the first letter
of each one of them.
And in environments that are really paranoid that require 15 characters passwords, when
you describe this particular process, a whole bunch of people's faces will just go beet
red because you've described the method that they've gone through to actually choose their
password.
And what seemed like it was probably like, you know, 53 or 57 to the 15th, you know,
50s has been greatly reduced.
So users are a weak link in certain ways.
How much it's their fault versus how much we've led them there is a question.
And we're also hearing that our physical systems are increasingly vulnerable to cyberattack.
And sometimes it's huge and horrendous and exciting and other times you're kind of going,
I don't get it.
So I threw up two examples here.
One is a snippet from the Washington Post which talks about what was referred to then as the
China Google incidents and talked about how China and the media picked up and said, oh,
30 or 40 other companies were probably hit on it.
Well, what they didn't explain was that it wasn't 30 or 40 other companies.
And I don't know who it was.
I'm not saying this is just the media that I'm referring to here that's giving attribution
to anybody.
But it was closer to 3,000 or 4,000 companies.
And the interesting part about it wasn't that it had actually been going on for well over
18 months.
But was that anybody who was anybody in the Fortune 500 was a target.
And these folks were quite successful.
And if you did telecommunications, computers or router equipment, there was a pretty standard
MO, which was they went right for the developer systems and they went right for the build
servers.
And when I heard that, I was like, oh, oh, oh, I know that one.
That's what we do when we were doing Red Teams or when we were going in on systems because,
of course, that's the crown jewels.
Because now what you're talking about is you're talking about a supply chain attack where
I don't have to be physically present.
I can actually change an array, a character array that's created in a header file somewhere
from signed to unsigned.
And now I've got probably, depending on the array and where it is, 15 or 20 reliably exploitable
attack vectors.
Good luck finding that one as you're going through looking for back doors.
You don't have to hijack a bunch of printers that are being sent to some area of interest
and put back doors on them.
You can do it from your home.
So OK.
That's a physical system that's interesting in how it's vulnerable to cyber attack.
And senior leadership is starting to understand exactly what this means and not just that
it's a, oh, supply chain, supply chain, because we hear a lot about that, but we don't really
understand what that means.
And I think a lot of folks consider some very valid supply chain issues such as where did
that microprocessor chip come from?
What was the fab design?
What was the process?
Does it do only what it says it's supposed to do?
And that can be a really challenging question.
But it goes further than that.
Or as Dino would say, like, who's burrito?
Where did that burrito come from?
Important things you want to know when you're purchasing food from a street vendor.
Same thing happens in supply chain.
And in the bottom right, one of my favorites is, and it's because I know some of the researchers
and some of the folks I work with were involved with this.
You'll notice this phenomena.
I'm sure a lot of folks here are already familiar with the car shark attack.
But this is an awesome one, because it really drives at home.
The speedometer's at 140.
The car's in park.
What does this mean?
Well, basically, imagine this.
You've got a guy twittering on an iPhone in a coffee shop in Seattle, and 100 miles away
is Chevy Malibu, and it was a Chevy Malibu.
Screeches to a stop.
The doors lock and the on-star mics key up.
It's not an exaggeration.
Well, not too much.
It wasn't 100 miles.
But that's basically what researchers from University of Washington and UCSD demonstrated.
Now, it was the third string copy, not stir-end copy, string copy, that they looked at that
was exploitable, and it took them about an hour and a half of code auditing to find it.
That was all they needed to figure out, oh, wait, this stuff is talking on the CAN bus.
Nice.
Which is where I've got my onboard diagnostics.
I've got my electronic submission to control, system five, system six, if it ever came out.
So increasingly, everything we're dealing with, and you guys know this, but this is
news to a lot of other folks.
Increasingly, everything we're dealing with is drive-by-wire now.
I mean, one of the first things I do when I get a new gadget is I rip it apart and see
if there are JTAG leads.
You know, it's like, yeah, what's exposed?
I mean, oftentimes, if I can just find serial pinouts, it's an embedded processor, and it'll
just talk to me.
Look at the Seagate drives.
There was a great talk last year at ShmooCon about, you know, see those little power jumpers
right there?
Everybody thinks they're power jumpers?
They're not.
They're the serial interface, and here's the entire command set you get for physically
moving and parking the heads and reading everything else and playing with the firmware.
This is fun.
Everything is hackable now, which is great, except for the fact that it's being deployed
out and it's being deployed out and relied upon without as much consideration.
So yes, physical systems are vulnerable to cyber incidents, but it's more at home and
personalized than I think a lot of people are explaining.
Now we, as a nation, spend a lot of money on this.
We put a lot of bright folks on it.
We've taken and centralized things.
You know, JTF, GNO, I'm sure folks have read much of the Joint Task Force global network
operations has now moved under cyber command, which is NSA, and dual-headed under General
Alexander.
There's a lot of smart people there, and they do a lot of hard work, and we all do, whether
you're in the government or whether you're in the private sector.
You see the budgets that we're spending on computer security.
You see the software that we're trying to roll out and keep up to date and keep the
patches up.
We're doing a lot, but it always feels like we're losing ground.
And that's really frustrating.
And then we see charts like this.
And we've all seen something like this.
Some measure of badness over time, increasing, which is scary, you know, very, very bad.
In this case, it's DOD-reported incidents of malicious cyber activity.
I don't even know what that means.
I don't know if that's port scans.
I don't know if that's an actual compromise.
I don't know, you know, what, but it's growing, and it's scary.
So I actually went in and I put the federal spending budget for all of our defensive efforts
and overlaid it on top.
That's billions there, by the way, for the red bar.
And except for this little blip, it's growing as well.
Now, that's really problematic because these sorts of charts lead you to believe that success
is actually measured by driving the numbers on the right-hand side down.
So if we're spending more money, lots more money, and the measure of badness keeps going
up, this isn't sustainable.
Okay.
Could be that we just don't know what we're measuring.
But if we don't know what we're measuring and we're just throwing more money at it,
that's not helping us either.
So why?
Here's where we get to the part that I kind of had some more fun with.
I went and I took a bunch of the defensive software applications that we've used, and
I started counting the lines of code.
Don't ask me how I had access to all the lines of code.
I started counting lines of code.
Sometimes I had other people count lines of code because, you know, whatever.
They might, never mind.
So on the defensive applications, I plotted them over time, and I called out a few interesting
metric marks here.
Dexil, Haystack Labs, Stalker, those were some of the first application-level firewalls.
You know, I'm seeing a few nods going, wow, I haven't heard that name in a while.
Milky Way was one of the first commercial firewall systems that was out of Canada, and
it had like a little encryption suite for peer-to-peer and a little management X-windows
sort of tool for it.
So that was the first like commercialization of an actual firewall and proxy setup.
That was the first snort from Marty Roche.
This was not the modern one.
The modern one is many more lines of code than that.
And Network Flight Recorder is called out because that's one of the first security appliances.
You would go out and buy it.
It was a solution.
It was an IDS solution.
You'd plug it in place, and it worked.
No, or it's supposed to...
You bought it, and you plugged it in.
It worked.
I don't know.
I don't know.
We wrote, the Loft actually was hired to write the first suite of detection tools for it.
So it worked.
It worked on the stuff we were looking for.
Unified threat management, that's your kind of all-in-ones.
The government, we call this HBSS, the host-based security system, which ends up being your
firewall, your intrusion prevention system, your access control list lockdowns, your configuration,
et cetera, et cetera.
It's all of those things.
We also call...
Other companies call it something else.
It may be like CA Unicenter.
It's your IBMs, your Tivoles, your kind of suites, your application suites, your McAfee's,
your semantics.
And we can see that in about 2005, we were already up at 10 million lines of code.
I took my malware collection sample, which is actually a bit more than 9,000 pieces of
malware.
Yeah, I still collect.
Hosts, so viruses, worms, botnets, exploits of all types.
And I averaged the lines of code for those over time.
And they stayed roughly constant at about 125.
This is really interesting.
Lines of code turned out to be a good unit of measure.
And we argued back and forth, oh, is that pre-processed?
Is lines of code the right one?
Lines of code is a good unit of measurement because it's a good proxy.
Because you can substitute complexity, time, money, level of effort, all for lines of code.
So if we do a simple substitution here, and we say one line of code is one dollar, just
a stupid substitution, what this game is telling me is that if you're playing the red side
and I'm playing the blue side, we're sitting down at a table and I have to put $10 million
on the table to play and you put 125 bucks.
You win, you take it.
I win, I keep my $10 million.
Then we play again.
I put another $10 million down, you put 125.
Somebody needs to tell me when I need to stop playing this game.
Because it doesn't look too good.
It also reinforces, yeah, yeah, one more time.
Damn, baby needs, ah.
It also reinforces a notion that being on the offensive side is more fun.
It's better, it's easier, you win.
If I'm on offense and I go after you, your defensive effort, and I fail, I don't manage
to go in, there's a good chance that I'm just no better off than I was before.
I don't actually step back.
On the defensive side, there's this thought that, oh, sorry, actually, if I'm on the offensive
side and I do get in, I'm a hero.
On the defensive side, if I put it in place and you don't get in, well, I'm no better
off than when I was.
I've probably spent some money, I'm a little more tired.
If you do get in, bad day in the office for me.
That's a conventional wisdom for the discrepancy between offense and defense.
I think this chart is leading to something which is, it's not about offensive defense.
It's about the sorts of environments and systems we've put in place, and the complexity and
the amount of effort, and what it costs.
Can I do this unified threat management with two people in a matter of three months?
No, probably not.
Really probably not.
But I can do any of these 125 lines of code effort.
But I started thinking back, and Casper Dick from Sun Microsystems, who's a friend of mine,
and somebody I really look up to technically, when stack-based buffer overflows were being
popularized in my 1996 timeframe, and again, I might have had something to do with that.
Casper said, oh, Mudge, this is why your stuff doesn't work on Spark, because we've got a
sliding window register.
And by the way, watch this, with a couple lines of ADB on the kernel, I'm just going
to make the stack non-executable.
So my buffer overflows were more lines of code than his two-line ADB mod.
So there's an example where it was more expensive for the attacker than it was for the defender.
And I think that's something that we're going to see more of in the future.
Well, we have to, because if we keep going this way.
This is the divergent with the threat.
But recognize this one?
It's not just in the lines of code and the effort and the complexity and the time that
we're divergent.
If you think back to that password example, where I gave you the 15 characters and how
the users came up to it, the guys at CoreLogic did a, they ran the crack me if you can challenge
at DEF CON this last year.
And what was really neat, and enabled me to kind of put this in the slide, and I'm always
giving credit to them for doing this, is part of the rules of playing is you had to describe
the process that you took.
And that was invaluable, because I was able to show the unintended consequences of the
people choosing the 15 character passwords in that previous example.
48 hours to crack all of these passwords.
They released the hashes out at the beginning of the 48-hour window.
You didn't know what the hashes necessarily were.
There were some Windows ones, some Unix ones, some SQL ones, all sorts of fun stuff in there.
And the neat part isn't, because the first thing the executive leadership and management
keys on to is, wow, 38,000 out of 53,000.
That's pretty good.
Well, you know, I'm sure there are some agencies that can do a little bit better than that
with the resources they have to throw at it.
But the neat thing is how they went about it.
So this is the winning team, Team HashCap.
And as they start, the gradual rises in the graph were described as, this is when we didn't
know what it was we were really looking for.
And we were kind of brute forcing.
And we'd make guesses, guesses, guesses.
And then we'd stop.
And we'd collect and we'd say, okay, what patterns are we seeing?
And so you might imagine, oh, they're 15 character passwords.
They're putting two words together.
And they put numbers at the end.
So we'll put that into our guessing algorithm and feed it back in.
And that's the area where you see the great shootups until they exhaust that sort of what
they've been able to harvest that way.
And they go back to a bit more brute force effort.
And then they say, okay, okay, okay, got a few more.
What are we seeing?
Oh, special characters in between the two words.
And then capitalizing the two.
And you'll shoot back up again.
So these environments, corporate, government, et cetera, that have imposed these 15 character
password requirements are longer and have done this, have unintentionally, after years,
conditioned and trained their users to actually start to engage in guessable routines.
They've turned their users into enemy assets, essentially.
And it was only 48 hours with the demonstration.
And any of us who have done auditing and where we go after passwords have figured this sort
of approach out generally.
Some folks have done much better at it and kind of fine tuned it.
But yeah, when we were doing Loftcrack or when we were grabbing the hashes there, it
was all about, can you make a good guess as to what types of passwords are in there in
the first place?
Because it might not be the key space you really thought it was.
So this one, we'll see if I have a job on Monday after showing this one, even though
it is redacted.
This is something called a vulnerability watch list.
And this was the sort of thing that JTFGNO runs.
They have a huge, huge job ahead of them.
Not ahead of them, but they have to do every single day.
And it's amazing what they're able to do with it.
So in addition to making sure patches get out and monitoring whose system is patched
and whose isn't for millions of computers, they get word of what vulnerabilities are in
place either from vendors or from other sources and whether or not they have it out in that
environment.
And they have to understand is there a fix available?
We can't necessarily go in and turn it off, so we have to track these things.
And this was a current watch list from a while back.
I've given constant Xs there so you couldn't infer which commercial products they were.
And just left the generic description of the problem there.
You'll have to trust me on this, but six out of the 17 that were being tracked right there
were security problems in the actual security software itself that was deployed out to fix
the system.
So like this bottom one here, remote privilege escalation vulnerability.
You wouldn't have had that if you didn't have that big antivirus suite in place.
Drats.
And this is disheartening as well.
This is again, could be a different one.
This is disheartening because you're spending all this effort layering on all of this extra
security, all of these solutions.
We're spending a lot of money for the licenses for it.
And it turns out that that's introducing more vulnerabilities.
How can you win?
And then you step back and go, wait a second, this isn't as surprising as I might have thought
it was.
Because remember that graph with the 10 million lines of code versus everything else?
Well, we didn't just plot, I didn't just plot the defensive security applications.
I started by looking at the size of operating systems over time.
You see that same blue curve going right up.
Then I looked at applications, just generic applications.
And you see that same blue curve going right up.
Many of the applications themselves are over a million lines of code.
How big do you think Microsoft Word is?
Yeah, they're too big, correct.
So with millions of lines of code, that's a big surface area that we're exposing.
So just how big of a surface area actually is it?
What I did is I went through the DOD environment.
It's eight, oh, you're evil.
HBSS fixes everything.
I'm not saying HBSS is bad.
I'm saying that it's complicated and complexity is oftentimes at odds with security.
So what I did here in the dark red, or kind of murky brown as it's showing up here on
the bottom, I went and I collected applications off of the environments I have access to.
Some are public, some aren't.
Not surprisingly, they're the same sorts of applications that are out in the commercial
world.
So I selected them off of Windows boxes, Windows XP, Mac boxes, OS X, Solaris boxes, and I
arranged them.
I ordered them from the smallest applications up to the largest, from the left to the right.
And I just numbered these 189, which were a good sampling of it, from 0 to 189 rather
than try and put all the file names there.
I ordered them by the number of functions that are in the actual applications, compiled
it.
Which you might think, so for something like Microsoft Calculator, that it's got a relatively
small footprint, relatively small number of functions, it's probably around file number
40 there, versus Microsoft Excel.
Not to pick on Microsoft, just probably over here at about 140.
If that doesn't look like it's much of a difference, the Y axis is in log scale.
So the green bars.
You might think that that calculator application is a much smaller surface area to attack than
the large spreadsheet one.
But when you run an application in a modern operating system, that ain't how it works
anymore.
You've got this really complex, dynamic runtime environment that pulls in all of these helper
libraries, these DLLs, these dials, whatever system that you're actually on, and brings
them in and maps them into the process space, which for things like return-oriented programming
and other sorts of environments are just masterful.
And that's what the green line is right next to it.
Each application, it's runtime number of functions that are mapped in and made available to its
actual address space.
That's a measure of surface area.
Depends on the type of attack that you're looking at, but it is a measure of surface
area that's viable for some of those types of attacks.
And what you'll see is if we take the median file number here at 100, that's about 100
functions, yet during runtime it's showing about 10,000 functions.
As an attacker, I'm happy.
This is really nice.
These are a lot of opcodes and opgrams that I get to choose from.
And in general, whether you're running a small application or a large application in the
modern operating systems, which everybody's using, there's no small risk and large risk.
Everything is a large surface area.
So we're divergent from the threat there.
IBM uses the metric that for every 1,000 lines of code, one to five bugs are introduced.
For that million line of code application, that's 1,000 bugs.
For the 10 million line of code defensive solution in place, 10,000 bugs.
Bugs are just exploits waiting to happen as far as I'm concerned.
And finally, some of the reasons that we're not winning on the security problem or why
it feels like we're losing is that we do it to ourselves.
This is a memo from OMB that says, to improve information security and reduce overall loss
of all IT operating costs, agencies who have Windows XP will blah, blah, blah.
They will run the same configuration, the same patches, the same access control lists,
because we want a monoculture because monocultures are easy to manage.
Except when you read things like the depth sec defs talk about things like Buckshot Yankee
that show that they're not easy to manage.
And it's really expensive and really costly to try and go clean up and manage these things.
So we've got a monoculture without the manageability.
And any of those bugs that you find in that 10 million lines of code or any of those bugs
that you find in all of that very large surface area that's being exposed, that one bug is
reproducible across those millions of systems that are all sharing those commonalities.
So up to this point, we've now been able to articulate why we're a bit into this quandary.
The U.S. approach, not just the U.S., but in general the approach to security is dominated
by a strategy that layers security on top of a uniform architecture.
Now, we do this for all the right reasons.
We're trying to buy tactical breathing space.
When something's biting your leg, you just want it to stop biting your leg.
I use the analogy, your plane goes down over the Pacific and you find yourself in the middle
of the ocean, you better start treading water.
And I'm not here to tell anybody, because this talk goes out to the different, you know,
the branches and the different parts of government, and I'm not trying to say that buying tactical
breathing space is the wrong thing to do.
You better start treading water.
But you better also have a strategy going forward.
Because three days later, if all you were thinking about was treading water, you're
still in the middle of the ocean and now you're tired and hungry too.
This is not a sustainable approach.
So we can tread water better.
We can do it more efficiently.
But ultimately, we have to start to understand the game more.
And that will enable us to do some of the things such as reduce the surface area, make
the users, you know, actually able to do mission, have mission performance, mission functions
without getting in their way.
So here's a couple of novel or one or two.
Oh, they removed one of my other slides.
I had to rush this thing through something called the DICTAR process to get it approved
for public release, which I'm sure they're regretting right now as they're watching me
on streaming video.
Anywho, no, that's a joke.
So business incentives.
We hear a lot of people saying in cyber, they're a bunch of irrational actors.
And you know, irrational actors are tough to deal with because, well, they're irrational.
And that might have been the case at the very beginning.
But there's money involved.
And there's actual access involved.
And there's value involved now.
And when that stuff starts coming in, there's a lot less irrationality and a lot more rational
behavior.
Now, if something appears irrational to you, you probably don't understand the game.
I guess it was the movie Rounders had the great line of, you know, when you sit down
at a card table, if you can't spot the sucker within the first 15 minutes, you are the sucker.
And I see some interesting scenarios and patterns here that are just showing that we aren't
understanding always the game that's being played and the incentive structures that are
going on.
So take one of my favorite botnets to look at, Storm, New War, PCOM, whatever you wanted
to talk about, whatever it was called.
It was one of the first peer-to-peer botnets that was out there, you know, distributed
hash tables, sort of lookups, a la academia and those sorts of protocols, which showed
that the folks who wrote it were, you know, wanted something a bit more resilient.
Traditional command and control botnets were known to be easily disrupted if somebody could
take out the C2 channel.
So they put some effort in up front.
Then they needed to figure out how some of the agents, some of the bots and the communications
channels would work.
So there was an XOR involved.
So take about five minutes, key up a string, propagate it out, and I had some obfuscated
people.
They had some obfuscated people.
They had some obfuscated people.
And that's how I ended up working for the government.
I always wanted to make that joke.
So they had obfuscated communications going back and forth between their systems.
It wasn't strong crypto by any means.
They used a smaller amount of keying material over repeated larger amounts of plain text,
or I should say they repeated the keying material over it.
So it would take, you know, a few hours to look at a bunch of captures of network traffic
and start to figure out, okay, here's what the XOR string is.
And that's what the antivirus industries would do.
So they'd get samples, and it would take them about ten days to do the following.
They would reverse engineer the sample to figure out the XOR string.
They would come up with a signature that would fit in their products.
They would test it in their labs, and then they would push it out through their distribution
and patch update systems.
At which point, guess what the bot herders would do?
They'd spend another five minutes and rekey the whole system.
They had about ten days running time.
Works very well.
You'd think, huh, this is pretty good.
Small amount of recurring effort.
Continue to run time.
They switched over to AES for a little while.
Nice implementation of it.
They waited, you know, three days, five days, seven days, twelve days.
We're past that magic ten day mark.
Fifteen days.
No updates from the antivirus folks.
So you might think, hey, in a scenario like that, the bot herders win.
Well, here's where it gets really funny.
They switched back over to the XOR.
Why might you do that?
Sales.
Yeah.
Sales.
Here's the, here's the, here's the, here's the, here's the, here's the, here's the,
here's the, here's, here's, here's, and hypothesis.
I might be curious if I'm the bad guy as to whether or not the antivirus folks have something
in their back pocket.
So I can put something out there for a while.
And if I find out that they don't, they don't have a solution for tagging the AES communications
back and forth.
Well, I don't want them to actually come up with one.
Because I just wanted to see if they had something.
Because if they come up with something, it's not going to be the tell that I know is obvious.
The little XOR string that's easy to find.
And when they come up with a signature for it, it might be a signature about something
that's baked more heavily into my entire system.
It might be a timing between my nodes.
It might be something else that I can't trivially change.
So if I want to play this game and I'm the bad guy, and they come out with a signature
like that, that's a lot of extra work and effort that I have to put in.
That's cost to me.
So we'll see here, that's not just taking down a branch.
That would be potentially a one shot, one kill on an entire tree.
But I'm happy when we can just work on the tree and I just lose a branch periodically.
And if you thought that was funny, here's where it just gets downright weird.
This works great for the virus vendors as well.
The anti-virus vendors, I should say.
How do they make their money?
Yeah.
They're a subscription service.
So they show their value to you by the number of signatures they can come out with.
Oh, you pay a subscription service.
Thank you very much, Dr. Mudge, because your check cleared and it's an evolving threat
scenario out there and this is why you want to keep paying for the subscription service.
We gave you 36 of them in the past couple months.
I go, wait a second, 35 of those were for the same darn problem.
So it's not that they're actually in cahoots, but it's that financially they've been incentivized
to come up with these recurring patches.
They can come up and do the research for the other one, but they also realize that it stayed
down there.
It would probably be a one shot, one kill.
They would come up with that signature down that road, but this is a quadrant which is
valuable for both the bot herder and the anti-virus vendors.
And so if you don't actually step back and understand the game that's being played and
understand this relationship and how folks are incentivized, you miss it.
So the bot herders win, the anti-virus folks win.
Who loses?
That's right.
So part of this framework, and this framework we use when we apply to our own programs over
in DARPA, and it changed some of the investment strategy where we said, yeah, we were also
doing a lot of buying tactical breathing space, and some of it was really good, and we've
got some notable wins out of that one.
But we really need to actually better understand what the surface area is that we're reducing.
What's the complexity?
What's the lines of code?
What is that asymmetry between the blue and the red?
How can we run programs, excuse me, over on the red side and force kind of the adversary,
whoever that might be, over to the expensive blue side?
So all of these were valid beliefs.
Defense in depth led to a uniform layer of network defense.
Host-based security system is an example, but it was an extremely large attack surface.
More areas of exploitability, and on top of that it was a homogeneous environment, so
one hits all.
Users are the best line of defense.
Educate the users.
Awesome.
So operator hygiene, 15-character passwords, unintended consequences.
They become predictable in ways that we hadn't actually game played out.
Part of that is because a lot of the defensive solutions that we take and we deploy are only
looking one step of the game forward, and they're only one option.
So if you only have one option available to you, you become a predictable player.
This isn't a good game.
The key to good strategy is to have multiple options available to you.
And then there's the interplay of technology, policies, and incentives.
We thought this is good.
This will favor good security.
We want an open market here, which made me think of the antitrust rulings for Microsoft
as they went to, or the threats of it in law as they went to VISTA and really locked down
the interface to access the system calls.
And a bunch of the antivirus folks came up, and I'm not beating on them.
I'm just saying that we've incentivized folks in strange ways.
Said this isn't fair because now we can't hook the system calls easily as well to look
for virus stuff.
And Microsoft, you're offering a security solution.
So there was some litigation that started happening.
And the result was that they opened up the kernel interface again and removed the security
progress that they had done in that particular aspect so that everybody could play.
That kind of stinks.
Now, the fun part that I didn't have to get cleared.
That's the sort of analytic framework that we're trying to look at security in a different
way.
Now, I mentioned earlier this is the community I came from.
This is the community I relate to.
But this community really isn't that new.
If you think back to the Homebrew Computer Club, there are a few folks here that are
old enough to remember that.
I was just barely old enough to remember.
That's where our first operating systems and home computers came from.
This is where Bill Gates was all upset when he had come up with a disk operating system
and some folks pirated it.
Well, they shared it because that's what was happening there.
And there's always been some contingent of cybersecurity researchers operating on low
budgets in kind of unique operations, unique settings.
It's because we've got this advent of considerable compute power now on the desktop, home fabrication
capabilities, and things like social networks, that these motivated people are actually more
able to seek each other out because motivated, curious people seek out and find other motivated,
curious people.
That's how I got involved in the community.
I'm sure that's how a lot of you folks got involved in the community as well.
And it's also that real world security skills are still largely taught in an apprentice-type
basis.
You can go to universities and learn some stuff about computer and security network,
and nine times out of ten it's going to be crypto because the universities know how to
teach math, and math is crypto.
And that's good, but it's not necessarily always real world.
And there are, don't get me wrong, there are a lot of organizations that will sell commercially
how to hack, how to become a white hacker or whatever.
And when you look closely at those, a lot of that is how to use a particular tool or
how to use the tools that are out and available.
But it's folks like us that are actually looking and saying, well, what are the tools that
are missing and how do I make them?
I don't care which side it is because I really don't see a difference between offense and
defense, which is kind of why I think that red-blue asymmetry is more about how things
have been structured and less about whether you're attacking or defending.
So makerspaces.
And what finally made me say, okay, this isn't just me who believes this.
I read a lot of proposals coming in because I am in charge of millions of dollars, and
they're taxpayer dollars, they're not my dollars, they're all of our dollars.
And so I really want to do the best thing about it.
And I read all of these proposals all the way through.
We have a scientific review board process.
And what I'm surprised by is in the citations and the footnotes as to where the secret sauce
is coming from, they're coming from presentations at places like this.
So whether the traditional government contractors and performers realize it or not, whether
this is their intention or not, they're telling me that the talent that we should be engaging
directly at a place like DARPA, the mad scientists that bring you all sorts of crazy science
and fund all sorts of crazy research, whether it's the internet, stealth technology, GPS,
etc., etc., UAVs, that we should be going directly out to you folks.
And I tried doing that when I first showed up at DARPA.
Some of you actually are engaged in some negotiations.
Some of you have done work with me there where I funded some of the research work we're doing.
And it's painful.
It is really painful for small organizations, boutiques, hacker spaces, maker labs to engage
the government and go through government contracting.
Because it's not set up for that.
It's set up for multimillion dollar, multiyear long efforts.
I want to build a new stealth technology.
Yeah, but they used to do this.
They did.
They did used to do it.
And we're getting back to that.
And that's why I went over to the dark side, because they need it.
And it's not about a recruiting pitch trying to get folks to come support the government.
That's not what it is.
I want you guys to stay like you are, because you're more valuable doing the type of work
that you're doing the way you're doing it now.
And I want the government to modify and change and make itself a resource to enable this
sort of work and to go out and fund the hacker spaces, the maker labs, and all the different
projects.
I'm looking at the things in...
Thanks.
That's how I feel.
And I look at the list of stuff being presented here at ShmooCon.
And I'm like, we should have been funding that.
We should have been funding that.
We should have been funding that.
And the great thing is I've got the approval from management.
I got the money put aside.
So Congress has given the money to do it.
The problem is now I've got to figure out how to do it legally in a way that's...
Checks and balance are really important here, because there are some reasons why the very
complicated process is in place.
But the government isn't trying to compete in the commercial world.
So what if we had like a seven page contract in place that was just firm fixed price, which
is something the government doesn't normally do.
And we can go out and say, hey, all of these things at ShmooCon, all of these types of
efforts, we can give you funding money for it.
We want it out there.
We want that research to keep going.
It's not about we want it to go dark or we want it hidden.
We don't even want the intellectual property for it in the commercial realm.
You keep all that.
If you're going to a venture capitalist or something and you're going, I've got to give
up 51% of my company and the intellectual property and some of the ownership here.
No, you keep all that.
We want government purpose rights so that we can pay for the hacker incubators basically.
We want government purpose rights because if we're paying for it, we'd like to be able
to use what we learn from it in the government.
But that's it.
That's just so that we don't spend taxpayer dollars twice to pay for something that we
already paid for to have it go in.
But go out and make your billions of dollars in the commercial world for it.
And that's what we're actually doing.
So I was looking online last night and I'll just wrap it up with this one.
Last year at 2010 ShmooCon, there was a ShmooBall launcher that was put together by a team of
two folks.
And I can get the names there.
Larry and Darren, 2010 ShmooBall launcher.
And they did a presentation at CohogCon and I couldn't make it up there.
But I saw the PDF online.
And A, I love the description.
A couple of dudes who do computer security, podcast, drink beer and build totally awesome
stuff in the workshop, much to their wives and wallets disappointment.
I can fix the wallet part.
I can't fix the wives one.
But at the very last slide it said next steps jokingly, get Mudge and DARPA to fund this.
Well, the joke is I didn't take it as a joke.
And it's called Cyber Fast Track.
And in about three months' time I hope to have this thing out on the street so we can
actually figure out.
And there will be pain at the beginning, I'm sure, as we figure out how to do this back
and forth.
But in a way where we can become a resource to the community by investing in it and have
more information spread so we can show that that asymmetry is just a crock.
Because when we do stuff this way, we are the asymmetric advantage.
And that's my talk.
So don't leave, don't leave.
There's important announcements.
First of all, we started tradition last year, two years ago.
You can go and give a keynote or a talk and they give you this little plaque and they
hold it up and say, here you go.
And you take them and you go, huh, I'm not going to put that shit on my wall.
And it goes in a drawer.
I challenge you to put this in a drawer.
So here you go.
Thank you for coming.
A couple of...
This is going on my wall in my office.
You can come and you will see it up there.
Awesome, awesome.
There will be a moose watching over Mudge every day.
You might want to scan it first.
You think it's a joke.
So a couple things real quick.
One, again, parking passes.
If you need the...
If you're here just for the day, coupons, coupons, it's not a pass.
You'll get free, you'll get it cheaper.
It's in the other room.
Get the little blue thing.
And on a more serious note, was there any other less serious things?
No.
So here's the deal.
I don't know how to say this any player that I'm about to say it, but don't fuck with the
hotel, please.
Because there's a lot of people here that enjoy coming here.
There's a lot of people here that actually enjoy putting in hundreds of hours to make
this happen.
And there's a time and place for shenanigans.
And I'll just go out and live and say this isn't one of those times and places.
So if you see people fucking with the hotel, encourage them not to.
If we see you, we will deal with it.
And the hotel will deal with it if they find you.
So anyway, that's it.
Every year I get to be a grumpy bastard on Friday to say the same thing.
So please don't make me do it tomorrow.
Anyway, any questions, concerns that things are working out well?
Yes.
All right.
See you all tomorrow.
Go have a good night.
Oh, fire talks are in the international ballroom at 8 o'clock.
Woo!
In other words, be mature party people.
Once again, brought to you by www.mediaarchives.com and mediaarchives.tv.
See you all soon.