Mime-Version: 1.0
Message-Id: <p0432041bb68282cf8036@[216.254.65.44]>
Date: Wed, 10 Jan 2001 16:34:56 -0500
To: ops@mit.edu
From: Bob Mahoney <bobmah@MIT.EDU>
Subject: Security Zephyr Class
Cc: Security Team <security-internal@mit.edu>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ops:

I've added all members of the ops mailing list to 
security-zephyr-acl.   You can all now enjoy the splendor of our 
back-room conversations.

The hope is that this will allow useful and clueful people to help us 
do our work, and interact in useful and clueful ways.

Note that we treat our zephyr traffic in the same way we treat the 
mail and Casetracker logs: CONFIDENTIAL.  On that subject, please 
read the attached Confidentiality Statement.  If this is a problem 
for anyone, let me know and I will remove you.

-Bob

-------------

Confidentiality

Team members are frequently exposed to very sensitive data.  Examples 
include user passwords, information relating to criminal 
investigations, and security-related corporate information. 
Inappropriate disclosure of this information can compromise user 
security, derail criminal cases, or expose an outside corporate 
entity to serious financial harm.  Civil or criminal liability could 
conceivably accrue to MIT.

It is ESSENTIAL that team members treat the information they are 
privy to with serious care.  Proper care of such information is a 
REQUIREMENT for participation in this work.

Information from the team mailing list, or specific cases, are not to 
be shared with outside parties without permission.  To be very clear, 
this means friends, co-workers, supervisors, other security teams, 
and even law enforcement agencies.

Decisions to pass information to outside parties will be made by the 
team leader, in cooperation with the network manager.  If you believe 
there is information that should be passed outside the team, bring 
the issue to the attention of the team leader, or in the case of 
emergencies off-hours, the network operations on-call contact.

There are standing exceptions, please use good judgement in such instances:

1) You may always use other contacts you may be aware of to reach the 
owner of a compromised machine.  This is typically via friends and 
associates of the system owner.  Please make other team members aware 
when you use such paths.  Take care to avoid disclosure of 
unnecessary information not pertinent to reaching the appropriate 
contact

2) If an imminent threat to life, safety, or physical property 
becomes evident, it should always be treated as expeditiously as 
possible.  If the team leader or network manager can't be reached 
immediately, it is appropriate to take steps, typically by notifying 
campus police.  In a case such as this, it is expected that 
information has been sent to the team list, and that attempts have 
been made to page the team leader and network manager.

3) It is encouraged that team members pass local vulnerability 
information to the appropriate *local* contacts.  Such disclosures 
should be as closely targeted as possible.  An example would be a new 
vulnerability that affects critical MIT servers, where such 
notification should be made *securely* to the team or teams 
responsible for these services.

In all cases, disclosure should be made carefully and securely, with 
an appreciation of any possible negative effects from such disclosure.

While we have been fortunate to avoid serious problems relating to 
inappropriate disclosures, it is an important danger we face.  Team 
members are expected to be mindful of the seriousness of our work, 
and the potential harm facing individuals or businesses through 
careless action on our part.