The following content is
provided under a Creative
Commons license.
Your support will help
MIT OpenCourseWare
continue to offer high quality
educational resources for free.
To make a donation or to
view additional materials
from hundreds of MIT courses,
visit MIT OpenCourseWare
at ocw.mit.edu.
PROFESSOR: How you guys doing?
I don't know.
As Nickolai said,
thanks for inviting us.
It's a real pleasure to
come here and have a chance
to talk to everybody today.
I brought one of
my senior managers
who oversees the network and
security areas, Dave LaPorte,
who's going to talk
about some of the more
tactical details of what we do.
I'm going to talk
about the high level.
Feel free to ask
questions at any time.
So really your opportunity
free to ask any anything
you're curious about.
So there's no decorum in terms
of what you guys may ask,
at anytime feel free to engage.
And so I think I was sitting
where you guys are sitting--
I don't know-- it's
almost 20 years ago now?
PROFESSOR: Yeah.
PROFESSOR: [CHUCKLES]
So Nickolai and I
were a lot younger then.
And I was probably a
lot thinner by then
and had a little bit more hair.
You know, one of the nice
things about overseeing
MIT's infrastructure
and operations areas,
you can see all sorts
of interesting things.
And some of the things we'll
talk about, a lot of what we do
is dealing with
interesting problems.
And you know, there's
no shortage of things
in an environment like MIT's.
I think what's
really remarkable is
we run an open network, which
is a little bit of a good thing
and a bad thing.
We don't have a broad campus
firewall, for the most part.
And everything's
pretty much open.
If you guys want to run a
computer in your dorm, right
here in the lecture
hall, or anything else,
you have pretty much
unfettered access
to the internet, which is,
compared to other schools,
actually, fairly unusual.
You know, you may not
realize that as you sit here,
but that's not the norm.
And that brings with it a
whole slew of challenges,
in terms of keeping
things secure.
So pretty much, we're
wide open to the world.
And that means
anybody, anywhere,
from whatever country, from
whatever part of the planet.
If they want to reach out and
touch your device sitting here
in this room, as you're
sitting here today,
whether it's your
phone in your pocket,
or your laptop that you're
typing on when you're
sitting here, they can do that.
There's nothing to prevent
them from doing that, right?
And that's kind of scary, right?
So we did an experiment
a couple of years ago.
And we just took a device out of
box brand new, brand new Apple
laptop, and just plugged it in.
Registered it for DHCP and just
left it there sitting there
for 24 hours.
And we left TCP dumps
running to just take
an inventory of what was
coming into the machine
for a 24-hour period, just
to see what we would see.
And then we combined
that with, hey,
let's go and graph all the
various IPs, using GeoIP lookup
and graphed them, put
them on Google Earth
and see what that looks like.
And for one 24-hour period,
for an inauspicious or relevant
host which is just publicly
registered for the internet,
it received connections from
every country on the earth,
except for two.
In one 24-hour period, one host,
every country, except for two.
That's pretty startling, right?
Does anybody want
to take a guess what
the two countries that
were not trying to connect
to this machine were?
AUDIENCE: [INAUDIBLE].
AUDIENCE: North Korea.
PROFESSOR: Anyone?
North Korea is one.
Good.
Nope.
China was very
actively represented.
[LAUGHTER]
So might have been the
military part, I don't know,
but certainly was very
actively represented.
AUDIENCE: Antarctica.
PROFESSOR: That's right.
Antarctica.
Very good.
So you get the gold
star for today.
It's excellent.
Yeah.
Yeah.
And so, for one
24-hour period, you're
seeing yourself subjected to
potential attacks, threats,
malware, anything
else everywhere.
For one host.
And the entire MIT campus right
now compromises about, I'd say,
150,000 different devices.
And so, if you do the math--
you can do that outright.
You're good at
math here at MIT--
that's a lot of threats, right?
And you know that happens
all day, every day.
Right?
And that's pretty scary.
And you want to combine
that with something else
to make a little
bit more scared?
So Dave and I were sitting in a
meaning a couple of months ago.
This is kind of a follow-up
as to a power outage
that happened.
Any of you here for the
big power outage a year ago
or a year and a half ago?
It was an exciting time, right?
[CHUCKLES FROM AUDIENCE]
I was here for the big power
outage about 20 years ago,
when the entire city
of Cambridge was out.
Now, that was cool.
Except it was about
100 degrees, so it
was a good time to
go over to Boston
and see a movie in
a movie theater.
But one thing that
came out of it that
was really interesting to us--
I don't know,
let's talk about it
for a second-- but Facilities
department comes to us
and says, you know, this
has been really bad,
this power outage.
We've really had to spend
the last four or five
months going across the
campus and reprogramming
all these devices.
OK.
Well, they must have
some SCADA systems
that are connected to
their air conditioning,
or to the lights in the room,
the doors, things like that,
right?
You would think they do.
It's MIT.
Makes sense.
So sure, you imagine
they're secure.
Talk about that in a second.
And so we figured that was
pretty straightforward.
And they said one of the things
they had a problem with was
their devices keep
getting knocked off
the net, have these issues.
And the more you
start talking to them,
you peel back
layers of the onion.
You're like, what do you mean
your devices are on the net?
Say, well, yeah, our
devices are on the net.
Oh.
You must have some secure,
proprietary control
system, a control network.
And they kind of looked
at us with a blank look
and were like, uh, I
think that's what it is.
That's what the vendor told us.
And this brings up one
of the interesting things
of the internet of
things or the era
we're moving into is, for the
most part, when I was younger,
people using the internet had
to be fairly specific, right?
You had to fairly know
something that you were doing.
Today, everybody's using it.
And the bar to use it used to
be, when you ride the roller
coaster, thou shalt
be this tall if you're
going to ride this rocket.
It's gotten a lot
lower, all right?
And so through the
conversation with them,
we find out that they have
pretty much everything
you could think of
connected to the internet.
Everything.
One of the things
that was interesting.
MIT launched an
energy Initiative,
I don't know, five,
seven years ago,
when Susan Hockfield
was here as president.
And one of the
things Facilities did
was really grow the
internet of things on campus
to create these dynamically
managed buildings.
So when a classroom isn't
in use, lights will go off,
heating will change.
It's new.
They're doing things like
that across the campus.
They deployed a gigantic
control network.
Gigantic.
It's actually bigger than
our own campus internet is,
somewhat.
So their control
compromises, I think,
400,000 different
points that they're
monitoring across the campus.
Over 75,000 to 100,000 places.
And so the next question
you ask yourself--
Dave asks, with the
big, bright, wide eyes
is, how you guys securing that?
They're like, well,
we called you guys up,
and we were going to check.
And they put it in.
And they got an IP address
by going through a web form
and request an IP.
Requested IP, it's working.
And you know we're sitting there
going, yeah, this whole open
internet thing--
how are you guys securing that?
And the question, of
course, which is, you know,
when your blood pressure
goes up a little bit
was, well, it's secure, because
you guys take care of that.
So the security's
already taken care of.
And you know our look on
our face is a little bit--
what do you mean by secure?
Well, we have
corporate firewalls.
It's dealt with.
And everything's cool.
[AUDIENCE CHUCKLES]
And you know my
next question was,
can you show me where that is?
I don't know.
And you know, of
course, the response
was, well, everybody does.
And of course, we're
a little different,
going back to the
point I made earlier,
we operate a fairly
open environment.
And we've always believed
and it's MIT's philosophy
that we believe in defense
and security across the stack.
You don't want to depend on any
one part of the infrastructure
to implement security.
It's something you have to
do at every layer, right?
You don't just do it
at the infrastructure,
you do it at the application.
You do it all sorts of places.
That's not how these systems--
you know, the internet of things
on the SCADA side-- get built.
You know, that's kind of scary.
And so one of the
things we're seeing here
that we deal with, so in
addition to dealing with folks
like yourself who
are doing all sorts
of creative and inventive things
that keep people like Dave
and I up at night.
You know, the
internet's becoming
this utility that's used
for all sorts of things
across the campus.
And it's really
changed the dynamics
that we have to worry
about, in terms of threats,
security issues,
all sorts of things.
So now, you know,
when the internet
used to go down or have an
issue when we were students,
it was an inconvenience.
Right?
It was annoying.
In these most recent
types of event,
when the internet goes out,
people's air conditioning
stops working.
Your heat goes out, you know?
So the threats have
really changed.
And so for us, we deal with this
whole broad spectrum of things
where we operate as a service
provider for the campus,
providing services to
folks like yourself.
We also provide services
to all sorts of things.
And if you combine that with
our open network philosophy,
it creates a lot of interesting
use cases and threats
that we have to worry about
on a pretty persistent basis.
And people's expectation of how
the internet is going to work
and one of the things
that's also been eye opening
is these systems kind of grow.
When the power
outage happened, one
of the first questions
they had was,
why did the network
stop working?
Our response was, well,
there was no power.
And they said, well, that comes
from the batteries on the phone
system, right?
It's all taken care of.
Like, no, it doesn't.
That's analog phone technology.
Like, well, what's
the difference?
Well, you guys know a lot.
But there's this expectation
that these things operate
with the utility
service, whether it's
at the security level,
resiliency level, or everything
else.
And I love the folks that
have so much confidence
that these things are being
dealt with at that level.
But that's a big gap from
where we are right now.
And so we spend a majority
of our time trying
to keep the campus
environment running,
keep everything as
secure as we can.
Dave will talk about that
in a little bit more detail.
He'll give you some interesting
stories about the kinds
of things we deal with.
But it's an
interesting job, right?
And we see all sorts
of interesting things.
And I think the problems
just get harder and harder.
And I think the thing is is
the internet kind of expands.
And the internet of
things is a big buzzword.
How many of you have heard
of that before today?
You guys have gone to a
Cisco website or something.
Trying to sell you
expensive equipment.
But this whole phenomenon
where everything
is internet or
IP-enabled, that's here.
And unfortunately, a lot of the
people writing these systems
are not as studious as
people who went to MIT.
They create all sorts
of interesting problems.
So I think, for us,
the real challenge
is, when you look at security
from a systemic level,
it's just there's a thousand
little bitty pieces.
And it's really, really hard.
And even for us, we have to
deal with service providers
on the external side.
We have to deal with
our own customers.
We have to deal with
application providers.
It's this very broad
ecosystem of issues
you have to worry about to
provide security holistically.
And the challenge is
pretty bumpy at times.
And so from that
point, I guess I'll
have Dave talk a little bit
about a couple of things
we've seen.
You guys have any
questions before Dave
gets set up that you'd like to
ask on anything in particular?
Anything?
Come on up, Dave.
PROFESSOR: Oh, you've
got a question now.
PROFESSOR: Yeah?
AUDIENCE: Have you
seen any APT campaigns
attacking MIT directly?
PROFESSOR: Yes.
Yes.
I think what's interesting
is one of the things
we're seeing more of is--
you know, one of the things
Dave will talk about now that's
really hard is visibility.
If I told you the story
about the one laptop,
and we have 100,000 or
150,000 devices, and also,
if you think of the number of
IP addresses MIT has just having
/8 network, finding the needle
in the haystack is really hard.
So these APTs--
which we do have--
finding that noise
or that activity
going on within this
broad stream of traffic
is very difficult.
One of the things
we've have help with
is some of the tools we have now
are a little bit more advanced.
And we'll talk about
that in a minute.
But one of the things
we also see now
is law enforcement's help
from the Federal side
or from other parts where
they reach out to you
to give you guidance
in some of these things
where they see things like
that, which is very helpful.
But you know, operating
an open environment,
we've had a few of
these where I've
been really surprised that they
were going on, but they do.
And I think one of
the other things we're
going to see in the
future is-- today,
we do a lot of research
activity here at MIT.
It's one of our
primary missions.
The Federal funding sources
that provide for that research
don't really have a lot of
rules about how you do it.
As you'll find out, as you
go into your grad student
lives and other
things and you get
Federal grants for research,
whether it's private
or primarily from
the government,
whether it's the NSF, NIH, their
requirements are pretty vague.
One of the things we're
dealing with lately
is they'll say, we have a data
requirement in the grant that
says, you should have a data
policy about all the data you
generate from your grant
is going to be preserved.
All right?
And the way MIT does that is it
says to the PI, that's great.
We have this requirement.
Are you going to
take care of it?
They say, sure.
I'll take care of it.
Sign the document, right?
Compliance with that?
What they did with it?
It's left to the discretion
of the primary investigator.
So if the government was ever
to come to us and say, hey,
where's the data?
Just point to a faculty member
and say, hey, talk to home.
But one of the things
we're also seeing
is the government
saying, hey, look.
We're investing a lot of
money in doing this research.
We don't want to
spend all the money
and give the research
to another country--
in some cases, right?
So what we've seen on
the legislative side
or some of the Federal
funding agencies side
is a lot of them are coming to
us and saying, as an industry,
I think we some more security
departments for this.
And I think what's
hard for us is
MIT is very much an incubator.
We have an incredible
number of brilliant people.
And for the
administration at large,
we serve as sort of a
hosting company, right?
We incubate that activity.
We provide them lab spaces,
or internet connectivity,
or all sorts of things.
But for the most part, it's a
fairly federated environment.
People have a level of autonomy.
And so, as you have more
requirements coming up,
applying those across the
institution is very hard.
To go back to the
APT thing, there's
a tremendous amount of
intellectual capital here.
Tremendous amount of
interesting things
going on here that folks
outside this country
are very interested in.
And I don't know if
you guys know this.
What country do you think
is responsible for more
intellectual property theft than
most any place in the world?
Anyone want to take a guess?
AUDIENCE: That's a
dangerous proposition.
PROFESSOR: No, no, no.
But I'm serious.
I mean, one of the ones that--
it was really shocking to me,
because I never expected it.
And that's not to say
they're doing that here.
But anyone want to take a hint?
Come on, somebody.
Anybody.
AUDIENCE: China?
PROFESSOR: Who?
It's not China.
AUDIENCE: Russia?
PROFESSOR: Nope.
Wasn't Russia.
No.
AUDIENCE: Is it Canada?
PROFESSOR: Nope.
[LAUGHTER]
You're getting close,
though, but it's in Europe.
AUDIENCE: France?
PROFESSOR: France.
France.
That's right.
AUDIENCE: What was it?
PROFESSOR: France.
Yeah.
So yeah, you wouldn't
expect that, right?
But I have a bunch
of folks who work
in the industry side, commercial
sector, in the security area.
And one of the things
they have to worry about
is companies, some of them
located in this geography,
is that's one of
their biggest threats,
which is kind of surprising.
You would think it's Iran.
You would think it's all
sorts of other places.
No.
And so, it's interesting, right?
You wouldn't expect that.
And that's not to say the
US isn't doing it too.
Let's be honest, right?
We're just doing it better.
We're not getting
caught, probably.
But needless to say, it's one
of the more interesting things.
Another question?
You ready, Dave?
PROFESSOR: Sure.
PROFESSOR: Yeah?
AUDIENCE: What sorts of things
do you log on an IP sector?
[LAUGHTER]
PROFESSOR: Turn
the camera off now.
We log some fairly
interesting things.
I'd say, for the most part,
I'll be honest with you,
authentication requests, we log.
So when you log-in
through Kerberos,
you log-in through
Active Directory,
you log-in through Touchstone,
through our SAML iVp,
those things get logged.
We have very detailed
retention policies, which
we're happy to share with you.
It's published.
If you access a web page, if
you check in to read your email,
things like that, then
one of the problems
we have is correlating
all that information
would be fairly hard.
That's a lot of
different sources.
Dave will talk about
that in a little bit.
But that's pretty
much what we do.
We try to keep our
retention period, usually,
within 30 days.
AUDIENCE: So MIT runs
its own CA, right?
There's a root MIT certificate.
Private key [INAUDIBLE] Where do
you guys keep that private key?
[LAUGHTER]
PROFESSOR: OK.
AUDIENCE: Could you use
tamper-resistant hardware,
or something like that?
Or do you just put it
on computer somewhere
running Linux [INAUDIBLE]?
PROFESSOR: Well, wow.
Good question.
Yes, we run our own CA.
We've been running our own
CA since the late 1990s.
So in a whole world where the
web was doing authentication
using username,
password over SSL,
I think MIT was fairly
progressive there, doing PKI.
Now, I don't know.
You guys are a little bit
younger, but back in 1998,
they were telling me the year
of PKI is just about here.
It's going to be next year.
And we've been saying
that for about 20 years.
So hopefully, soon.
So in terms of how it's stored?
Tamper-resistant hardware,
that's a nice idea.
I like that.
That would be great.
That's not how we're doing it.
AUDIENCE: Is that
how the CAs do it?
PROFESSOR: So the CA's usually
do it through using USB keys
or other tokens that have
fairly involved protocols where
you can only access
information off
once it's been written,
in terms of you
could send something
out for signature,
but you can't actually
get the key off.
So they have a whole
way of doing that.
To be honest, the CA
server we're using now
was written before any
of those markets existed.
And so we've used, I'd
say, a typical MIT spirit
of being a little bit creative.
And so it is stored
on the file system.
It's stored in such a way to
make it difficult to recover.
And it's stored
in multiple ways.
And it's encrypted
with multiple keys.
And there's a variety of
system-specific parameters,
which I will not get into
every one of them here.
AUDIENCE: So it's more of
a security by security.
PROFESSOR: Yes.
Yes.
So if you know the
specific locations,
which may not even be files--
I'll give you a hint to look--
and you know how
many keys are needed
and you know how
many bytes to read,
you might be able
to figure it out.
But to be honest
with you, if you're
able to actually get on the
machine, it's game over, right?
If you're able to get on
the machine, it's game over.
You know, people who tell
you that they can still
break into the machine
and not compromise
the key for some ETA, nah.
I'd be very
skeptical about that.
So we try to be
fairly secure, but--
anyway, it's not perfect.
Other questions?
AUDIENCE: Typically,
what percent
would you say of
MIT accounts are
compromised at a given time?
PROFESSOR: Good question.
Not yours, right?
I think I'm amazed--
so does everyone know
what phishing is?
AUDIENCE: Mm-hm.
PROFESSOR: OK.
Good.
I can't tell you how many talks
I go to where they look at you
and they say, isn't
that like Seattle?
But that's a little bit
of an older audience.
Every time one of these
phishing things happen--
and they happen quite a bit
where these emails go out--
I will tell you, it amazes me.
You're the world's smartest
institution, all right?
As an alum, I'm pretty
proud to believe that.
You know, we're
the world's leading
technological institution
in the world, right?
I cannot tell you how many
people will reply to those
things.
It just always
amazes me how many
of them reply to
"Dear Help Desk,
here's my user
name and password.
It shocks me, right?
And some of them are faculty.
And they call the
help desk and go, hey,
I wrote back to
your quota message.
How come my quota
hasn't gone up?
And oh, by the way, like
my inbox is full now.
So what happened?
Well, they got 200,000 bounced
messages to be in their inbox
because it's being used
to send mass emails.
So I'm being honest.
I'd say we see 10,
15, 20 to 30 a month.
During one of these phishing
spikes, even larger.
And I think the ones that
have been really interesting
are the ones we
don't know about, OK?
And the government came to us, I
don't know, about a year or two
ago and said, hey, we
won't get into specifics,
but there's a
marketplace where you
can buy MIT usernames
and passwords so you
can access library resources.
And so they're bidding on them
online on these black markets.
If you'd like to access
all the materials MIT
has in their libraries
or on campus,
you can simply auction
one of these accounts
that they've compromised
off the web page.
And they said, oh, by the
way, do you know about this?
No.
No.
And so we see a tremendous
number of those.
The success of
the social vectors
for getting people's
credentials is
incredibly high, in particular,
across our industry--
Dave will talk about it in
a little bit, how you try
and mitigate those
things-- is very high.
And it's a little bit scary.
Yeah?
AUDIENCE: Dealing on that, is
there a way or some web site
to see all the places
you've logged-in
with Touchstone or something?
PROFESSOR: Yeah.
So we're working on-- one of the
things I talked about in answer
to the log question was
what do you guys collect?
We collect a variety
of information.
One of the things we don't
have the ability to do today
is to correlate.
So in our case, there's 30
different technology systems
involved in some of these
things, and different formats,
and all sorts of different
ways to generate it.
We are working to try
and make that easier.
And our hope is to give the
user community something where,
from a GeoIP or
other standpoint,
they can see where
their activity is maybe
over the last 30
days, or seven days,
or whatever their
retention period is,
to help inform
people about where
these things are happening.
Dave wants to go a step further.
He wants to have you can
pick a circle of radius
where you're allowed to
log-in from geographically.
And if you log-in from
outside that range,
it either shouldn't
allow it, or it'll just
send a text to your phone to
let you know that something
happened, which I think is a
step in the right direction.
But so yes, we're
working on that,
but we don't have it today.
AUDIENCE: You said there was
malicious traffic on the MIT
network?
PROFESSOR: Yes.
In terms of--
AUDIENCE: What's
the primary source?
Is it from outside going in?
Or is there malicious traffic
from the inside going out?
PROFESSOR: You know, I'd
love to say it's completely
from the outside coming in.
I'd say there's a fair bit of
it from the inside going out.
I think, realistically, we have
a tremendous amount of internet
bandwidth and connectivity.
We'll talk about some of these
more recent UDP reflection
attacks, which is
a great example.
But when you have
big pipes, it's
a good resource to use
to hurt other folks.
And so we see a lot of
that, I'd say more so
than stuff coming in.
Stuff coming in,
you see a fair bit,
like I talked about
with the laptop.
But I'd say, in terms of
actual volume of traffic,
the bigger stuff you
see is in and out,
in terms of just
sheer throughput.
AUDIENCE: How many
people connect to the MIT
Network on a given day?
PROFESSOR: On a given day,
I'd say like, I don't know,
100,000, 120,000 different
kinds of devices.
I'd say, people-wise, if you
figure people average 2-1/2
devices, probably 35,000 folks,
40,000 folks on a given day.
I think what's more surprising
is our visitor population's
fairly large in a month.
AUDIENCE: What's the policy
for running a TOR exit
node on the MIT network?
PROFESSOR: Policy?
What?
No.
[LAUGHTER]
AUDIENCE: Is there a
good reason not to?
PROFESSOR: So you know, MIT's
a very open place, all right?
And I think that's one of
the great beauties of being
a student here and one
of the things I've always
cherished about being here
is we're a place where
it's OK to experiment.
It's OK to do things.
It's OK to learn about things.
It's OK to develop new things.
That's one of the great
things about being at MIT
and it's what's special
about being here too, right?
That's what's pretty unique.
You don't need to go to
the policy office to say,
hey, I want to run a
core exit node today,
or I want to invent a
new anonymous protocol,
or something like that.
That's one of the thing's that's
really unique about working
here and going to school here.
And I think, for us, is it a
good idea or is it a bad idea,
depends how you're
trying to do it, right?
If you're doing it as part
of some thesis research
into an automatization
technique, some privacy,
it's probably fine.
If you're doing
it for the purpose
of running some kind of black
market ring or something
like that--
I mean it's probably
not a good idea.
But from a policy standpoint,
MIT's fairly flexible.
We really try to
balance the need for--
the institution has
a responsibility
to behave responsibly, right?
Let's just be honest.
As an institution,
we have to do that.
But we try as much as
possible not to encumber
the activity of innovation.
And so, for the most part,
that's worked out pretty well.
I'd say MIT's been fairly
successful over the last 125
years.
But you know, I think it's
one of those areas where
if one of those
activities was to place
the institution collectively
in jeopardy, then
we have to look at that.
But MIT does run a
variety of TOR exit nodes.
SIPI has some.
CSAIL has a few.
They show up on Dave's
naughty list like a plague,
but we do that.
You can't run that
at most schools.
Questions?
My esteemed colleague,
Dave LaPorte.
He from used to work in the
Harvard University network.
And he'll talk a little
bit about networking
at a liberal arts school, if you
get him outside of the office.
And he's also a teacher
himself at Northeastern,
which is great.
So Dave will talk
to you a little bit
about some specific examples
of the kings of things
that keep us up at night.
PROFESSOR: Oh, wait.
Wait.
I think I got it.
Loose connection.
OK.
[INAUDIBLE]
All right.
Hello, everybody.
My name is Dave LaPorte.
As this very verbose
title claims,
I am Manager of Infrastructure
and Security Operations,
which basically in
a nutshell means
I'm responsible for maintaining
and operating and securing
mit.net, which is
definitely a full-time job.
Today, I've got a lot
of content to cover.
I'm going to cruise through
it, to leave room for questions
at the end, because I think
that's probably where you
guys get the most out of it.
If anything's not
clear, just stop me.
Raise your hand.
I don't mind being interrupted.
But yeah, with that, we'll
start talking with the Security
Operations Team, which is
really the one central body that
does security as a
full-time job here at MIT.
We'll talk about
some of the events
that we've had in
the recent past here
and what we've done
to mitigate them
and to leave the current
state of security at mit.net.
We'll talk about the
current landscape, what
we're facing a lot of now,
which-- as Mark alluded to--
is to a large degree, social.
And we'll talk about
some future trends,
which are nebulous by nature, so
the slides are kind of sparse.
So the team there, as
you can see is Mark.
I report directly to Mark.
Under me, there's a
Security Operations Team
led by our team
lead, Harry Hoffman.
He has three people under
him, Andrew Munchbach,
who basically is
the analyst who does
a lot of the washing
of the systems,
does a lot of the
notifications to users,
responds to complaints
from the outside world.
Then Mike Hossle, who does a lot
of the engineering activities,
a lot of the forensics.
And you have Monique
Buchanan, who
handles a lot of the
correspondence and community
outreach.
Harry himself is also
extremely hands-on.
So I just want to
preface this whole thing
with we have a team of four
in a very large institution
with tons of devices.
So the federation
that Mark talked about
is really a necessity,
in order to even try
to secure a network
of this size.
So now, the portfolio
services we have and what--
we're going to blast
through this stuff fast--
consulting, we talk with
people and help them on campus.
Services, we provide some
services to the community.
And the tool set that we use.
The services we provide
are pretty varied.
We do abuse reporting.
So this is response
to complaints
from the outside
world, typically,
the vast majority of which
are Tor exit node-related.
[LAUGHTER]
They just are.
PROFESSOR: They just are.
PROFESSOR: Endpoint
protection, so there
are some tools and
products out there
that we install on both the
community at large machines--
you opt-in if you prefer.
If you're part of the MIT
domain, which is typically
administrative staff, some
might be auto-installed for you.
Network protection, these
are tool sets that we have,
either at the border
or throughout mit.net
that detect anomalies or
capture flow data for analysis.
Data analytics helps us
correlate, put all this stuff
together and try to get some
actionable intelligence out
of it.
Forensics are-- well, we'll
talk about those in a second.
Risk identification, basically
probing and assessment tools,
basically Nessus and
things that look for PII,
Personally Identifiable
Information.
which, being in Massachusetts,
we need to comply with 201 CMR
17.00, which is a Mass
regulation that requires us
to be able to identify where all
the PII on our network lives.
Outreach awareness and
training, just what it says.
Compliance needs, this is,
in large part, PCI DSS.
So PCI, being the
Payment Card Industry,
has DSS, which is the
Data Security Standard.
Believe it or not, MIT-- well,
you'll probably believe it--
MIT is a credit card merchant.
We have multiple
vendors on campus,
and we need to be
able to make sure
that that infrastructure
is compliant with PCI DSS.
So Security is a part of the
team that basically manages
and ensures that compliance.
PCI 3.0, which is the sixth
major update to the standard,
goes live on January 1.
So we're kind of in
the process right now
of ensuring compliance of
all of our infrastructure.
And providing reporting alerting
metrics on the work we do.
So here's some of the end point
protection products we use.
This eagle-- I think
it's an eagle there--
is a tool called CrowdStrike,
which is currently
being tested within
IS&T. Basically, it's
a tool that watches
for anomalous behavior
from a system call perspective.
If you're using Word,
and Word suddenly
starts doing something
that it shouldn't do,
like maybe trying to read
the account database off
of the system and a
bunch of passwords,
it alerts and throws a flag.
It's a cloud-based tool, which
we'll talk more about later.
So all this data gets
sent to a central console.
And should machines start
doing things untoward
from a heuristic or
behavioral perspective,
they get red flagged.
GPO here, these are just
Group Policy Objects,
so managed systems
which push down policy.
The S is Sophos.
It's anti-xrays,
anti-malware, anti-spam--
oh, not anti-spam--
but anti-malware,
anti-virus, all of
the typical stuff
that we expect when we buy and
end point protection product.
PGP does hard drive encryption
for select systems on campus
that have sensitive data.
Some of these tools are in flux.
The industry seems to be
going more towards a more
vendor-neutral
solution, if you want
to call it that, so BitLocker on
Windows, FileVault on the Mac.
So we're exploring
those options as well.
And Casper is a way to manage,
mostly Macs, to enforce policy
on managed Macs.
On the network protection side--
I'll just start down here.
Akamai is a company
that came out of MIT,
has a lot of MIT alums.
They also have
extremely good services,
so we have partnered with them
on a lot of their services.
And we'll talk about
them fairly extensively.
TippingPoint is an IDS vendor,
an intrusion detection system.
As I said, some of
these tools are in flux.
That might be one of them.
But we basically have an
intrusion prevention system
at our border.
We don't actually
prevent, we just detect.
So we don't actually block
anything on the MIT border,
except for some very
basic anti-spoofing
and standard rules
you'd find anywhere.
Stealth Watch is a tool that
generates NetFlow data--
or I should say
collects NetFlow data.
So we use Cisco devices,
but all network devices
will output details,
meta information
about the flows that
they're sending,
source port, dest port,
source IP, dest IP, protocol,
et cetera.
StealthWatch collects this, does
some basic security analysis
on it, and also
provides APIs that we
can interface our
tools with to do
some more intelligent things.
And RSA Security Analytics,
this is another tool.
[BANG] Oops.
It's, in a lot of ways,
like an IDS on steroids.
It does full packet
capture, so you can actually
see some content if
things get red flagged.
On the risk
identification front,
Nessus, kind of the de facto
vulnerability assessment tool.
So we typically
use this on-demand.
We don't unleash this
on 18/8 at large.
But if we get an
on campus DLC that
would like us to come in and
perform some basic assessment
for them, we can use Nessus.
Shodan is a computer-- they call
it a computer search engine.
Basically, they scan
the internet at large
and have lots of, lots
of good security data.
We have a subscription,
so that we
can leverage that intelligence.
And Identity Finder,
that's a tool
that we use in locations
where there's PII,
Personally Identifiable
Information,
in order to comply
with mass regs
and just to make sure we know
where critical data lives.
Forensics is a
business that is--
periodic?
I'm looking for the right word.
This isn't something we
do, until we do a lot of it
for a long time.
And then we don't
do a lot of it.
Basically, when cases surface,
we have the tool sets.
EnCase is a tool that
allows us to image drives
and go through them
looking for content.
FTK, the Forensic Toolkit and
the Sleuth Kit are other tools.
We often get called in for cases
where we have to image drives
for intellectual property cases
or whatever cases the OGC,
the Office of the
General Counsel,
needs to have
computers imaged for.
So we have all the tools
that's necessary to do that.
But frankly, it's
not our day job.
It's something that
comes up occasionally.
So how do we put all
this data together?
Mark alluded to correlation.
We have operating system
logs for managed systems.
You can see that
we have NetFlow.
We have some DHCP logs,
IDS logs, Touchstone logs.
Splunk is a tool that does
a lot of this correlation
work and take data that's
not necessarily normalized
and normalize it and
allow us to correlate
across different sources
to get more intelligence.
So when you were talking about--
whomever out there
asked about, maybe,
a log-in page that could
show where you last logged
in, et cetera,
Splunk would probably
be the enabling
technology for that,
because we can put
everything together,
we can do GeoIP lookups,
and really build something
on top of the raw data,
pull some actual wisdom
of that data, so that we could
present it to you in a page.
OK.
So now, we'll talk
about attacks and things
that you might find
more interesting.
We'll talk first about
Distributed Denial of Service
attacks, which we've
really received
a lot of in the past few years.
We'll also talk
specifically about attacks
that resulted from the Aaron
Swartz tragedy of a few years
ago, which ties in to the
Distributed Denial of Service
attacks.
OK.
So just a primer on
Distributed Denial of Service.
I apologize if this is remedial.
So Denial of Service
attack really
attacks the A of the CIA triad.
CIA triad's the foundation
of computer security.
It's Confidentiality,
Integrity, and Availability.
So we're going after
the availability, right?
We want to take a resource down
so that legitimate users can't
use it.
That could be
defacement of a page.
Very simple, right?
Digital graffiti, just ruin the
page so nobody could see it.
Could be resource
consumption where
you eat up all the
computation on a system,
all the bandwidth on a network.
Could be a single attacker.
But much more likely
nowadays, you're
going to invite your
friends and you're
going to have a
party and a DDoS,
a Distributed Denial of Service.
OK these are recent
trends in the industry.
These are pulled from
the Arbor Networks
State of the Internet report.
Hacktivism is the most
common motivation.
According to them, it's
40% of all claimed--
actually, those attacks that
are attributed, 40% of them
are attributed to hacktivism.
The next one is 39% unknown.
So it's dominating
the top of the heap.
Last year-- and these numbers,
I believe, are from 2013--
there were multiple
100Gbps attacks.
So the year before
that made news
because I think there was
an attack on Spamhaus that
was 300Gbpm.
This following year,
that's kind of--
I wouldn't say the
norm, but we're
seeing a lot more of that.
Longer-lasting attack,
this operation here,
Ababil, was a multi-month
attack against the US
financial sector.
It went on for months.
It was 65Gps sustained at times.
I've heard stories about
this-- but you can Google more
online--
where it was just relentless.
They just couldn't stop it.
And we'll talk about the way
that they ended up doing it.
But frankly, at
65Gbps or at 100Gbps,
you're at the mercy of
the attacker, right?
There's very few
organizations on the planet
that can sustain an attack--
can sustain-- can survive
a sustained attack
of that magnitude.
You just can't do it.
And we're seeing a shift towards
reflection and amplification
attacks.
So this is where you
take a small input
and generate a large output.
This is nothing new.
This goes way back to--
let's go ahead a sec, all
right, I left that slide out--
but this goes way back
to the ICMP Smurf attack
where you would ping a
broadcast address of a network,
and every machine
on that network
would respond to the
supposed originator
of the packet, which, of
course, would be spoofed, right?
So I would masquerade as Mark.
I would sent a packet to this
class's broadcast address.
And you would all respond
with packets to Mark,
thinking that he sent it.
Meanwhile, I sit in
the corner and laugh.
So this is nothing new.
This goes back-- I mean,
when I was in high school,
I was reading about this stuff.
[LAUGHTER]
So UDP and ICMP, but UDP is
a fire and forget protocol,
right?
It's not TCP.
It's not reliable.
It's not connection-oriented.
So fire and forget,
it's easily spoofable.
And over the past
year, what we've seen
are exploits of amplifiable
features of these three
protocols, in particular.
So DNS-- this isn't working.
It works with a clicker.
DNS, port 53, UDP, right?
Basically, if you sent
a 64-byte ANY query
to a misconfigured
server, it would respond
with a 512-byte response.
So that's an 8X
amplification factor there.
Not bad.
What we found personally
here on mit.net was,
when this whole trend
started, like most things--
EDUs and particularly here--
we were at the forefront
into this trend.
We were seeing this
before it really took off
against commercial victims.
But we saw a 12-gig DNS
amplification attack here,
which substantially impacted
our outbound bandwidth.
We have sufficient bandwidth.
But at those rates, if you add
that to legitimate traffic,
we started to notice issues.
And Mark and I had to
come in and resolve that.
SNMP, which is UDP port
161, very useful management
protocol.
But if you send a GetBulkRequest
of 64 bytes to a device
that's improperly configured, it
will respond with up to 1,000X
amplification.
So that's even better, right?
If you're an attacker, you're
going to target things.
And we saw huge attacks
against printers on campus.
So they would have a printer
with an open SNMP agent.
They would send packets to it.
And we would send back 1,000 of
them and pollute the internet.
NTP, Network Time Protocol.
In this case, a
misconfigured server
would respond to MONLIST
command, which would--
I'm not sure of the
amplification factor
on that one.
But that one's really,
really popular.
So we got hit pretty
hard with the NTP MONLIST
misconfiguration.
And we ended up
doing a few things
to mitigate all these attacks.
So on the NTP side,
we disabled MONLIST
on the NTP server we
could, which kind of
kills the attack in its tracks.
But this being a federated
institution where we don't have
power over nearly anything--
I shouldn't say that--
nearly everything,
there's just a lot
of things we just don't have the
reach to touch or the authority
to touch.
So what we ended
up doing was just
rate-limiting NTP at the border.
And that's been in place
now for almost a year?
Almost a year with almost
no negative impact.
So we rate-limited down to,
let's say, a few megabits,
which was certainly better than
the gigs we were sending out
to the internet previously.
So that's kind of
a solved problem.
DNS is a bit harder, was a
bit harder to take care of.
What we ended up doing
was started to leverage
an Akamai service called, eDNS.
So Akamai has this
service where you could
host your zones with them.
They're one of many providers.
But we had an
existing relationship
with Akamai, which I'll
talk about in a minute.
So we leveraged their eDNA,
bifurcated our DNS, our domain
name system space.
We put an external
view on Akamai.
We put an internal on the
servers that always served MIT.
And then we ACL'd off
the internal view,
so only MIT clients could
hit our internal servers.
And the rest of the
world hits Akamai.
The benefit of Akamai eDNS
is it's hosted in a content
distribution network.
It's all over the world.
It's being served out of
Asia, Europe, North America
East, West.
It's all over the place.
Most people can't
take down Akamai,
so we don't have to worry about
our DNS going down any more.
So that's kind of how we
resolved that problem.
OK.
So these are details of
the attacks themselves.
Source obfuscation, this
is probably remedial.
Why you do it, to avoid
detection and prosecution.
I'll skip that one.
OK.
So maybe you don't want
to hide your address
or spoof your
address, you just want
to destroy a target with bots.
So botnets are huge right now.
The "it's OK, no
problem, bro" was
used in that operation Ababil,
which really targeted the US
financial sector.
So in this case, rather
than just spoofing
a bunch of packets
from one host,
we're using a botnet
of legitimate systems
that don't necessarily
need to just spoof.
Since these are
legitimate systems
and they'll respond
to, say, a TCP synack,
we can actually do more
higher level attacks,
like attack an HTTP server
and do GET and POST floods.
They might hire stressors.
Stressors are basically
botnets for hire
where you hire them
to do load testing,
and they go and load test
someone else for you.
There's, no doubt, probably
legitimate ones out there.
But there are others that
aren't and are basically
denial of services for hire.
OK, so the mitigation
strategies.
We talked about
one, which is DNS.
We can use DNS to
mitigate these attacks.
So we have used
Akamai to do that.
In this graphic here-- which
is probably too small for you
to see--
but basically, this slide
is way too far ahead
where it should be.
So OK, we had an attack
against our web server,
so I'll just brief
you real quick.
One of the attacks that
followed the Swartz tragedy
was an attack against web.mit.
They took down our web server.
The way we solved that was
we used our bifurcated DNS
to point internal clients
to web.mit internally.
And then we use the Akamai
content distribution network
to basically mirror web.mit.
And then we used
the external view
of our DNS to point
external clients to Akamai.
So when a user out
on the internet--
which we'll say is over here--
wants to go to
web.mit, they actually
go to the Akamai CDN, which
serves up the content.
If it's content that,
for some reason,
they can't directly
serve out cache,
it's dynamic or whatever, the
origin server, which is still
web.mit, and Akamai will go and
fetch the necessary content,
send it to the user, and
then potentially cache it
for some interval.
So short story here
is that the attack--
I'll talk about it in a minute--
but the way we solved it was
we put the actual web server
on the content distribution
network of Akamai.
The other attacks
that we'll talk
about-- this how we mitigated.
These two slides
are out of order.
So I mentioned a few attacks.
I mentioned the NTP attack.
I'm going to mention
a couple of others.
But basically, these
are attacks that
are just brute force, trying
to overwhelm our bandwidth.
And I mentioned, when
you get up into the tens
of gigabits range, a lot
of internet end users,
such as MIT--
you can name another service
provider, but a very large
user-- even we would
have trouble handling
tens of gigabits of traffic.
So in that case, your options
are really limited, right?
If it's spoofed
traffic, how do you
put a filter at your border
to block this traffic?
And even so, once it's
got to your border
where you filter it, it's
already flooded your pipes.
So how do you do this?
You have to push it back up into
the cloud, into the internet,
and block it there.
And the way that many
people are choosing to do it
and the way we've done it here
is through BGP mitigation.
So if you're familiar with
BGP, which is Border Gateway
Protocol, it's the protocol that
runs routing on the internet.
And it's a path
vector protocol that
uses ASN, so autonomous
system numbers.
So every multi-homed
organization on the internet
has an ASN, an
autonomous system number.
And BGP uses that
number to build paths
through the internet so that you
can have multiple paths to get
to a particular ASN.
In this case, I'm
using example 123,
because I created this
for another organization.
We're three, because
we're awesome like that.
Harvard was 11, so they're a
little slower to the punch.
But in this case,
we've got a path.
So we've got the beginning
of the path is ASN123.
The end of the path is 789.
And there's some sequence
of ASes, autonomous systems,
that this packet
has to pass through.
So what we're going
to with BGP mitigation
is just inject another
ASN into the mix.
And that ASN has
the capabilities
to handle this traffic on our.
So in this case, we have ASN456.
And they are going to be
kind of a sanctioned man
in the middle for us.
We're going to allow them to
advertise our prefixes so that,
when we come under
attack, if 18.1.2.3.0/24,
a small slice of 255 addresses
at MIT comes under attack,
we allow this AS456 to advertise
that prefix on our behalf.
Once that change propagates
across the internet,
all of the traffic starts
going into that AS.
And in this case, for
us, that AS is Akamai.
And they have lots of scrubbers
and can handle the high
bandwidth that we can't.
So on the back end
of that connection
is a private connection
we have into Akamai
where they send
the post-scrubbed,
the clean traffic out to us.
And that way, we can
avoid these sorts
of potentially
deadly attacks that
could just take us offline.
If you're getting hit
with that much traffic,
there's just nothing you can do.
So actually, before
we keep going,
any questions on what
we've covered so far?
Yes?
AUDIENCE: This is just more
of a networking question.
You mentioned the borders.
PROFESSOR: Yes.
AUDIENCE: And [INAUDIBLE].
So I'm trying to understand the
structure of the micro-network
and just what a
border actually is.
PROFESSOR: Let's see.
Let me see if I can pull
up a quick diagram for you.
PROFESSOR: [INAUDIBLE].
PROFESSOR: Oh, that's right.
Yeah.
It's a video camera, it's not--
So MIT really has three
border routers, external 1,
external 2, and another router.
Let's just call it external 3.
So these are our--
so basically, the actual mit.net
is pretty much a standard hub
and spoke topology.
We have core switches connected
out to a distribution layer.
And then they go out
to access layers,
which are basically buildings.
At the border, we have
these three borders here.
This is incredibly vague.
I apologize.
But we have multiple providers.
So for instance, our
commercial providers
will soon be dual home to
both of our border routers.
This external router 3 here--
which is not its real name--
but this external router here
is basically for
research peering.
So we kind of have a
delineation between commodity
and commercial peering
and research peering.
So all of the BGP
we're talking about
happens between the external
border and our providers
and back up into
the internet itself.
Oh, and these are just
choke point routers
that we have between
our border and our core.
OK.
So in response to the
Swartz tragedy of--
I believe it was two years
ago, I had just started here--
certain hactivists
took it upon themselves
to attack MIT as an institution.
So we experienced three attacks.
And I'm going to go
through all three,
because there were three
separate and distinct types
of attacks.
So the first attack was against
our infrastructure itself.
So at the time, MIT did and
does and will support openness.
And we have a very open network,
especially in comparison
to other dot edus, having
come from another one.
That can be a blessing and
a curse from a security
perspective, right?
So we're open to the world.
In this case, our border
routers, these guys here
that we just drew, were running
an older version of software
that was vulnerable to a
particular denial of service
attack.
So the attackers in this case
sent a very low bandwidth
stream.
I mean, it was really low.
It was less than 100k.
It would have been
totally non-noticeable,
without actually going on
the device and debugging.
They send it to the management
interface of those devices.
And those devices promptly
just keeled over, right?
They didn't die,
but the CPU spiked.
They weren't routing packets.
mit.net, at that
point, was offline.
So in this case, this was the
first attack we experienced.
I think it was during the
Patriots playoff game.
Sometimes, I think
these things are
planned to find it when staff
is not paying attention.
So it was during
that playoff game.
What we ended up
doing was immediately
upgrading the software to
a patched version, right?
That was a quick triage fix.
The longer term fix was that--
outsiders on the
internet probably
don't need to access our
management interfaces, right?
A very select few need to
access those interfaces.
So we ended up
implementing, basically,
the least privileged,
so that only at the IP
addresses of our staff
on VPN could access them.
And we stopped using clear
text management protocols.
So that one was fixed.
Then attack two came in.
PROFESSOR: There's a
question over here.
PROFESSOR: Oh, a question.
Sorry.
AUDIENCE: So is it not correct
that this was a zero-day attack
against the service provider?
PROFESSOR: I think it
would be fair to say
it was not a zero-day attack.
The second attack was
against web.mit.edu itself.
And this was what I alluded
to on the DNS mitigation slide
that I got ahead of myself on.
So web.mit was in
our data center,
protected by a firewall.
So it was behind a firewall.
What ended up happening
was that the attacker
sent a flood of HTTP traffic.
It was a GET and POST flood.
I'm not sure which one it was.
But basically, they didn't
kill the web server,
they killed the firewall.
The firewall keeled over
because firewalls too are
a blessing and a curse, right?
A stateless router access list
is very simple, is very fast,
but you also lose a
lot of the granularity
in what you can filter.
Because it's doing
it packet by packet,
you can only use the criteria
in each packet, ports, and IP
addresses, mostly.
We hid behind a firewall, which
worked well when it worked.
But when it came
under load, the state
required of the firewall--
because of firewall tracking
in every state, in addition to
the packets--
it died.
So the triage fix
for this attack
was that we moved it
to a routed network.
And that's something we would
have preferred not to do,
but you really had to, due to
the attack that was ongoing.
The longer term mitigation
that we performed
was that we moved
into the Akamai CDN.
So you may notice, if
you go outside of MIT,
as you go to web.mit now, it
doesn't resolve to 18.09.22
anymore.
It resolves to a C name,
which in turn resolves
to an Akamai IP address.
And attack number
three, this one actually
wasn't on the side of mit.net.
This was on the side
of our registrar.
So we found the
homepage of MIT--
www.mit and web.mit replaced
with this page here.
And we quickly did some
diagnostics on the web server.
Everything looked fine.
The server was not compromised.
It was not defaced like this.
And what we did
end up finding was
that our who is information
for our name and our actual DNS
delegations weren't working.
So in this case, you can see
the administrative contact,
"I got owned."
And then our address, "Owned
network operations, Destroyed,
Massachusetts."
They were clearly just
trying to poke at us.
But it was delegated
out to these two servers
at CloudFlare, which is a
cloud-based hosting provider.
So this is what
I call the troll.
This was on Gizmodo.
This was a bit of indirection
on the part of the attackers,
however many there were.
The hack went down like this.
So this is what
he told the world
very soon after this happened.
So once we realize
that it wasn't
MIT or anything on
mit.net that was hacked,
it was actually our
registrar, we got in contact
with our registrar.
We got our records changed.
We got everything locked down.
But of course, in DNS, there's
time to live values involved.
Some of them are hours.
So after this
attack was resolved,
there were still
some flux afterwards.
And during that time, we're
trying to clean everything up,
he posts on Gizmodo
in the comments
on an article about this.
"Own the MIT NOC guy
with a browser exploit."
That guy.
"Get their Educause
logins, which were blah."
So he goes through
the whole scenario.
But the vector here
was the MIT NOC guy.
So Mark is swearing at
the time, up and down--
not actually
swearing-- but swearing
up and down that it's not him.
He's not compromised.
So what we did end up finding
out after the fact was this
was published well
after the incident.
That link is still live, if
you want to read about it.
This was indirection.
It wasn't true.
The actual vector was that our
entire registrar was owned.
Our registrar, being .edu, is
run by an organization called
Educause.
Turns out that every
DNS registration
account had been compromised.
The attacker had this for
I don't know how long,
but they just decided to show
their hand with the MIT hack
here and actually use their
power to expose themselves,
but to also hack our DNS.
So this one wasn't
actually anybody
at MIT's fault, it was on
the part of our registrar,
which they soon acknowledged.
This was in February of 2013.
They mentioned that they
were in fact breached.
And we all had to
change our passwords.
And do we have two-factor now?
PROFESSOR: No.
PROFESSOR: OK.
But we ended up locking
down our domain account so
that it couldn't be changed.
But you know, it turns out,
if the entire system is owned,
if you check a box
that says, "locked,"
which prevents people
from updating it,
it doesn't do much good.
In any case, they've
fixed their system.
And this one wasn't
our fault, but it
was kind of an interesting
one because it really
subverted some of the core
protocols of the internet
in order to do this.
OK, so the current
threat landscape.
No, no, no.
[INAUDIBLE]
Ah.
So if you can't exploit the
silicon, exploit the carbon.
Exploit the use at the keyboard.
And this is what we're
seeing a lot of now.
I mean, from my
personal experience,
having been in this
for almost 20 years,
the network-based vector--
with the exception
of this year, which
I'll talk about in a minute--
but the network-based vector,
attacks that originate
on the network
and remotely exploit
hosts, that isn't
a lot of what we see anymore.
Computer systems actually do
seem to be getting more secure,
from the outside at least.
You know, Windows, and Solaris,
and Linux, in the old days,
maybe a decade ago, they used
to ship with all their services
enable.
I called it lit up
like a Christmas tree.
Everything would be on, because
on the convenience and security
continuum--
if we agree that one exists,
some people don't-- but they
were way on the convenient side.
They wanted everything
to work out of the box.
Whereas, I think we
found a sensible medium
where, when you install
a fresh operating system,
there is a host-based
firewall running.
And there aren't world
accessible services
running on a system.
We've also got things like
Windows Update and Apple Update
and package managers in
all the Linux distros,
so that a box that gets
online, pretty quickly,
will get itself up to date.
So you don't have these ancient
boxes with ancient services
open to the world.
OK.
So where I was going
with that is they've
moved up the stack now, right?
Maybe they're at level
eight or nine now.
They're dealing with people.
And they're trying to exploit
human failings or frailties,
like fear, or greed, or
trust, or familiarity, to kind
of leverage credentials, so that
they can exploit application
access or privileged access.
Rather than exploiting
hosts themselves,
they're exploiting people.
A few things we've seen on
campus in the very recent past.
This one here--
oh, I should say,
we have not experienced
this one on campus.
I don't want to scare anybody.
This has been seen, though,
across the nation in different
.edus.
And it's a very serious
threat, so we're
moving quickly to address it.
However, we have not
actually seen it here.
So this threat is
spear phishing.
And this is probably
remedial, but spear phishing
targets a particular community
with a plausible message.
So if you just get spam
messages or phishing messages,
they're just casting a
wide net and catching
people who, for some bizarre
reason, might respond to that.
However, in a spear
phishing attack,
if they're able to narrow it and
find a community of interest,
that they can actually say
something that sounds mildly
plausible, Bank of
America customers,
or MIT students,
staff, and faculty.
In this case, they were
able to choose communities
of different institutions.
I'm not singling anybody
out, but it is public.
And Boston University
was one of them.
They targeted the community with
bogus email messages pointing
to a bogus authentication site.
Some percentage of the users
actually clicked through
and logged in, which of
course, gave the attacker
the credentials.
The attacker then went
to the legitimate site
and redirected those
user's direct deposits
to an account
under their control
and emptied that account.
I'm not sure the dollars
affected there are public,
but it was probably
a large amount.
So in response to this--
I mean, how do you combat that?
To a large extent, it's a
user education issue, so
community awareness.
Just let people know
you can't trust email.
You just have to verify things,
before you click on them.
But from experience and
just knowing human nature,
that's only going
to get you so far.
There's always going to be
some percentage of people
who click on it.
And I'm amazed.
As you can imagine-- you
all probably are as well--
I'm a repository of all
the phishing messages
my family receives.
So I'm getting stuff from
my father, my sister, like,
is this legit?
And it's getting
increasingly hard to tell.
So you've got to actually
go into the headers
and see where it's coming from.
And a lot of male
clients now, they
don't actually like
to show you the link
that it points to, which
gets really annoying.
So it's getting harder.
So some of it is
just user error,
for lack of a better word.
And some of it is it's just
increasingly difficult to tell.
So at the root of the
problem, in my opinion,
is that passwords are just
a dead technology, right?
In terms of the factors, it's
something you know a password,
it's something you
are, maybe a biometric,
or something you have, a token.
So what we're doing to try
to mitigate this here--
because basically, these
man-in-the-middle attacks are
just stealing
something you know.
They're stealing your password.
Well, if we can also add
something that you have,
that attack is only going
to get them halfway.
They're not going to be able
to compromise your identity.
AUDIENCE: [INAUDIBLE] number?
PROFESSOR: You won't
be able to compromise--
the attacker won't
be able to compromise
the identity of the user.
So we are rolling out a
second authentication factor
in the near term that will be
tied into our Touchstone IDP.
We can release that
to these guys, right?
So early release, if
you're interested.
If you're go to duo.mit.edu,
we're using a vendor
called Duo Security.
It's a cloud-based two-factor
authentication system that's
being used in a lot of edus.
But basically, you'll register
your phone as a second factor
and you run a little
smartphone app.
If you don't have a
smartphone, I'm sorry.
But if you don't have one,
you can also do it via SMS.
It will actually call you
and tell you a number.
And you can also generate
one-time passwords,
a list of 10 passwords
that you can use.
So this is coming
soon to the community.
It is completely active at this
point, it's just not announced.
If you want to go to duo.mit,
you can opt your phone in.
You can actually
turn on Touchstone.
I'll give you a quick demo,
to show you how it integrates.
The beauty of using standards
and federated systems,
like SAML and Shibboleth,
which underlay Touchstone,
is that we can easily lay
on additional factors.
So in this case, I'm going to
just go to a tool that I use,
which is transparently going
to authenticate me using
Touchstone with my certificate.
But I should now
get prompted for--
too fast there.
Who runs this now?
PROFESSOR: Don't know that guy.
PROFESSOR: I don't know.
[LAUGHTER]
PROFESSOR: He got owned.
[LAUGHTER]
AUDIENCE: Yeah.
PROFESSOR: Give
me a site to hit.
I'm just drawing a
blank, because I'm
in front of a crowd.
PROFESSOR: Splunk?
PROFESSOR: Splunk.
No, not Splunk.
Because that's not a native
Touchstone integration.
Atlas.
PROFESSOR: Atlas, yeah.
[LAUGHTER]
PROFESSOR: All right.
All right.
PROFESSOR: Well, he's very
secure, at least, right?
[LAUGHTER]
The only real security is
to stay off the internet.
PROFESSOR: All right.
If this doesn't work in 20
seconds, I will move on.
PROFESSOR: Do you have another
browser, maybe, that's cached?
PROFESSOR: Maybe.
There we go.
Oh, weird.
OK, so here's my typical
Touchstone login.
Now, you're going to
just get one more prompt.
PROFESSOR: You're actually
off the Wi-Fi, it looks like.
PROFESSOR: Oh, yeah.
I did.
All right.
Well, let's leave that
demo for after class,
and let's edit that out.
[LAUGHTER]
PROFESSOR: In fact,
now I tried it--
PROFESSOR: All right.
I did not rehearse that
demo, so that's what I get.
But trust me, it works.
If you go to Duo, you
can register yourself.
And all of your two-factor
interactions-- or I'm sorry,
your Touchstone interactions
will all be two-factored now.
And you'll be super secure.
It really does work well.
Another threat we've experienced
in the past few months is--
this, again, is something
that's targeting not just edus,
but organizations
across the country.
But we've been getting
police called ID spoofing.
And this kind of transcends
the digital world,
for the most part.
Members of the MIT
community are getting
calls from local
police departments
nearby their hometown.
PROFESSOR: Yeah.
It appears to be a call.
PROFESSOR: Yes.
So these police departments are
telling them bad news, right?
They're telling them
you're about to be
charged with a crime.
I think some of
them are tax fraud.
Your family member's
been in an accident.
Of course, it's not real.
Their call's coming
from an attacker who's
using ANI, which is automated--
PROFESSOR: They're
using SIP, basically,
to forge their From field
in their voice call, right?
PROFESSOR: OK.
Which feeds into caller ID.
PROFESSOR: Which
then gets translated
by a bridge who trust the From
field that a SIP message to be
whatever number's placed in it.
PROFESSOR: OK.
PROFESSOR: And so the attacker's
like, all right, so I sign up
for a cheapie SIP service.
And I'll set my From field
to be the police department's
number in Lexington.
And I'll send it.
And once it gets to the
transcoding gateway that
turns it back into traditional
telephony, it says, all right.
Well, that's the
number it's from.
We'll just show it to the
user when it shows up.
PROFESSOR: So you
end up getting a call
from what you think is a police
department with extremely
bad news.
Again, they're exploiting
human frailty here.
In this case, it's
probably fear.
Maybe it's a little
anger, but it's the case--
PROFESSOR: Or guilt.
PROFESSOR: What's that?
PROFESSOR: Or guilt.
PROFESSOR: Yeah.
Yeah, I suppose.
[LAUGHS] If it's legit.
But in any case, these calls all
come to the same point, which
is you need to pay a fee for
something, which, on its face
is kind of bogus.
But once they've told you this--
I mean, if they told me that
my wife was in a car accident,
I would not be in the
right state of mind.
And I might believe
some craziness
that they tell me
after the fact.
So we've had people
on campus who--
I don't think it's actually
anyone's actually paid,
but we have had multiple
targets of this attack.
And again, this isn't just here.
If you Google it, you'll
find reports of it
in Pittsburgh newspapers
and all over the country.
But again, this is a spear
phishing attack, right?
They figure out where you live.
And they can do this by
just Googling your name
or just looking at MIT
and checking the directory
and finding out some
details about you.
And they just need
enough to be plausible.
And then they proceed to call
you and scare you and try
to extort you.
The mitigation
here is difficult,
because it involves
the phone system.
It involves multiple bridges.
Frankly, I'm not
a phone guy, so it
involves lots of stuff I'm just
going to wave my hands about.
But law enforcement needs
to be involved here.
You have to go to your providers
and work with law enforcement
to get that traced back.
Actually moved forward?
And one more along the spear
phishing email side of things.
There's another thing
that some people
call whaling, which is
the intentional targeting
of high level staff
at an organization.
We have experienced this--
I've experienced it elsewhere,
but we've also experienced this
here where they will send
extremely targeted messages
at high level staff,
using org charts,
using directories to
find plausible reporting
relationships, and write some
really believable messages
that, if you're not careful
when you click reply,
that wire transfer
number that they're
asking for isn't going to
the person that you think
sent the message.
It's going to somewhere on
the other side of the world
or the other side
of the country.
So we've been
experiencing this as well.
The short of it is-- in your own
security class, you know this--
SMTP is not a reliable protocol.
You can't believe
pretty much anything
in there, which just
runs completely counter
to human nature.
So take everything
with a grain of salt.
PROFESSOR: You going
to tell the story?
PROFESSOR: No, you can.
PROFESSOR: Yeah.
Yeah.
So you could tell it.
Basically, we had one recently.
And I won't go into the
details or the names.
Keep anonymity.
But a senior member
of the administration
reaches out and says,
hey, I got this email.
This is from someone
and says, I need
help-- a very senior executive--
with a wire transfer.
And so he sent me this email.
And I replied.
And he said he didn't know
what I was talking about.
And so how did that happen?
Is my email account hacked?
It says I sent this
email, but I didn't.
And to Dave's point, the whole
possibility that email itself
could somehow be spoofed,
without your account itself
being compromised, is very
foreign to people, right?
It's a trust relationship.
So it turns out, I
guess, it was someone
at an internet cafe in Nigeria
or something like that,
which we were joking about.
But yeah, they basically
went to the MIT org chart,
found a senior
executive, found someone
in the Vice President of
Finance office and said, hey,
I need you to help me with
this wire transfer call.
Here's the number.
And these are the kinds of
things that happen every day.
They didn't transfer
the money, obviously.
PROFESSOR: The email
was totally believable?
PROFESSOR: Yeah.
PROFESSOR: I've seen it.
PROFESSOR: Even the
tone and everything
seemed very plausible.
PROFESSOR: Yep.
PROFESSOR: They actually
used email messages
this senior
executive had written
that were posted
on public websites,
because they send
memos to the community
and things like that that
used the exact same style,
introduction, the way
they closed the message.
Even the language and terms
they used was identical.
This is stuff they had
used in other ways.
So it was actually
kind of creepy,
because even when
I first read it,
if you didn't know what it
was, it was semi-plausible.
And thankfully, the staff
member that it was requested
of-- like this was kind of an
out of the ordinary request,
it got flagged, even though
it looked legitimate.
And he or she responded
directly to the sender,
removing the Reply To
address and actually
putting in a known good one from
his address book or her address
book, and responded and
asked and kind of unveiled
the whole scheme.
But it could have gone
south really quickly.
OK, so I mentioned that
the network-based vector
in my experience isn't as
prevalent as it used to be.
And I'll kind of belie that
here, or make a lie of it here.
This year has been a
year of major exploits.
Every single major
SSL implementation
has been targeted.
There was Schannel on
the Microsoft side.
There was the Apple
implementation, open SSL.
There was Poodle with SSL v3.
This is SSL, right?
This is a security service.
So when you put a service
up facing the world,
you're going to run SSL.
So we had a lot of
world-facing services
out there that were vulnerable
to some of these things.
Shellshock was one that affected
the Bash shell where you could
remotely exploit a system.
So these are all kind
of the gold standard
of a network-based exploit.
They were remotely
exploitable, and they could
get administrative privileges.
So it's been a kind of a
nasty year, in terms of that.
So it's, in my opinion,
a bit of an outlier.
But how do we deal with this?
Because these
services are public.
They need to be public.
We can't just fence them
off, because they're
vulnerable to something.
The first thing is
automatic patching.
In the old days, the latency
between a zero day coming out
and a patch coming
out was fairly long.
That's shortening, and
shortening, and shortening,
so we're down to
literally hours.
So when these things
surface, we're
able to push out updates
to at least the systems
that we maintain.
The systems we don't
maintain, we're
able to use our communication
folks, like the communications
office and Monique
on the security team,
to craft messages to go out to
the community to at least alert
them to the fact that you
really need the patch,
because this is dangerous
and it's out there.
On the more active front,
we can detect these scans.
So the StealthWatch tool,
I mentioned way back,
is a tool that pulls
NetFlow data off
of our network devices.
And we can do some basic
heuristics on that.
And if we see an
outside IP address
talking to several
hundred MIT systems,
that's probably not good.
It could be good.
And if it's good, we will
totally white list it.
And we've done that many, many
times for research projects
and just things
that are legitimate.
But it's probably
not a bad posture
to say, OK, if we see
that, it's probably bad.
Let's block it.
So we actually have some
automated BGP null-routing
going on where we're
actually watching the flows.
And if we see an
anomalous behavior,
we null-route on-the-fly.
That runs every five minutes.
So as soon as a scan starts,
we cut it off at the knees.
On a more proactive
front even than that is
we will proactively scan.
So in the case of Shellshock
and some of the earlier SSL
vulnerabilities that
were really deadly,
we actually scanned
the community
and sent out lists
to those we had
contact info for to
let them know, hey,
this IP address is
running a service.
This is a known vulnerable.
Please patch it.
It's really just about
getting the information out
to the community as
quickly as we can.
OK future trends, because
we're running short on time,
consumerization of IT.
I call them future trends, but
the future is now here at MIT
and pretty much at any .edu.
These are old things that
we've been dealing with.
Bring your own device--
I mean, I've owned
my own phone here
and at other institutions
in the edu space forever.
It makes policy enforcement
really difficult,
because how do you
enforce policy on a device
that you didn't pay for
that you don't manage?
Consumerization of
services, here at MIT,
we have an enterprise
agreement with Dropbox
now, so that you can
store data up on Dropbox.
Unlimited storage.
That's open to students, right?
So yes, unlimited storage
on Dropbox, which is great.
The problems that
come along with that
are maybe data custody.
Where is that data
going to live?
In our case, we've made sure
that jurisdiction will always
be in the United States.
But what happens if you're
dealing with a provider that
crosses national boundaries
into areas where they
have different regulations?
What do you do if a person
puts sensitive information up
on that Dropbox and it gets
synced up to the cloud.
And they think it just
lives in the cloud,
but we know that Dropbox
syncs to the local system.
There's a lot of issues involved
with the consumerization of IT,
because the IT
department doesn't
control the service anymore.
They're really just brokering
the service between the service
provider and the consumer.
Third-party email providers,
kind of same thing.
You might send
sensitive information
through an email system
that's not totally internal.
So sensitive data might
leave the institution.
Cloud-based resources kind
of ties into that as well.
MIT never really
had a perimeter.
Neither does the rest
of the world now, right?
If you're a small startup--
and I'm sure you all have
many friends at startups,
I do as well--
none of them have local
resources anymore, right?
They're using stuff that's
entirely in the cloud.
How do you draw a
line or put a moat
around those resources when
they're living in Amazon Web
Services, and at Salesforce.com,
and as Google Apps,
and as Dropbox?
We need to find different
ways to handle that.
We have the same
data custody issues
as to where that
data might live.
We've also got authentication
and authorization issues.
How do you make sure
that just your users
are accessing those services?
And that's where
things like SAML
come in, which I think MIT
is really well-positioned,
because we have this really
robust SAML architecture.
When we wanted to
add Dropbox, it
was easy enough to add
them as a service provider
to our Touchstone
infrastructure.
And it just worked.
I'm sure I'm glazing
over some things,
but you know, in
the grand scheme,
standards-based and
federated systems,
like SAML and
Shibboleth are really
life savers in a
cloud-based world.
The internet of things,
what does that mean?
It seems to be the
new buzzword du jour.
But in terms of our
experience so far,
the internet of
things at mit.net,
we have building management
systems all over, right?
These are computer
systems that are
built by the fine
folks that built
air conditioners last year.
So they're not all that
secure, for the most part.
Mark had the story
about they were just
living on public mit.net.
They could be probed
by anyone in the world.
What we've started
to do-- and actually,
we're almost entirely done
with our building management
systems--
is move them onto a
different VRF, which
is a Virtual Routing
and Forwarding instance,
so that they have a completely
different forwarding path.
And we front-end
it with a firewall.
It's all access controlled.
It lives on separate physical
infrastructure in closets.
The closets are secured.
But when we move into a
internet of things world,
this problem is just
going to multiply.
What happens when the
light switches have
IP addresses and, who knows,
my shoes have IP addresses?
And it's going to get crazy.
So how do we deal with that?
And frankly, I don't
have an answer quite yet.
Many companies say they do.
And they'll make you spend
a lot of money on solutions.
But one of them I can think of
is maybe we map access policy
down to devices,
based on 802.1X.
So when I authenticate or
my device authenticates,
it pulls down the
thermostat policy,
so that it can coexist
on the same network,
and yet not be wide open to the
world as, say, my laptop is.
So with that, I realized
we're over, but are there
any questions?
Yes.
AUDIENCE: So there was
one page you skipped over
a coupld of slides ago.
PROFESSOR: Oh, sure.
AUDIENCE: Campus firewall.
PROFESSOR: Oh, I'm sorry.
Where was this?
AUDIENCE: I'm curious about it.
PROFESSOR: [INAUDIBLE].
PROFESSOR: I swear,
it wasn't intentional.
Oh, yeah.
Coming soon.
So this is-- do you want to
talk about it, or shall I?
PROFESSOR: Yeah.
So I'll talk about it.
I mean, one of the things
we realized, as David said,
is that your default posture for
things, you get it with an Xbox
you install it today.
You have IP tables by default.
Install Windows machine,
you have Windows host firewall.
One of the things
we look at is--
you know, you have
this internet of things
and this vast variety
of devices on mit.net
is having a more secure
posture by default,
so that devices, by
default, may not necessarily
be exposed to the
entire public network.
And there are legitimate
reasons people
want to have a device
on the public network.
And that's fine.
You know, one of the things
that's great about MIT is,
if people want to do that,
you allow them to do that.
They can do that in
an automated way.
They can do that by themselves.
They don't need to
ask a policy person.
They don't need to do
anything like that.
So what we're trying
to move towards
is really a network topology
where, by default, people
will be behind some
layer of protection.
If they want to go to a web
page and enroll themselves
in the public internet
level of access,
they can do that without
talking to anyone.
And it's automated.
And it just happens
within a minute or two.
And so I think what we're
trying to do is just
move the default security
posture to something
a little bit more secure, by
default. But at the same time,
we recognize that
our goal here is
to not really disrupt
the innovative activities
that happen here.
And so if people want to do
that, students or faculty,
on an opt-in basis and go to
the web page, that's up to them.
Any other questions?
AUDIENCE: I had one.
PROFESSOR: Sure.
AUDIENCE: What's the traffic
like now on the MIT network?
It's like, what kind of
traffic do you see the most of?
PROFESSOR: Yeah.
So I mean, looking
at StealthWatch,
I'd say like 80% of our traffic,
if you look at it by protocol,
is like HTTP, you
know, [INAUDIBLE].
PROFESSOR: Which would
include HTTP-streamed media.
PROFESSOR: Movies, media.
Now, I think the interesting
question you could ask
is how much of it is
legitimate research activity.
[LAUGHTER]
I know you guys are
all studying hard.
I know I was, that's why
I'm still working here.
No.
But yeah, it's
interesting breakdown.
I think the one thing
we do philosophically,
as a provider, is--
you know, a lot
of schools, there
was a time where
they were trying
to make judgments about
what kinds of traffic
and how much were going
across their campus networks.
MIT does not do that.
One thing we believe very
strongly in is not me
nor anybody else in
the administration
is in a position to pass
value judgment over someone's
internet activity.
PROFESSOR: Because
people live here.
PROFESSOR: You live here, right?
PROFESSOR: It's
not just your work.
I mean, people are doing a
lot of research on Netflix,
because we have a Netflix cache.
And we a lot of
traffic going there.
But we also have thousands of
students and staff living here.
So that's them at night
powering up their Netflix box
and streaming.
PROFESSOR: Or
whatever it may be.
So we've always been in the
position of like, you know, we
have some very detailed
information about what it is.
But I'd say that most
of it is, I'd say,
even nowadays, is kind of scary.
I'd say, at night, half of
it's video stream, which is--
AUDIENCE: Would you
allow torrent traffic?
PROFESSOR: Porn?
PROFESSOR: We don't.
No.
AUDIENCE: Torrents.
[INAUDIBLE]
PROFESSOR: Oh.
You know what's interesting?
So porn and torrents are
pretty similar, so yeah.
[LAUGHTER]
Not that that's what went
through my head Freudian-wise.
I'm sorry.
You know, it's interesting.
Torrent traffic has
actually gone down.
I think that's what's
been interesting.
I'd say it's actually
gone down over the years.
I think, on the plus side,
most things are getting so easy
for people to get through
something like a Netflix,
or an Amazon Prime,
or whatever it
is, where you can
subscribe for $4 a month,
where people are
generally doing it.
We have a Comcast
video TV service
we offer for free
to the students.
If you want to do IPTV, you
can just do it on your computer
now.
But for the most part, I've
seen torrents have actually
gone down.
I would just be honest,
which is kind of a surprise.
PROFESSOR: All right.
Well, let's thank Dave and Mark.
PROFESSOR: Thank you, guys.
PROFESSOR: Thank you.
[APPLAUSE]
