Special CNIL Report, May 31st, 2004

Costas Spanos, Robert Wilensky, HuaPei Chen and Ron Fearing

Executive Summary
The five issues listed below are presently key focal items within CNIL:

•	Security. Our computing world has changed dramatically in the last year, and computing security is now a serious issue. In the past few months we floated some ideas about a firewall policy. We have collected many responses, and we now want to put a revised plan on the table that addresses most concerns and complies with recent campus policy.

•	SPAM is no longer just a quality of life issued, as it has grown to the point that is causing us daily frustration and lost productivity. We have been working diligently on evaluating various options to deal with this problem. Effective options will cost money, but there are also things we can do that cost next to nothing and will improve the situation.

•	Campus Policy on Sensitive Data. Yes, such a thing is actually emerging, and it will impact the way we do business. In this report we introduce the subject.

•	Collaborator Accounts. Not all our users have the same needs. In the past we have resisted creating many, finely distinguished user models, but now we propose to introduce just one new category of users with limited access needs, and correspondingly lower access fees.

•	Instructional Laboratories play a key role in the quality of the educational experience in our department. Consistent budget cuts over the last few years now mean that our resources no longer match our goals. What should we give up?

These issues are addressed next in some detail in this report. Please note that this report is not meant to be a comprehensive accounting of all the activities within CNIL, but rather provide a focus on these few issues that currently dominate our attention.

Security

The computing security situation in the summer of 2003 deteriorated rapidly, when new attacks seriously threatened our ability to offer a safe, reliable environment of our users. The rapid introduction of new viruses compromised many machines in our network, caused user downtime, and absorbed lots of resources. In response, we have initiated an assessment study which has been competed with help from Microsoft, and we produced a plan involving a hardware firewall in December of 2003. The original plan had three key drawbacks: 

•	It left portable computers outside the security perimeter.
•	It was weak in its ability to maintain systems integrity.
•	It would restrict some networking research activities.

As a result of these early discussions we now have a new design, with the following key characteristics:

•	Enables centralized patch management would ensure that all our CPU will be up to date with the most recent patches released by Microsoft and by antivirus vendors, thus drastically reducing the window of vulnerability.
•	It will harden current Windows Infrastructure to Win 2003
•	It will restructure networking topology within EECS to trusted, semi-trusted, un-trusted, offering further flexibility in its implementation.
•	It will involve a Hardware Firewall on critical or restricted systems (this is now a requirement of new campus policies on computing). Fixed systems within the EECS environment that have an auto-patch agent installed can access restricted or sensitive zones behind firewall. Systems without the agent will not be able to access directly.  Mobile or offsite Systems can only access via vpn (provided that they have the agents).
•	It will require all users to run local Software Firewalls in addition to the above. This is also according to a recent campus recommendation as outlined in http://socrates.berkeley.edu:2002/MinStds/ 

A department-wide security project is currently underway, and new security measures will be implemented in stages beginning FY04-05.  Part of the reason for the proposed timing is that we must demonstrate compliance to campus requirements by May 2005.

The cost of this project will be substantial, and it involves the addition of 1 or 2 FTE and ~$200k in additional networking hardware. This translates to roughly $20/system/month needed to provide limited baseline service for all windows EECS systems supported by CNIL.

A key component of the new system is virus control, which is now a campus requirement. Presently, 6-8% of all incoming EECS emails are virus-laden. Outlook users are more vulnerable to viruses, and compromised systems require a complete rebuild. Within EECS we have the campus site-licensed TrendMicro VirusWall service that applies to @eecs and @cs addresses. Virus definitions are updated hourly. This service removes viruses at the server level and adds headers to all affected emails. More information can be found at: https://iris.eecs.berkeley.edu/15-faq/03-security/20-email_viruses.html#filter.

At the present time we are considering these additional Virus protection measures:

•	Make it impossible to run executables from inside email.
•	Run local anti-virus detection, and update it frequently.
•	Reject certain type of dangerous attachments (“.exe”, “.scr”, etc.)

Spam Management

We have been working on evaluating various options to deal with this problem. Effective options will cost money, but there are also things we can do that cost next to nothing and will improve the situation.

EECS currently has public domain (free) Spam-Assassin. The SPAM patterns (used to recognize SPAM) are not updated frequently. This system successfully tags 15 -18% of all incoming EECS emails. The true percentage of incoming email being spam is unknown, but preliminary numbers indicate that it easily exceeds 55%. We published how-to documents to help users set up client based filters to file those tagged email to folders, but Client based filters do not work everywhere.

We also encourage users to adopt bayesian-based browsers to “learn” about personal customizations. The key point, however, is that we don’t have server based filtering capabilities yet, and Spammers are always one step ahead.

Fortunately, there are some easy steps that will provide some level of defense.

•	Posting your email address invites spam. Removing your previously posted email address reduces spam – see: http://www.cdt.org/speech/spam/030319spamreport.shtml
•	Using a low cost internet service, we harvested some 3500+ email addresses out of www.eecs and www.cs.

Department staff has taken steps to protect email addresses from our web pages. Users should also invest the effort to remove as any open email references as possible, including the ones in instructional web sites. CNIL will deploy tools to “crawl” our web servers routinely and alert our users. Research has shown that:

•	Spammers refresh lists frequently, so removing email postings reduces spam.
•	Reducing the number of instances of email appearances will reduce spam.

This will be more effective for staff than for faculty, since faculty has many email postings outside EECS (conferences, publications, etc.) More details on how to protect email addresses are on:
 http://istpub.berkeley.edu:4201/bcc/Winter2003/feat.spamharvest.html

Another SPAM vulnerability stems from our use of large mailing lists. These lists have been historically open.  We changed to only allow senders with @eecs or @cs addresses. This will help, but it will not be entirely effective due to hijacked systems and fake sender addresses. At the present time we have this Proposal for Mailing list Management: 

•	Keep student mailing lists as they are (managed via CalMail.)
•	For faculty lists (15+), allow direct postings from a pre-defined list of addresses, and moderated by staff.

For the next Step in Spam Management we are focusing on adopting a commercial Spam Blocker. We screened 10 products, and focused on evaluating 3 of them. These commercial systems offer Updates on hourly basis, properly tagging emails for filtering. The Goal is to increase the percentage of proper identification of all incoming “spam”. The preliminary test results are encouraging:

•	Current tagging (by free Spam Assassin) is 14-18% of all incoming EECS email.
•	With external ($20-$30k acquisition cost) spam appliance, the % increases to 48-56%.
•	The above number includes all false positives (estimated about 6%), but not virus-laden email.
•	We estimate an increase of approximately $2/user/month for additional license fees.
		
At this time we have two proposals for further SPAM management

•	For IMAP users, establish global filters to file all emails tagged into 3 pre-determined user mail folders on the IMAP server. (ex. “Spam-high”, “spam-med”, “spam-low” based on rating).

•	Global filters do not apply to non-IMAP users (but tagging does).
•	Users should be aware of false-positives.  
•	Users will need to manage/delete the contents of those 3 folders.
•	Not much flexibility (personalization) can be offered in the near term.

•	Some users would like to employ a “challenge-response” system. We are considering pursuing this for a limited set of users as a “beta” project.

Data Management Usage and Protection (DMPU)

Campus, as required by UCOP, is proposing a “Data Management, Usage, and Protection” policy (DMUP).  
This policy is detailed in: http://dataintegration.vcbf.berkeley.edu/. The information that we have to date is preliminary, but the policy is expected to be approved by e-Berkeley steering committee by May/June, 2004. An Executive summary will be sent to all deans and chairs soon. The following are the key characteristics of DMUP:

DMUP assigns system owner responsibilities, and the users must comply by identifying the following roles:
		
•	Proprietor (department chairs, directors, MSO, PI, etc.) has verall responsibility of compliance (including legal, budgetary, policy, etc.).
•	Custodian (technical or administrative staff, etc.) ensures all technical levels of the day-to-day management meet requirements.
•	Integrator (custodians, external contractors, etc.) ensures proper levels of protections are instituted.
•	Users (day-to-day users) should be adequately informed and trained to ensure proper use of data and resources.

DMUP also categorizes data and the respective systems they reside on. Several following categories apply and carry various levels of needed security. This is in compliance with federal or CA state level laws (FERPA, HIPPA, sb-1386, DMCA, etc.) Also UCOP IS-3 requires data (and systems hosting the data) to be classified as:
•	Mission critical, medium, non-critical.
•	Restricted, non-restricted.

DMUP also has the following enforcement provisions:

•	Proprietors of systems with “mission-critical” or “restricted” data must submit security plans.  An “Office of Records” will be set up to verify and audit.
•	A minimal security requirement has been established for systems with “restricted” data.
•	Another security requirement has been established for ALL systems on the UCB network.
•	Compliance is expected within 12-months of announcement of the DMUP policy.
•	Date of “official” announcement is May 2004.  
•	Non-compliance will result in system being removed from UCB network.

CNIL is studying the requirements. We are working with the campus to determine appropriate actions and lines of responsibility. We will have more information for the general user at the beginning of the fall semester.

Collaborator Accounts

At present we have two different types of users: Regular Members pay $60/month (to grow to $70/month for FY 2005) and Alumni/Emeritus pay $10 a month (to grow to $12/month for FY 2005). There are some finer distinctions that do not result in a different fee structure. For example, Alumni get email forwarding, while Emeriti get full email support, and they can only be established at the request of the department.

Some of our users have active research collaborators with people outside EECS. These collaborators often require limited access to our network for a period of time. As a result, we are introducing a new user category called a Research Collaborator. The cost of this service will be $25 a month in FY 2005. The rules that apply are the following:

•	A research collaborator needs faculty sponsorship, 
•	A research collaborator must be renewed every six months,
•	This person must NOT have a physical desk within EECS,
•	The main computing “home” of this user is elsewhere, so this account will not have an eecs email alias.

We expect that the introduction of this new category will be cost-neutral to CNIL, with a few present Regular Members dropping to Research Collaborator status, while some additional members will join in the new account structure. Ultimately, we estimate having 40-60 research collaborators at any given time.

 Instructional Labs

The following instructional labs are presently under the purview of CNIL

EE20N	EE43	EE192	
EE117	EE100	EE143	
CS150	EECS145L/M	EE105	
CS152	EE1	EE141	
EE40	EE125	EE199	
EE42	EE128	Student Machine Shop	

During the 2002-03 academic year we served 2449 students. We typically offer about 10,000 Student Course Hours per year, and last year we provided this level of student service with 7325 staff hours. We presently have the following Current and Pending Development Projects:

Project	Status	Owner	
1. EE100 student test board development	In progress, special dept. allocation	Prof. Chua	
2. EE100/1 mote experiment development	In progress, special dept. allocation	Prof. White	
3. EE105 development	On hold	Prof. Howe	
4. CS152 hardware and software support	In progress	Prof. Patterson/Kubi	
5. NSC lab infrastructure ( Cory 125 multimedia infrastructure)	On hold for 2 years	Prof. Fearing	
6. Lecture demos for 40, 117, 129 etc	On hold	various	
7. EE145L/M development	On hold for 3 years	Prof. Derenzo	
8. Callinx II board development/deployment	In progress, finish Sp ‘04	Prof. Katz	
9. EE20N hardware lab addition	On hold	Prof. Sastry	
10a. Vodafone lab EE142	On hold	Prof. Niknejad	
10b. Vodafone lab EE224a, 224b, 225a, 209	On hold	Prof. Sahai/Ramchandran	
11. EE130/231 organic electronics	On hold	Prof. Subramanian	

Note that some key Instructional Lab Goals for 2004-05, requiring ~1200 hours of new lab development are on hold pending 1 new FTE. These are:

 3. EE105 development	400 hours	
 5. NSC lab infrastructure (two way AV, finish Cory 125 multimedia infrastructure)	400 hours	
 7. EE145L/M development	400 hours	

The historical trends in HW lab support are quite interesting, and easily highlight how our instructional labs have been limited by constantly reducing resources. The following graph list the available staff hours (including part time student support):

5.7 FTE 
+ 3850 p/t lab
0.3 FTE AV

4.67 FTE
 + 2400 p/t lab
1.0 FTE AV

3.6 FTE 
+ 640p/t lab
1.0 FTE AV

4.0 FTE 
+ 700 p/t lab
1.0 FTE AV

In summary, Student Credit Hours have increased from ~6000 in 97-98 to ~9800 in 02-03, while available staff hours have decreased from 10600 in 97-98 to 7300 in 02-03. The number Instructional FTE has dropped from 5.7 to 3.6. Part time student help has dropped from 3850 to 640 hours.

A special note is made regarding the Distributed Computing budget, which is currently being managed by Kevin Mullally, for instructional labs in Soda, Cory, Davis, Hearst Field Annex, etc. For fy04-05, EECS will be withdrawing its contribution of 50% ($58K) of Kevin’s salary. This will now come out of the funds that Kevin receives each year directly from campus as opposed to COE or EECS. The annual sum is about $500K, but $256K is already being used for salaries in Kevin’s group, so the net reduction of his discretionary S&E funds will be about 24% (from $244K down to $186K). On top of that, we expect another 5-8% ($25K to $40K) cut in next year’s campus budget and this will most likely be applied to his S&E part, further reducing it down to $146K - $161K, or a net reduction of up to 40%.