Home > Computing policies > Responsibilities for Chairs, Managers and PIs under the Minimum Security Standards for Networked Devices
Home > Computing policies > Responsibilities for Chairs, Managers and PIs under the Minimum Security Standards for Networked Devices
All chairs, managers, and PIs have responsibilities in the area of computing security. Those responsibilities include:
See the "How we can help" section at the bottom of this article for assistance meeting these requirements.
The most significant issue facing computing support operations today is computer security. Five years ago, security incidents on desktop machines were relatively rare, and usually affected only a single user; now, more time is spent dealing with security incidents than any other single aspect of desktop support, and incidents routinely affect whole networks on campus. A more aggressive approach from Microsoft toward finding and fixing security holes has not served to significantly reduce the problem; it has become clear that we must revise our policies and practices to better protect our computers and our data.
In response to the growing crisis, in January 2004 the campus approved an innovative new policy: Minimum Security Standards for Networked Devices (effective as of May 1, 2005). The adoption of this policy represents a significant philosophical change; for the first time, network users will be required to meet certain conditions to have access to the network. In some cases, compliance with the standards might be tested before a device is allowed to connect; in others, a computer may be removed from the network for violating the standards, even if the machine does not pose an immediate threat to other network users. These unprecedented measures highlight the need to more actively manage our networks.
The requirements are not merely technical; department chairs and managers, principal investigators, and other administrative heads have significant new responsibilities due to the minimum standards and several other related policies. I hope this document will help clarify those responsibilities, and provide some help with meeting them.
The Departmental Security Contact Policy requires departments to define an email address for SNS to use when contacting the department about security issues. This can be a single person's address, or a mailing list. I recommend that departments create a mailing list, and have at least two people on that list to cover absences. Some departments, particularly in the lab sciences, may need to have a large number of people on the security mailing list.
Calmail account holders can create simple mailing lists on the lists.berkeley.edu page.
When SNS detects a computer with a security problem, they will send a mail to the security contact address of the department which owns the IP address of the problematic machine. The department must be able to locate the owner of the machine and respond to SNS within approximately 24 hours, or SNS will have no alternative but to block the machine off the network. Even after a machine has been blocked, it can still cause problems for other machines in the department, so it is in the department's interest to locate the machine and the owner. The campus IT Security Policy contains the following language:
Administrative Officials (individuals with administrative responsibility for campus organizational units [e.g., control unit heads, deans, department chairs, principal investigators, directors, or managers] or individuals having functional ownership of data) must identify the electronic information resources within areas under their control
In plain English, this means that anyone who controls computers must keep track of them. The responsibility may be passed down the line; for example, a department may know that a machine is in a particular faculty member's lab, but not exactly where the machine is, but the faculty member, or someone in the lab, must be able to locate the specific machine, and in some cases, the person using it.
This issue is partly technical and partly administrative. In a sense, the campus is simply requiring that IP addresses be considered a piece of departmental inventory that must be tracked.
It is worth noting that this requirement extends to network equipment installed by the department; if your department installs a router or wireless access point (which must comply with the policy on User-Installed Network Equipment), you must be able to track down which machines are using that network connection. This requires you to register machines before they connect, and maintain connection logs, so that you can find the specific machine which is causing a security problem.
Every operating system has security problems; once a vendor stops providing security patches for a particular OS release, it is only a matter of time before a permanent vulnerability is found in that OS. (For example, there are known problems in Windows 95 which cannot be fixed.) For the protection of all network users, the machines under your control must be updated to an OS which still has vendor support (or community support, such as the Fedora project for RedHat Linux). If the computer is too old to run a modern OS, it must be removed from the network.
This requirement may impose a significant burden on some departments, particularly in regards to "tertiary" machines such as those used by temporary faculty, GSIs or GSRs. Departments which cannot afford to upgrade their machines are being asked to make a difficult decision; they may need to decide that they cannot provide as many networked computers as they do currently. Fundamentally, these policies exist to protect the entirety of the network; the cost of putting a computer on the network must include the cost of protecting that computer from attack, as a compromised computer can compromise the entire network.
At this time, Windows 95, Windows 98, Windows ME, Windows NT, and Mac OS 9 are unsupported by their vendors. Machines running those operating systems must be upgraded to their modern equivalents, or the machine must be removed from the network or replaced.
The Data Management, Use, and Protection (DMUP) policy requires that computers store "restricted data" only if absolutely necessary, and that departments which must store such data must take inventory and report it, and take steps to protect it. That policy defines "restricted data" as "Data to which use is restricted by federal or state law or University or campus policy". This includes Social Security number, bank or credit card information, driver's license numbers, health records, and student grades. (See the College's Recommendation for Protection of Computerized Personal Information for details).
You may have heard about a security incident in 2004 at the Institute of Industrial Relations (IIR), in which a visiting researcher had a database which included 600,000 social security numbers on her machine, which were stolen by an attacker. Her institution is going to be required to contact all 600,000 people; Berkeley will probably be sued to cover some portion of the cost. It turns out that IIR didn't know the database contained social security numbers, and that the researcher was not even using the numbers; they just happened to have been provided by the state with the data set the researcher was working with.
This is just one example of how restricted data can represent a significant liability to your department; I expect that many L&S departments have some exposure to this liability. It is important to survey your faculty and administrative staff to ensure that you know if they have restricted data on their machines, and to encourage them to remove if it is not completely necessary, and protect it if it is.
The College and LSCR can help your department deal with many of these new requirements. The things we can do include:
