TABLE OF CONTENTS NETWORK SECURITY

 

I.      REFERENCES & RELATED POLICIES ............................................................................................. 2

A.   Federal & State Regulations ........................................................................................................... 2

B.   University of California Policies and UC San Diego Campus Regulations Applying to Campus

Activities, Organizations, and Students .......................................................................................... 2

C.  Business and Finance Bulletin IS-3: Electronic Information Security ............................................ 2

D.  University of California Electronic Communications Policy........................................................... 2

E.   Policy and Procedure Manual (PPM)............................................................................................. 2

F.   Personnel Policies for Staff Members ............................................................................................ 2

 

II.   PURPOSE ............................................................................................................................................. 2

 

III.  AUTHORITY .......................................................................................................................................... 3

 

IV.  DEFINITIONS ........................................................................................................................................ 3

 

VI.  PROCEDURES ..................................................................................................................................... 4

A.   Sponsorship .................................................................................................................................. 4

B.   User Agreement ............................................................................................................................ 4

C.  Network Infrastructure.................................................................................................................. 4

D.  Network Connectivity .................................................................................................................... 5

E.   Service Provision .......................................................................................................................... 5

F.   Monitoring, Scanning and Blocking...............................................................................................  6

G.  Remote Access .............................................................................................................................  6

H.  Miscellaneous ...............................................................................................................................  7

I.    Violations.......................................................................................................................................  7

J.   Contacts ........................................................................................................................................  7

 

EXHIBIT A NETWORK SERVICE PORT BLOCKING................................................................................ 8

 

EXHIBIT B UCSD MINIMUM NETWORK CONNECTION STANDARDS ................................................  9

 

APPENDIX A – DEFINITIONS .................................................................................................................. 18

 

APPENDIX B – EXCEPTIONS ..................................................................................................................   20

 

APPENDIX C – RISKY FILE TYPES..........................................................................................................   21

 

APPENDIX D – RESOURCES ........................................................................................................23

 

NETWORK SECURITY

 

I.              REFERENCES & RELATED POLICIES

 

A.         Federal & State Regulations

 

California Public Records Act (1976)

California State Assembly Bill (AB) 1298 (2007)

California State Assembly Bill (AB) 1950 (2004)

California State Senate Bill (SB) 1386 (2003)

Confidentiality of Medical Information Act

Electronic Communication and Privacy Act of 1986

Federal Family Educational Rights and Privacy Act of 1974 (FERPA)

Federal Privacy Act of 1974

Federal Information Security Management Act of 2002 (FISMA)

Health Insurance Portability and Accountability Act of 1996 (HIPAA)

Health Information and Technology for Economic and Clinical Health (HITECH) Act (2009)

State of California Penal Code, Section 502, Chapter 858, relating to Computer Crime

 

B.         University of California Policies and UC San Diego Campus Regulations Applying to Campus Activities, Organizations, and Students

 

C.         Business and Finance Bulletin IS-3: Electronic Information Security

 

D.         University of California Electronic Communications Policy

 

E.         Policy and Procedure Manual (PPM)

 

160-2	Disclosure of Information from Student Records
460-5	Reporting and Investigating Improper Governmental Activities, Misuse of University Resources, Fraud, and Other Financial Irregularities
480-1A	Information Within Word Processors, Personal Computers
480-1B	Personal Computer Backup
480-3	Responsibilities and Guidelines for Handling Records Containing Information about Individuals
510-1	Use of University Properties

 

Other PPM references include those dealing with academic, student, and staff discipline, and use of University equipment for personal financial gain.

 

F.         Personnel Policies for Staff Members

 

62	Corrective Action – Professional and Support Staff (Systemwide)
62 HR-S-1	Corrective Action – Professional and Support Staff (UCSD)

 

II.         PURPOSE

 

This document sets forth a security policy for the UCSD data communications network that will preserve network integrity and protect the information assets of network users.

 

Other University policies also apply to the operation of the campus network. Relevant policies are mentioned under References above.

 

III.        AUTHORITY

 

Jurisdiction of this policy is under the auspices of Administrative Computing and Telecommunications (ACT). Questions concerning this policy should be referred to computingpolicies@ucsd.edu.

 

IV.        DEFINITIONS

 

A user is any individual who makes use of the network.

 

A username is a network user's personal identifier.  Depending on the computer system this identifier may be variously known as the Active Directory username, network user name, Business Systems username, Kerberos principal, or account name.

 

A sponsor is an organization or individual who provides verification of a user's need for network services and their affiliation to the campus.

 

The UCSD Backbone network consists of routers, switches, and cabling that make up the node-to-node campus network backbone, not including building distribution equipment.

 

The UCSD Production network is all data networking at UCSD that permits data to flow over building distribution networks, the UCSD backbone, or a connection to an outside network.

 

The UCSD Data Communications Network encompasses both the Production network and all other data networks that may exist at UCSD. (e.g. experimental and research networks)

 

Networking equipment is equipment that provides routing, repeating or switching functions on a wired or wireless network, including routers, switches, wireless access points, hubs, and computers that provide any of these services for a network segment.

 

Data equipment is equipment capable of generating binary data on a wired or wireless network, including, but not limited to, desktop computers, servers, IP phones, printers, PDAs, netbooks, tablets, smart phones, laptops, and IP-based FAX machines.

 

A server room is a room where six or more ports are dedicated to servers providing file storage, email, Web and/or other computing services. Ports in server rooms are typically provided by a switch that is owned and managed by the department and has been approved by ACT in advance of purchase.

 

Core network services are services such as Active Directory, radius, VPN, DHCP and DNS that facilitate network use by attached data and networking equipment, and that are offered beyond the local switched segment.

 

Restricted network services are those from which an authorized user may make modifications to data, initiate connections to other networks, or which have data with sensitive or secure content.

 

Unrestricted network services are those that provide read-only access to publicly available network services.

 

V.         POLICY

 

Information is a principal asset of UCSD and must be protected from unauthorized modification, destruction or disclosure, whether accidental or intentional. The UCSD Data Communications

 

Network must therefore be kept secure, as it is essential to the transmission of information. The level of protection on the Network must be high enough to ensure that the most sensitive information traversing it is protected while still allowing free access to public information.

 

The security of the UCSD Data Communications Network, as a shared resource, is the responsibility of all network participants. Primary responsibility for the security of the production network rests with the IT Infrastructure group of Administrative Computing and Telecommunications (ACT). All other managers of a segment of the network (including managers of networks not directly connected to the UCSD Production network) are also responsible for maintaining the security of their segment.

 

VI.        PROCEDURES

 

A.         Sponsorship

 

A network user will have at least one sponsor.  All campus users of the network will have an organization to act as a sponsor; in most cases this will be the individual's home department. Students are sponsored by their college. UCSD sponsors limited guest wireless access to the network, which may be revoked or limited for violations of Minimum Network Connection Standards (Exhibit B). Non-UCSD users of restricted services must find a sponsor within UCSD. Authorization to use services on a network device is granted by the operator of the service who may also be a sponsor. Sponsors have the responsibility of ensuring sponsored users meet all applicable policies, including Minimum Network Connection Standards.

 

B.         User Agreement

 

All users of restricted network services are bound by the University of California Electronic Communications Policy. Key provisions include:

 

The user agrees to behave in an ethical manner and will be responsible for his or her own actions. Under California State Law any person who maliciously accesses, alters,

deletes, damages or destroys any computer system, network, computer program or data is guilty of a felony.

 

The user understands that the network is a shared resource and will not intentionally take actions that will interfere with the operation, integrity or security of the network.

 

The user will not provide access to third parties without the approval of a sponsoring organization.

 

The user understands that network traffic and files may be subject to search under court order. In addition, system administrators may monitor network traffic or access user files as required to protect the integrity of the computer network.

 

The user understands that access to the network may be temporarily suspended during maintenance and that UCSD will not be liable for damages due to a failure of some network service or due to a breach of security.

 

The user should understand that misuse of networking resources may result in the loss of privileges. Additionally, misuse can be prosecuted under applicable statutes. The user may be held accountable for his/her conduct under any applicable University or campus policies, procedures, or collective bargaining agreements. Complaints alleging misuse of network resources will be directed to those responsible for taking appropriate disciplinary action.

 

C.         Network Infrastructure

 

Any wired or wireless networking equipment connected to the UCSD Backbone network must be approved and/or operated by ACT/IT Infrastructure.

 

Network services and networking equipment connected to the UCSD Production network must be approved by ACT/IT Infrastructure; the process of obtaining approval should begin before purchase of said equipment. Such equipment and services must conform to current NGN standards and will be operated by ACT/IT Infrastructure except where special approval is granted, as in the case of server room switches (see IV Definitions, server room). All such equipment must provide routing and access control technology to enable separation of connected segments for security and bandwidth control purposes that meet current campus standards at the time of installation. Installation of networking equipment to avoid the expense of additional wall jacks is not likely to be approved, nor is any network equipment to support end user connections.

 

Note that ACT/IT Infrastructure provides network firewalls for most UCSD departments or units. Under special circumstances when centrally-provided services are unable to meet these needs, department-installed network firewall devices may be approved under the following rules:

 

·         Each such device must be pre-approved and properly registered with ACT/IT Infrastructure, including the name of a technical contact for the device,

 

·         ACT/IT Infrastructure will be kept informed of current traffic-filtering rules in place on each such device,

 

·         firewall devices must not be used to obscure downstream hosts (i.e. no NAT),

 

·         department-installed firewalls will *not* be managed or maintained by ACT/IT Infrastructure.

 

All networking equipment must be registered with ACT/IT Infrastructure, meet all applicable Minimum Network Connection Standards (see Exhibit B), permit login access by ACT Data Communications network personnel and be located in areas inaccessible by the general public, secured behind locked doors, or monitored by staff.

 

D.         Network Connectivity

 

Anyone wishing to attach a new piece of data equipment to the UCSD Production network will contact ACT/IT Infrastructure prior to doing so and follow the appropriate ACT/IT Infrastructure registration procedures.  Any attempt to change connectivity by the introduction of new protocols or new physical or logical links will be subject to review by ACT/IT Infrastructure.

 

Any piece of data equipment attached to the UCSD Production network is bound by this policy and its owner is subject to the policies listed in Section I, References and Related Policies. (See Exhibit B, “UCSD Minimum Network Connection Standards”.)

 

Departments should, wherever possible and with ACT assistance, logically divide their networks between administrative, research, instruction, or business activities. In addition, those networks should be further subdivided by security profile, such as external-facing servers, internal-facing servers, and clients. This allows for the best combination of performance and security.

 

E.         Service Provision

 

Providers of network services (e.g. file/print, VPN, proxy, Web services) will do so in a manner that is consistent with good facility management; network security is a function of the network participants. The Minimum Network Connection Standards (Exhibit B) pertaining to the specific classification of server must be followed. Providers of restricted network services will ensure that all applicable policies and guidelines (e.g. Business and Finance Bulletin IS-3) for access security are followed.

 

Services shall not interfere with other services on the network.

 

Services offering access to non-public University resources (network bandwidth, restricted-access materials, etc) will authenticate users in accordance with the terms of use of the resource.

 

Organizations will designate a Technical Contact (a person or group of people) to be used in the event of questions or concerns about a device. It is the organization’s responsibility to keep its contact data current with ACT/IT Infrastructure.

 

F.         Monitoring, Scanning and Blocking

 

ACT/IT Infrastructure monitors traffic on the network for the purpose of maintaining proper network function. By extension, traffic generated by users of computer systems on the network is also monitored. In addition, ACT/IT Infrastructure uses automated tools to proactively scan network-attached devices for vulnerabilities that, if left unaddressed, could allow those devices to be compromised and further damage the network.

 

ACT/IT Infrastructure practices proactive blocking. Network devices that are identified as being vulnerable to or having suffered a security breach will be removed from the network at the discretion of ACT/IT Infrastructure until the problem is resolved. Actions taken for the purposes of circumventing such a removal are not acceptable. Devices may be blocked even when this will impact devices served by the device in question; security of the campus network is paramount.

 

Network services having vulnerabilities that are known to pose a significant threat to campus network security may be blocked on the network at the discretion of ACT/IT Infrastructure. Solutions will be available to allow access to blocked services by authorized remote users. Exceptions to service blocks for individual machines may be granted where circumstances dictate. (See Exhibit A, “Network Service Port Blocking”)

 

Any device or equipment that interferes with the campus wired or wireless network, including, but not limited to, devices creating radio interference and unauthorized wireless access points, will be removed from the network at the discretion of ACT/IT Infrastructure unless ACT/IT Infrastructure has consented in advance to such interference. ACT will attempt to notify the person/group responsible but if they are unable to make contact quickly, the violating device may be removed without notice.

 

G.         Remote Access

 

In order to preserve the safety and integrity of the UCSD Data Communications Network, UCSD authorized users are required to use encrypted connections when connecting remotely to campus to access, transmit, view or modify any sensitive data. The UCSD Virtual Private Network (VPN) service, administered and managed by ACT/IT Infrastructure, is the recommended encrypted solution; in some circumstances, other

protocols such as https and ssh may be sufficient. Users are advised that use of the VPN for all remote connections is strongly recommended. System or service administrators should use VPN in conjunction with standard encrypted connection protocols such as ssh when administering services using higher-level (e.g. "root") access.

 

In special cases, divisions with higher-security needs may request ACT approval to administer local VPN services. Such approval is contingent upon the technical inability of central services to support requirements of federal, state or local legislation or the terms of a specific research contract.

 

Machines remotely connected to the UCSD network to conduct University business are expected to conform to the Minimum Network Connection Standards (Exhibit B).

 

H.         Miscellaneous

 

Information regarding major security vulnerabilities and fixes for them is available from ACT. Users should contact their Systems Administrator and/or the manager of their local network for security information and local policy.

 

I.          Violations

 

University policy prohibits the use of University property for illegal purposes and for purposes not in support of the mission of the University.  In addition to any possible legal sanctions, violators of this policy may be subject to disciplinary action including but not limited to suspension or dismissal as relevant, pursuant to University policies and collective bargaining agreements.

 

J.         Contacts

 

Questions concerning this policy should be referred to  computingpolicies@ucsd.edu.

 

Specific questions about security issues should be directed to security@ucsd.edu.

 

Questions about network connectivity or function should be addressed to hostmaster@ucsd.edu.

 

EXHIBIT A

 

NETWORK SERVICE PORT BLOCKING

 

PURPOSE:

 

The purpose of this addendum is to formalize and document the processes by which service ports are "blocked" (access disallowed) at the campus border.

 

AUTHORITY:

 

See the Network Security Policy

 

RATIONALE:

 

The vast number of computers installed on UCSD's network has made the task of securing individual computers extremely difficult. The increasing sophistication and automation of network scans, coupled with the increasing complexity and deployment of application software on desktop machines, make a totally host-based approach to network security impractical. A network-based firewall can at least reduce campus security exposure by blocking potentially dangerous traffic from even entering the UCSD network.  Blocking commonly-attacked ports on the border router is no panacea, but can be a good first line of defense.

 

PROCEDURE:

 

Pursuant to the task of ensuring network security, ACT/IT Infrastructure may enact blocks of network service ports at the campus border.

 

As blocks of this type affect all machines within the campus boundary, service port blocks will not be established unless a significant threat to the security of UCSD devices or data is perceived, either from reports of hostile action elsewhere on the Internet, or resulting from analysis of campus network traffic.

 

Such blocks will be discussed in advance when possible, and announced immediately upon sysadmin-l@ucsd.edu mailing list, as well as on the UCSD Information Security and SysWiki web sites.

 

Solutions will be available to allow access to blocked services by authorized remote users. Exceptions to service blocks for individual machines may be granted where circumstances dictate.

 

References:

 

UCSD Information Security homepage:

http://security.ucsd.edu

 

List of currently blocked ports:

http://syswiki.ucsd.edu/index.php/Border_filtering

 

UCSD Network Security Policy:

http://adminrecords.ucsd.edu/ppm/docs/135-3.HTML

 

EXHIBIT B

 

UCSD MINIMUM NETWORK CONNECTION STANDARDS

 

1.         IMPLEMENTATION

 

As of January 1, 2010, all standards are in effect. We have retained effective dates for historical purposes.

 

2.         MINIMUM STANDARDS

 

To connect a device to the campus data communications network, you must comply with the following standards and directives.

 

2.1        Register All Devices

 

Register all devices with Administrative Computing and Telecommunications/IT Infrastructure via the UCSD Hostmaster (see Appendix D for information). ResNet machines must be registered with ResNet instead. Review registration information periodically and update it as needed. The registration should indicate which standard applies to the device.

 

2.1.1     Additional Health Sciences Host Registration (Effective January 1, 2008)

 

In addition to registration with ACT, register specified Health Sciences devices with Medical Center Information Services. Do not install Life Sustaining Medical Equipment that is dependent upon network connectivity. If installed on the network, Life Sustaining Medical Equipment must comply with either section seven or eight. All servers must have a current Risk Assessment on file with UCSD MC Information Services. Update this information annually. All devices must be running a currently-supported operating system.

 

2.2        Patch and Update Software (Effective January 1, 2005)

 

Campus networked devices must run software for which security patches are made available in a timely fashion. Review available patches no later than three days from availability; apply as appropriate. If a patch is not applied, or cannot be applied for a specific reason, you must apply for an exception with ACT/IT Infrastructure and comply with all required mitigation.

 

2.3        Protect Against Malicious Software (Effective January 1, 2005)

 

Malicious software detection and prevention tools appropriate for the platform, such as anti-virus

software, rootkit detectors, and system integrity monitoring software, must be running and kept up to date. Where machines are University-owned, the responsibility for ensuring protective software is updated ultimately rests with the department or laboratory. The responsibility for these tools on personally-owned devices rests with the individual owner

 

2.4        Limit Services (Effective January 1, 2005)

 

Do not run any service that is not necessary for the intended purpose or operation of the device.

 

2.5        Configure Host-based Firewall Software (Effective January 1, 2005)

 

Run and configure host-based firewall software to allow communication only from necessary clients and only to required services. The presence of an external access control mechanism does not obviate the need for host-based firewalls. Depending on how the device or data on it is used, UCSD Network or Data Security groups may require you to install additional protection.

 

Note that ACT/IT Infrastructure provides network-based firewalls to departments and units. Groups should contact ACT/IT Infrastructure for information on how to apply that layer of security. Existence of network firewalls does not obviate the need for host-based firewalls.

 

2.6        Use Complex Passwords (Effective January 1, 2005)

 

Campus electronic communications service providers must have a suitable process for authorizing any use of shared restricted electronic communications services under their control. The mechanism for providing access to service users will be referred to here as an "account".

 

All campus electronic communications service user accounts must have either passwords or another secure authentication system (e.g. biometrics, Smart Cards).

 

Where possible, devices must be configured to enforce at least the minimum password complexity requirements specified at the resource found in Appendix D.

 

Modify all default passwords for network-accessible device accounts, and ensure they are complex. Do not use the same passwords for privileged and non-privileged access. Organizations are strongly encouraged to use multi-factor authentication with appropriate credential controls for administrative access to systems.

 

2.6.1     Additional Health Sciences Password Standards (Effective January 1, 2008)

 

Passwords for administratively privileged accounts must be at least 14 characters long, unless long passwords are not supported.

 

2.7        Do Not Allow Unencrypted Authentication (Effective January 1, 2008)

 

All campus devices must use only encrypted authentication mechanisms. In particular, historically insecure services such as login via HTTP, Telnet, FTP, SNMP, POP, and IMAP should be replaced by their encrypted equivalents. In cases where protocols are used without authentication (e.g. HTTP for general Web pages, anonymous FTP), use of legacy protocols is permitted.

 

2.8        Do Not Run Unauthenticated Email Relays (Effective January 1, 2005)

 

Campus devices must not provide an active SMTP service that allows unauthorized third parties to relay email messages, i.e., to process an e-mail message where neither the sender nor the recipient is a local user. IP-based authentication is not adequate to meet this requirement. Open email relays will be removed from the network as soon as they are detected and without warning.

 

2.9        Do Not Allow Uncontrolled Access to Proxy Services (Effective January 1, 2005)

 

Proxy services are not allowed on the campus network unless they have been approved by ACT/IT Infrastructure and unless their configuration and use have been reviewed and deemed appropriate by that group.

 

In particular, software program default settings in which proxy servers are automatically enabled must be identified by the system administrator and re-configured to prevent uncontrolled access to proxy services.

 

Open proxy services will be removed from the network as soon as they are detected and without warning.

 

2.10      Enable Logging (Effective January 1, 2008)

 

Log all authentication successes and failures on all devices. Retain logs for at least the default retention period for the operating system in use.

 

2.11      Employ Physical Security (Effective January 1, 2008)

 

Where possible and appropriate, configure devices to "lock" and require a user to re-authenticate if left unattended for more than 20 minutes.  Efforts must be taken to protect computer hardware and removable media from theft.

 

2.12      Protect Embedded Data (Effective January 1, 2008)

 

When a device is decommissioned or serviced, clean/destroy any internal hard drives according to the applicable standard. If disk drives are used in these devices for temporary storage, encrypt data where possible. Delete data after it is no longer needed.

 

3.         STANDARDS FOR SHARED PUBLICLY ACCESSIBLE COMPUTERS

 

These guidelines cover any publicly accessible machine that is shared by many different people who may not know or trust each other. Workstations shared by a group working together are not considered “publicly accessible” for the purposes of this policy. All devices in this category must meet the Minimum Standards outlined above as well as the standards that follow.

 

3.1        Prevent Accidental Disclosure of Sensitive Information (Effective January 1, 2008)

 

In order to prevent the accidental disclosure of sensitive data or the misuse of credentials, devices must prevent persistent storage of files. Any private information must be cleared from the computer between uses. Web browser histories and caches must be cleared.

 

3.2        Preserve System Integrity (Effective January 1, 2008)

 

Verify and repair the integrity of the system on a regular basis. Do not permit changes to the hard disk that could result in unauthorized installation or modification of software on the computer. Limit access to system features to only those necessary to support the primary function of the computer.

 

3.3        Employ Physical Security (Effective January 1, 2010)

 

Physically secure system data cables (e.g. keyboard, network) and their connections to prevent the insertion of key-logging or other monitoring hardware by unauthorized persons.

 

4.         STANDARDS FOR PRINTERS, NETWORK SCANNERS, NETWORK FAXES, WEBCAMS AND OTHER NETWORK APPLIANCES

 

4.1        Restrict Network Access (Effective January 1, 2009)

 

Deploy all such devices in private IP space. Limit network access to authorized entities (using device- local or network firewall means).

 

4.2        Update Firmware (Effective January 1, 2008)

 

Apply firmware updates promptly when available.

 

4.3        Protect Embedded Data (Effective January 1, 2008)

 

When a device is decommissioned or serviced, clean/destroy any internal hard drives according to the applicable standard. If disk drives are used in these devices for temporary storage, encrypt data where possible. Delete data after it is no longer needed.

 

5.         STANDARDS FOR CLIENTS THAT PARTICIPATE IN SENSITIVE ACTIVITIES

 

These standards cover any desktop machine where one or more of the users participate in business or research activities that expose them to sensitive data. Health Sciences clinical workstations are considered “sensitive clients” for the purposes of this document. See Appendix A for definitions of data and activities that are considered sensitive.

 

5.1        General Requirements (Effective January 1, 2008)

 

·         All such devices must meet the Minimum Standards outlined above

 

·         If unauthorized access is reasonably believed to have occurred, the security incident process of the UCSD Computer Incident Response Team (CIRT) will be invoked.

 

5.2        System Configuration

 

5.2.1     Configure Host-based Firewall Software to Enforce Client Status (Effective January 1,

            2008)

 

Configure the host-based firewall to block all incoming connections by default. Incoming connections through the host-based firewall can be permitted when they support IT management and help desk activities, when they apply to specific administrative machines and specific services, and/or when they allow remote access through VPN or local network segment to primary users of the machine.

 

The host-based firewall must be a departmentally or centrally managed firewall product that logs to a departmental/central server. We recommend that intrusion prevention capabilities be part of the host-based firewall product.

 

5.2.2     Patch and Update Software (Effective January 1, 2008)

 

Apply security patches within two weeks of availability.

 

5.2.3     Protect Against Malicious Software (Effective January 1, 2008)

 

Anti-spyware software, if it is available for the platform, must be run. Available anti-virus and anti- spyware logs must be reviewed on at least a weekly basis. Where machines are University-owned, the responsibility for ensuring protective software is run and logs are reviewed ultimately rests with the department or laboratory. The responsibility for these actions on personally-owned devices rests with the individual owner. To prevent exposure to malicious software, scan e-mail file attachments for viruses and block risky file types (See Appendix C.)

 

Web filtering must be used to prevent exposure to sites that host malicious software.

 

5.2.4     Enable Logging (Effective January 1, 2008)

 

Enable verbose logging at the operating system level. Logs must be able to show user, type of event, date and time with time zone, success or failure, and origin of event, and must identify system component, affected data, or resource.

 

In order to allow for event correlation between different log sources, synchronize clocks using Network Time Protocol (NTP). Set the time source to ntp.ucsd.edu, an Active Directory domain controller, or another accurate time source.

 

To prevent tampering, push logs off machine at least weekly to a central log server and store them for at least two months.

 

5.2.5     Scan For Sensitive Data (Effective January 1, 2008)

 

Scan system for unencrypted sensitive data at least monthly. Where possible, remove sensitive data from the system. If it cannot be removed, sensitive data must be encrypted.

 

5.3        User Management

 

5.3.1     Use Secured Authentication (Effective January 1, 2009)

 

Authenticate to an infrastructure that supports account fraud detection, authentication logging, disaster

recovery and fault tolerance for system level authentication.

 

5.3.2     Restrict Administrative Account Use (Effective January 1, 2008)

 

User accounts must not be administrative users, and administrative access must only be used when required.

 

5.4        Vulnerability Management

 

5.4.1     Vulnerability Scanning (Effective January 1, 2008)

 

ACT/IT Infrastructure will scan devices on a regularly scheduled basis. Firewall rules must allow for comprehensive scanning from ACT/IT Infrastructure scanning machines. Systems must have no real critical vulnerabilities.

 

5.4.2     Blocking (Effective January 1, 2008)

 

In order to protect the sensitive data on these systems, a designated party will block devices from using the Internet or intranet on detection of critical vulnerabilities, unless prior arrangements have been made to mitigate any risk.

 

5.5        Additional Health Sciences Standards (Effective January 1, 2008)

 

Only secured email servers should be used to exchange sensitive data. Non-UCSD e-mail providers do not meet this standard unless approved by Medical Center Information Services.

 

6.         STANDARDS FOR SERVERS THAT PARTICIPATE IN SENSITIVE ACTIVITIES

 

These standards cover any servers that host applications or support clients that participate in sensitive activities. See Appendix A for definitions of data and activities that are considered sensitive.

 

6.1        General Requirements (Effective January 1, 2008)

 

·         All such devices must meet the Minimum Standards outlined above

 

·         If unauthorized access is reasonably believed to have occurred the security incident process of the UCSD Computer Incident Response Team (CIRT) will be invoked.

 

6.2        System Configuration

 

6.2.1     Configure Host-based Firewall (Effective January 1, 2008)

 

Configure host-based firewall software to allow communication only from necessary clients and only to required services. To support management, review, and logging, use a centrally managed and centrally logging firewall product. Firewall rules should be supplemented by network ACLs or network-level firewall rules.

 

6.2.2     Protect Against Malicious Software (Effective January 1, 2008)

 

Use host-based intrusion-prevention system (IPS) software that can log and prevent malicious activity. For machines that deal with large amounts of sensitive data or installations that consist of many systems dealing with sensitive data, network intrusion detection must also be used.

 

Protect the system with anti-spyware software if it is available for the platform.

 

6.2.3     Patch and Update Software (Effective January 1, 2008)

 

Apply security patches within a week of availability.

 

6.2.4     Enable Logging (Effective January 1, 2009)

 

Enable logging for the operating system, web server, and applications that may be running on the server. Logs must be able to show user, type of event, date and time with time zone, success or failure, and origin of event, and must identify system component, affected data, or resource. Review logs regularly, at least three times a week.

 

To prevent tampering, archive logs to a central log server or read-only media and restrict access to only those with a true business need. Monitor online archived logs with change detection software. Retain logs for at least three months.

 

In order to allow for event correlation between different log sources, synchronize clocks using Network Time Protocol (NTP). Set the time source to time.ucsd.edu, an Active Directory domain controller, or another accurate time source.

 

6.2.5     Limit Services (Effective January 1, 2009)

 

Use a single server to support only services related to a single purpose, rather than offering many generalized services, in order to limit the potential for compromise. For example, departmental e-mail can not be hosted on the same server as departmental personnel’s Web pages. Services must run with the least privilege necessary.

 

6.2.6     Scan for Sensitive Data (Effective January 1, 2009)

 

Scan system for unencrypted sensitive data at least monthly. Where possible, remove sensitive data from the system. If it cannot be removed, sensitive data must be encrypted or protected using another appropriate authorized mechanism.

 

6.2.7     Manage Users and Privileged Accounts (Effective January 1, 2008)

 

Change any privileged password when an employee who knows said password leaves. Make sure that you can associate activities performed with elevated privileges with an identifiable authentication event and specific individual.

 

6.3        VULNERABILITY MANAGEMENT

 

6.3.1     Vulnerability Scanning (Effective January 1, 2008)

 

ACT/IT Infrastructure will scan devices on a regularly scheduled basis. Firewall rules must allow for comprehensive scanning from ACT/IT Infrastructure’s scanning machines. Systems must have no real high-level vulnerabilities.

 

6.3.2     Blocking (Effective January 1, 2008)

 

In order to protect the sensitive data on these systems, a designated party will block devices from using the Internet or intranet on detection of critical vulnerabilities, unless prior arrangements have been made to mitigate any risk.

 

6.4        REQUIREMENTS FOR SPECIFIC SERVICES

 

6.4.1     Web Server

 

6.4.1.1   Protect Against Malicious Software (Effective January 1, 2009)

 

Test third-party and custom applications for common web security issues (see the OWASP top ten at http://www.owasp.org/) and repair. Monitor third-party applications and Web frameworks for patches and vulnerabilities. Patch any vulnerability within a week.

 

6.4.1.2   Preserve System Integrity (Effective January 1, 2009)

 

In order to detect compromise or defacement, use change detection software to monitor static Web content and Web server configuration for unauthorized changes.

 

6.4.1.3   Use Secured Authentication (Effective January 1, 2008)

 

Where technically possible, use campus Single Sign-On services to authenticate, selecting appropriate authentication mechanisms for the application.

 

6.4.1.4   Limit Access (Effective January 1, 2008)

 

Restrict Web service to the smallest audience possible, using both authentication and firewall rules.

 

6.4.2     File Server

 

6.4.2.1   Use Secured Authentication (Effective January 1, 2008)

 

Use non-trivial authentication to enforce user and access control to the network service and the files within. Restrict access to authorized clients and users.

 

6.4.2.2   Limit Access (Effective January 1, 2008)

 

Restrict file service to the smallest audience possible, using both authentication and firewall rules.

 

6.4.2.3   Protect Against Malicious Software (Effective January 1, 2008)

 

Scan all shared files for viruses on at least a weekly basis.

 

6.4.2.4   Encrypt Data Transfer (Effective January 1, 2008)

 

Employ transport-level encryption when transferring unencrypted sensitive data.

 

6.4.3     Mail Server

 

6.4.3.1   Protect Against Malicious Software (Effective January 1, 2008)

 

Employ technology such as spam filtering and blacklists to limit malicious e-mail delivery. Block risky file types (see Appendix C). Scan mail folders for viruses at least weekly to locate e-mail viruses that escaped the initial scan. Scan all e-mail file attachments for viruses.

 

6.4.3.2   Encrypt Mail Transport/Delivery (Effective January 1, 2009)

 

Employ transport-level encryption between mail clients and mail servers. Encrypt mail delivery whenever possible.

 

7.         STANDARDS FOR CLIENTS CONNECTED TO, OR PART OF, LIFE-SUSTAINING MEDICAL EQUIPMENT, TREATMENT DELIVERY SYSTEMS, SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA), AND HEAVY MACHINERY CONTROL SYSTEMS

 

Devices must meet the standards for “clients that participate in sensitive activities” outlined above as well as the standards below.

 

7.1        Enable Logging (Effective January 1, 2008)

 

Collect logs as outlined in section 5.2.4, but retain them for at least six months.

 

7.2        Scan for Vulnerabilities (Effective January 1, 2008)

 

Devices connected to the campus network or to the Internet must be scanned weekly using a credentialed Foundstone scan. Systems must have no real high-level vulnerabilities.

 

7.3.       Protect Against Malicious Software (Effective January 1, 2008)

 

To prevent the unauthorized installation of malicious software, Internet-connected clients must never run as a user with administrative capabilities.

 

7.4        Configure Host-based Firewall Software (Effective January 1, 2008)

 

Devices connected to the campus network or to the Internet must have host-based firewall rules that limit

the outgoing traffic to only established traffic, and limit administrative access to specified administrative machines. Configure devices to only establish connections with servers connected to or part of Life-Sustaining Medical Equipment, SCADA, and heavy machinery control systems through a bastion host.

 

Clients may talk directly to servers connected to or part of Life-Sustaining Medical Equipment, SCADA, and heavy machinery control systems if both systems are exclusively, and only ever, connected to a common private network.

 

7.4.1     Additional Health Sciences Standards (Effective January 1, 2008)

 

Devices must have a designated UCSD Health Sciences IS contact.

 

8.         STANDARDS FOR SERVERS CONNECTED TO, OR PART OF, LIFE-SUSTAINING MEDICAL EQUIPMENT, TREATMENT DELIVERY SYSTEMS, SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA), AND HEAVY MACHINERY CONTROL SYSTEMS

 

Devices must meet the “standards for servers that participate in sensitive activities” outlined above as well as the standards below.

 

8.1        Enable Logging (Effective January 1, 2008)

 

Collect logs as outlined in section 5.2.4, but retain them for at least six months.

 

8.2        Restrict Network Connectivity (Effective January 1, 2008)

 

Do not connect devices directly to the campus network or the Internet. Configure such devices so that they cannot directly communicate with any outside host. Necessary communication can be accomplished using a bastion host to exchange data.

 

If connected through a bastion host, ACT/IT Infrastructure will scan devices on a regularly scheduled basis using a credentialed vulnerability scan. Systems must have no real high-level vulnerabilities.

 

8.3        Configure Host-based Firewall Software (Effective January 1, 2008)

 

Limit outgoing traffic using the host-based firewall to only allow necessary communication with clients meeting the client specification that have no Internet connectivity, and/or with the bastion host.

 

8.3.1     Additional Health Sciences Standards (Effective January 1, 2008)

 

Devices must have a designated UCSD Health Sciences IS contact.

 

9.         STANDARDS FOR VIRTUAL MACHINE(VM) HOST SYSTEMS THAT SUPPORT IMAGES OF HOSTS THAT ARE CONNECTED TO, OR PART OF, LIFE-SUSTAINING MEDICAL EQUIPMENT, TREATMENT DELIVERY SYSTEMS, SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA), AND HEAVY MACHINERY CONTROL SYSTEMS

 

Host systems must meet the “standards for servers that participate in sensitive activities” outlined above. Guest systems must meet the minimum standards.

 

9.1        Preserve System Integrity (Effective January 1, 2008)

 

Verify and repair the integrity of the operating system, applications and VM software at least weekly using change detection software.

 

9.2        Limit Services (Effective January 1, 2008)

 

Do not offer any services on the host system other than VM management software. Limit access to VM management software to only authorized administrative machines or approved VPN infrastructure as necessary.

 

9.3        Restrict Network Communications (Effective January 1, 2008)

 

The VM virtual network interface and host operating system must enforce network security rules to limit inappropriate communication between virtual machines and/or the host.

 

                                                                             

 

APPENDIX A – DEFINITIONS

 

 

1.         SENSITIVE ACTIVITIES

 

For the purposes of this document, Sensitive Activities are defined as anything that involves the storage, entry, processing, transmission, or viewing of Sensitive Data.

 

2.         SENSITIVE DATA

 

Sensitive Data is any data that is regulated by law or limited by contractual agreements between the University and other business partners.

 

3.         CRITICAL VULNERABILITIES

 

A Critical Vulnerability is one where an exploit or proof-of-concept code is publicly available or being actively exploited.

 

4.         FAMILY EDUCATIONAL RIGHTS AND PRIVACY ACT (FERPA)

 

FERPA covers all student data. We may disclose without consent, "directory" information such as a student's name, address, telephone number, date and place of birth, honors and awards, and dates of attendance as long as we honor the students disclosure preferences from Tritonlink. If any data is present that has been flagged for non-disclosure or the disclosure option is not checked and enforced then the data is considered sensitive.

 

5.         GRAMM-LEACH-BLILEY ACT (GLBA ACT)

 

The GLB Act, officially known as The Financial Modernization Act of 1999 includes privacy provisions to protect consumer information held by financial institutions. Because of the student loan activity, the University is considered a financial institution under the GLB Act. Family Educational Rights and Privacy Act (FERPA) compliance places the University in compliance with FTC privacy rules under the GLB Act.

 

6.         CALIFORNIA PUBLIC RECORDS ACT CODE 6250-6270

 

The Act mandates public access to records held by the University. The Act also provides exclusions for access to certain types of records or data. Examples of data that are excluded include personal payroll/employee data such as state and federal tax withholding. The Act requires that we protect the privacy and integrity of this data and its use at the University.

 

7.         CALIFORNIA STATE SENATE BILL SB 1386

 

SB 1386 became operative in 2003. It “requires any agency, and any person or business conducting business in California, that owns or licenses computerized data that includes personal information to disclose any breach of the security of the system, following discovery or notification of the security breach, to any resident of California whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person.”

 

The bill defines “personal information” as follows:

 

An individual's first name or first initial and last name in combination with any one or more of the following data elements, when either the name or the data elements are not encrypted:

 

1.     Social security number.

 

2.   Driver's license number or California Identification Card number.

 

3.   Account number, credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account.

 

8.         HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA)

 

HIPAA is a federal law establishing national standards that provide for the privacy and security of an individual's health information. Information created or received by a health care provider or health plan that includes health information or health care payment information plus information that personally identifies the individual patient or plan member.

 

Personal identifiers include: a patient's name and email, web site and home addresses; identifying numbers (including Social Security, medical records, insurance numbers, biomedical devices, vehicle identifiers and license numbers); full facial photos and other biometric identifiers; and dates (such as birth date, dates of admission and discharge, death).

 

9.         PAYMENT CARD INDUSTRY (PCI) STANDARDS

 

The PCI standard is a contractual agreement between the University and our merchant bank. The agreement covers our handling of credit card numbers, magnetic stripe contents, CVC numbers, and expiration dates. In addition to the standards outlined above for sensitive systems, PCI requires additional security and has its own set of standards that must be met.

 

10.        CALIFORNIA STATE ASSEMBLY BILL (AB) 1950

 

Enacted in 2004, AB 1950 requires any business that is the data custodian of personal information about a California resident to “implement and maintain reasonable security procedures and practices” to protect the data. Personal information disclosed “pursuant to a contract with a nonaffiliated third party shall require by contract that the third party implement and maintain reasonable security procedures and practices appropriate to the nature of the information.”

 

11.        CALIFORNIA STATE ASSEMBLY BILL (AB) 1298

 

Enacted in 2007, AB 1298 expands the definition of “personal information” as defined in SB 1386 to include health information and medical record information.

 

12.        HEALTH INFORMATION TECHNOLOGY FOR ECONOMIC AND CLINICAL HEALTH (HITECH) ACT

 

HITECH is part of the American Recovery and Reinvestment Act of 2009. It includes provisions for breach notifications by entities covered by HIPAA that disclose unsecured protected health information (PHI).

The Act states that notifications “shall be made without unreasonable delay and in no case later than 60 calendar days after the discovery of a breach by the covered entity involved.”

 

HITECH requires covered entities to notify affected individuals, the Secretary of HHS, and in some cases the media. The Secretary must post on the HHS web site the names of covered entities for breaches that involve more than 500 individuals.

 

APPENDIX B – EXCEPTIONS

 

Departments, units, or individuals unable to comply with the UCSD Minimum Network Connection Standards but wishing to connect to the campus electronic communications network must identify resources that will assist them (on an ongoing basis) in becoming compliant. Devices that do not comply with the minimum standards are subject to exclusion from the campus network.

 

Departments, units, or individuals who believe their devices require configurations that do not comply with the UCSD Minimum Network Connection Standards may request connection to the campus electronic communications network on an exceptional basis. The exception process will involve other mitigation of the risks that the UCSD Minimum Network Connection Standards address. To request exception, fill out the form available at http://blink.ucsd.edu/technology/security/network/standards/.

 

Questions about the UCSD Minimum Network Connection Standards or the exception process may be addressed to: security@ucsd.edu.

 

 

APPENDIX C – RISKY FILE TYPES

 

File Extension	Description
.ani	Windows animated cursor file security vulnerability. Possible buffer overflow in Windows
.bat	Batch files are often malicious
.bmp	Windows bitmap file security vulnerability. Possible buffer overflow in Windows
.cab	Possible malicious Microsoft cabinet file
.cer	Dangerous Security Certificate (according to Microsoft Q883260)
.chm	Complied help files are very dangerous in email
.cmd	Batch files are often malicious
.cnf	Speed Dials are very dangerous in email
.com	Executable DOS/Windows Programs are dangerous in email
.cpl	Control panel items are often used to hide viruses
.cur	Windows cursor file security vulnerability. Possible buffer overflow in Windows
.exe	Executable DOS/Windows programs are dangerous in email
.hlp	Windows file security vulnerability. Possible buffer overflow in Windows
.hta	HTML archives are very dangerous in email
.ico	Windows icon file security vulnerability. Possible buffer overflow in Windows
.ins	Windows Internet Settings are dangerous in email
.its	Dangerous Internet Document Set (according to Microsoft Q883260)
.job	Task Scheduler requests are dangerous in email
.jse*	JScript Scripts are dangerous in email
.lnk	Eudora .lnk security hole attack
.mad	Microsoft Access Shortcuts are dangerous in email
.maf	Microsoft Access Shortcuts are dangerous in email
.mag	Microsoft Access Shortcuts are dangerous in email
.mam	Microsoft Access Shortcuts are dangerous in email
.maq	Microsoft Access Shortcuts are dangerous in email
.mar	Microsoft Access Shortcuts are dangerous in email
.mas	Microsoft Access Shortcuts are dangerous in email
.mat	Microsoft Access Shortcuts are dangerous in email
.mau	Dangerous attachment type (according to Microsoft Q883260)
.mav	Microsoft Access Shortcuts are dangerous in email
.maw	Microsoft Access Shortcuts are dangerous in email
.mda	Dangerous attachment type (according to Microsoft Q883260)
.mdz	Dangerous attachment type (according to Microsoft Q883260)
.mhtl	MHTML files can be used in an attack against Eudora
.pif	Shortcuts to MS-Dos programs are very dangerous in email
.prf	Dangerous Outlook Profile Settings (according to Microsoft Q883260)
.pst	Dangerous Office Data File (according to Microsoft Q883260)
.reg	Windows registry entries are very dangerous in email
.scf	Windows Explorer Commands are dangerous in email
.scr	Windows Screensavers are often used to hide viruses
.sct	Windows Script Components are dangerous in email
.shb	Shortcuts Into Documents are very dangerous in email
.shs	Shell Scrap Objects are very dangerous in email
.tmp	Dangerous Temporary File (according to Microsoft Q883260)
.vbe	Visual Basic Scripts are dangerous in email
.vbs	Visual Basic Scripts are dangerous in email
.vsmacros	Dangerous Visual Studio Macros (according to Microsoft Q883260)
.vss	Dangerous attachment type (according to Microsoft Q883260)
.vst	Dangerous attachment type (according to Microsoft Q883260)
.vsw	Dangerous attachment type (according to Microsoft Q883260)
.wmf	Windows Metafile security vulnerability
.ws	Dangerous Windows Script (according to Microsoft Q883260)
.wsc	Windows Script Host files are dangerous in email
.wsf	Windows Script Host files are dangerous in email
.wsh	Windows Script Host files are dangerous in email
.xnk	Microsoft Exchange Shortcuts are dangerous in email
.zip	Compressed and packaged files used to distribute many virus/trojans
.txt.exe	Attachments using multiple extensions
filename.{1CE8B2C9-EAEF-43fc-8218-F092E4F94A47}	Format of Windows Class Identifiers (CLSID) The CLSID will not usually be displayed to the user. Windows may run the program that is associated with the CLSID if the user attempts to open the file.