Director's Blog
2009 June

I’ve been working for several years now on a new strategic plan for computing in L&S, and I’m pleased to announce that the first major change related to that plan is due to take effect July 1.

We got a ton of input from our current customers and others within L&S, through surveys, committee discussions, and in-person interviews.  One thing we heard loud and clear was, “I want my own person.”  L&S folks want to get to know a specific IT person in their department, who understands their computing needs, and who they can grab in an emergency.  They want someone who gives them advice and help managing their IT, not just someone who shows up to fix problems.  They don’t want to submit requests to a faceless help desk system, and they don’t want to have nickle and dime charges every time they ask for something new or different.  Departments want a partner, not a consultant.

LSCR’s current structure and funding model will need to adapt to the way that our customers’ needs have changed.  We are perfectly structured to meet the technology needs of 1995: 2009’s demands will force us to look at ourselves completely differently.

We will take the first step on July 1.  We are not yet prepared to change our financial model–we’ll be looking at that during the coming fiscal year–but we are ready to implement significant changes in the way we interact with our customers.  Here’s how it will work:

For each department we’re supporting, we’re going to create a support team.  That team will work a little like an account team from a vendor; you’ll have one person who’ll be your lead partner, your first contact for any IT request.  In many cases, that person will be physically located in your department or your building (especially if you’re able to provide space for him or her), and he or she will handle requests from both staff and faculty.  Your partner will be backed up by technical experts in all the areas you need tech support; we’ll identify a Mac lead, PC lead, and web, database, or Unix leads depending on the department’s needs.  The goal will be to have one single person handling the bulk of requests in your department, while giving that person the ability to call upon the wide range of skills and experience that LSCR has, in order to solve customer problems.

We will set up a single departmental mailing list, such as “english@LSCR.berkeley.edu,” which will be your primary way of requesting support of any type.  Everyone on your account team will receive your department’s emails, and jobs will be tracked in a queue specific to your department.

I think this plan will provide better communication, clearer responsibilities, and stronger relationships between LSCR and the folks we support.

This reorganization is not related to the budget difficulties we are all facing; we are implementing this functional change without changing our financial model.  That means that for the 09-10 fiscal year, you can expect little to no change in your LSCR recharges compared with 08-09.  Like all departments, LSCR is likely to be affected by budget cuts and salary reductions or mandatory furloughs; the exact impact is not yet known.  We will keep our customers informed when we have any useful information.

We will soon be contacting each department individually to introduce the account team and provide more specifics about how the new scheme will work.

Web site security got some press last month when it was revealed that hackers had broken into a system at the Tang Center and stolen thousands of Social Security numbers.  The mechanism for that break-in was a “SQL injection attack“; without getting too geeky, SQL injection is an all-too-common vulnerability, caused when your application doesn’t check the input it’s receiving from the user.  If the application doesn’t check the input, it’s often possible to trick the system into doing something it’s not supposed to do.

The important thing to note is that the machine which had the SQL injection vulnerability was not the same as the machine which held the social security numbers.  The hackers broke into a low-security system, and used that as a platform to find and attack a high-security system.  The trust relationship between the systems allowed the hackers to escalate their privileges on the insecure system and get at some very high-value data.

It turns out that there is a ton of code with similar vulnerabilities out there on web pages, including on the departmental sites we host on the college web server.   It is almost guaranteed that PHP code written by someone who doesn’t understand the security implications will be vulnerable to this kind of attack.  Our web server has been under almost constant attack for the past two months, and at least three different departmental sites have been compromised.  Once the site is compromised, the hackers attempt to escalate their privileges (looking for confidential data), and try to use our server to support spamming, phishing, and other nefarious activities. All of these things are more likely to work when the activity is coming from a berkeley.edu (trusted) machine than when it’s coming from an ultranet.ru (suspicious) machine.

We’re doing what we can to reduce the ability for these hackers to escalate their privileges through our servers, but we have little control over the quality of the code on departmental web sites.  Our server hosts web sites for dozens of departments (75 unique domains at last count), and once a department is set up on our server, it can write and upload whatever code it wants.  The people running web sites for departments range from serious geeks to relative novices, so some of them are just fine in terms of security, while others are wide open.

If we see that you have vulnerable code that is being attacked or exploited, we’ll contact you and ask you to fix it.  Many departments who have vulnerable code don’t have anyone on staff who knows how to fix it–the fix is usually not very difficult, but it does require understanding of the issues.  If you don’t know how to deal with the issue, our web team can also fix security problems, charging on an hourly basis.