Policies and Procedures Bob Mahoney MIT Security Camp

Policies and Procedures Bob Mahoney MIT Security Camp August 11 , 2000 1

Quick Overview of Network Security at MIT • Team info: http: //mit. edu/net-security • We are a major target, with an open network, many machines, & no firewalls • We have a Rules of Use document, but it is fairly broad. (Currently under review) • Security Team work blessed by MIT’s Academic Council 2

What? No firewalls? MITnet is an "open" computing environment: • Firewalls can raise barriers to legitimate traffic • Often no fewer dangers on the inside. . . • Can give a false sense of security • Firewalls are “icing, not cake”- host security should be considered first and foremost. 3

MITnet Rules of Use http: //web. mit. edu/olh/Rules/ 1. 2. 3. 4. Don't violate the intended use of MITnet. Don't let anyone know your password(s). Don't violate the privacy of other users. Don't copy or misuse copyrighted material (including software). 5. Don't use MITnet to harass anyone in any way. 6. Don't overload the communication servers; in particular, don't abuse your electronic mail (email) or Zephyr privileges. 4

Security Team History • ~6 years ago “net-security@mit. edu” managed by 1 individual, part time • 3 years ago the he left. . . • 2 years ago the team was started • Last year we even got a budget! 5

Volume of incoming requests, statistics • Average of 3 -4 new cases a day. • 60% of our cases are initiated by our own vulnerability scanning. • 419 cases opened in the last 90 days. • 33% increase from a year ago. . . 6

Composition of team • About 36 official team members • Active members: – 8 students (2 more have been hired as full-time, some have graduated) – 10 IS staff (1 official, 9 donate time) – 10 non-IS staff (from departments, labs and centers around campus) 7

Team Rules AKA, “The Riot Act” • • • Respect user privacy Respect operational confidences Get help/advice if at all unsure Avoid Gray Areas (or swim w/ a buddy!) Do not Tempt Fate… You will be held to a higher standard 8

The interchangeable role of staff and students • Everyone: – Responds to incidents – Scans for vulnerabilities – Participates in creating policies and procedures – Does outreach and training • Students are paid, staff do it as part of their job or on their own time. 9

How we track our cases: Casetracker • Homegrown system used throughout Information Systems, Oracle backend • Email and Web Interfaces to submit issues • Web & NT Clients • Uses X. 509 certificates for authentication and encryption 10

First Response • Email is seen by all team members. If the appropriate person is available, they deal. • We have specialists in NT, various flavors of UNIX, viruses, etc. • Depending on the situation we may: – – Respond to the report Contact owner of the machine (email or phone) Investigate more Remove machines from MITnet (remotely if possible) 11

Different situations that call for different responses • Machine is doing “something bad” • Machine is compromised, but not actively doing “something bad” • Another site says MIT machines are scanning them • Another site scans MITnet • Someone tells us that an MIT machine is vulnerable • We determine that a machine is vulnerable 12

General procedures • We always notify the owner or contact for the machine. • If the machine is actively misbehaving, we disable the machine’s drop. • We prefer not to do site visits for first offenses, but this varies with the situation. • We try to log everything. 13

Machine is doing “something bad” 1. 2. 3. 4. 5. 6. 7. Remove it from the network immediately Contact the owner Collect forensics (logs, files, etc) Advise them regarding cleaning up First incident: we trust them when they say its clean Second incident: NS member needs to visit them Respond to initiating site with status (e. g. , "We've taken it off the network, please let us know if you see further problems from this machine“) 14

Machine is compromised, but not actively doing “something bad” 1. Attempt to contact the owner, leave v-mail 2. Ask the owner to take the machine off the network 3. Usually, we disable the network drop (Machine must be off the network the same business day. ) 4. Then we follow the same procedure for an attacking machine. 15

Machine is merely vulnerable • Send machine owner a description of the problem, with pointers to additional info and resolution procedures. • Give a deadline for resolution, depending on problem severity and machine sensitivity. 16

In All Cases: Enforce deadlines, Monitor problem situations, and Escalate to Department Head or Provost as necessary. 17

Another site reports a scan from MIT • Ask the complainer to provide: – – – – time of day, time zone they are in, their IP address, what port(s) on their system, MIT IP address, source port number, frequency/duration of scan relevant logs to us in plain text. • If we don’t hear back, we close the log. 18

Another site says we are scanning them (more) • If we have the above information: – Notify the owner that their machine may be compromised, or that a user on their machine may be doing this. – Let them know they should stop (if it’s them) – If they are unaware of this activity, treat it as a compromised machine. 19

Another site scans MITnet • Report the scanning to the other site and close the log. • If they scan us again, report the scanning to their service provider and close log. • Repeat ad nauseam, escalate to our Network Manager if it seems worth while. • We encourage competent people who report scans to us to email the offending ISP themselves. 20

Scanning our own network for vulnerabilities The MIT Network Security Team periodically performs scans of all MIT hosts for known vulnerabilities. (Includes “Private” networks) I/S notifies the appropriate system administrator if it is found that a vulnerability is present. 21

Someone tells us that a machine is vulnerable • If the vulnerability is easy to confirm, we do so and treat it as appropriate. • In any event, we always pass the warning along, even if we can’t verify it. 22

Site visits • When the owner can’t fix the problem themselves (These hurt) • When it is part of a larger case we are tracking • When the vulnerability is new to us • When it is a repeat offender. 23

Checking up • Ask for notification that machine is fixed. • Need resolution before closing the case! • We prefer to trust people: if they tell us the problem is fixed or the machine is reinstalled, we believe them - the first time. • Repeat offenders are not allowed back on the network until after a site visit (staff or student). 24

Non-obvious MIT web policies • Can I put anything I want on my personal web server on the MIT network? • What defines a personal web server? Is this directed at students? • Can someone put anything on their personal web pages that sit on MIT servers departmental, IS or otherwise? 25

Non-obvious MIT web policies • What is IS's policy on an individual's web page or server getting millions of hits suddenly? • I just registered foo. org, foo. com, foo. net, etc. and I want it to point to my machine on MITnet. • What is the policy on downloading MP 3 files from Napster? 26

Lawyers - who needs them? : -) • Carefully pick and choose what cases go to law enforcement, it often isn’t worth the trouble. • Evidence of an external crime on a compromised machine - inform a law enforcement agency • Internal manners handled internally (COD) • Subpoenas: review by MIT lawyers (their purpose is to protect MIT) • Good working relationship with local law enforcement, DOD, FBI 27