Home /

Procedures for Blocking Network Access

CONTENTS:

The following was originally approved at the March 12, 2002 meeting of the Provost's Advisory Council.
Updated February 2012.

I. BACKGROUND AND PURPOSE
Campus network and security personnel must take immediate action to address any threats that may pose a serious risk to campus information system resources. For example, compromised systems can put information and other systems at risk. Similarly, inappropriate behavior such as email spam or password guessing attempts directed at remote sites can result in blocked communications and damage to the campus' reputation. If the threat is deemed serious enough, the account(s) or device(s) presenting the threat will be blocked or disconnected from network access. For services hosted remotely, ITS will work with the service provider to address the threat.

The following specify how the decision to block is made and the procedures involved. It is important to note that external service providers may have and enforce different policies regarding blocking access or services.

II. AUTHORITY
Campus network and security personnel have the authority to evaluate the seriousness and immediacy of any threat to campus information system resources and to take action to mitigate that threat. Action that is taken will be responsible and prudent based on the risk associated with that threat and the potential negative impact to the campus mission caused by making the offending device(s) and/or account credentials (e.g. passwords) inaccessible. Examples of threats that will trigger blocking are:

  • The level of network activity is sufficiently large as to interfere with the normal business activity of the University;
  • Privileged access has been acquired by an unauthorized person;
  • An attack on another computer or network has been launched;
  • Confidential, private or proprietary electronic information or communications are being inappropriately collected;
  • Complaints have been received and verified regarding inappropriate activity or the system exhibits a high-risk vulnerability and no response has been received from the ITS Divisional Liaison (DL), Local IT Specialist (LITS), or identified ITS staff regarding the incident.

Other regulations or campus policies for which separate procedures exist may also result in blocking network access. These include:

III. PROCEDURES

a) Notification:

  • The Data Center Manager must be notified of problems in the Data Center.
  • The Computer Systems Integration Senior Manager must be notified of problems in Learning Technologies.
  • Instructions for identifying the appropriate DL and/or assignment group to contact are in SlugHub tech-only KB article #17170.

b) Devices:
The intent of campus network and security personnel who operate under these guidelines is to work cooperatively with departments in blocking network access. The practice is to notify DLs or identified ITS staff prior to blocking in order that they may address the problem in a timely and appropriate manner. However, there will be times when this is neither possible nor practical.

If the threat is immediate, or the impact is severe, as evaluated by campus network and security personnel, the offending device(s) will be blocked immediately and notification will be sent to the DL(s) or identified ITS staff via SlugHub ticket, email and/or phone, as appropriate regarding the threat.

If the threat is not immediate, or the impact is acceptable, notification of the threat will be sent to the DL(s) or identified ITS staff via SlugHub ticket, email and/or phone, as appropriate. If a response is not received within 2 days indicating that the department is taking action to mitigate the threat, the offending device(s) will then be blocked.

In either case, if a block has been put in place it will be removed when the DL/LITS/identified ITS staff/client and campus security personnel agree that the problem causing the incident has been addressed.

Recourse for blocked network access
If a department believes that a device has been inappropriately blocked it may request a review of the decision by the ITS Director of Core Technologies. If there is still a disagreement with the decision, it may be further reviewed by the Vice Chancellor, Information Technology, and if necessary, by the Executive Vice Chancellor and Provost.

c) Account Credentials:
Problems involving compromised account credentials that access more than one service, such as CruzID Blue or Gold, are to be reported to the Accounts Team in the ITS Support Center via SlugHub ticket, email (help@ucsc.edu), or phone (x9-HELP) to coordinate the following response.

ITS Service Providers will disable compromised account credentials as soon as possible once the compromise has been discovered. This includes account credentials known to have been phished and accounts exhibiting behavior indicating a high probability of being compromised. Where passwords are involved, disabling must include changing the compromised password or rendering it unusable, as well as disabling or locking out "I forgot"-type mechanisms.

When disabling or blocking account credentials, Service Providers will notify the ITS Support Center or other support organization who will notify the client via SlugHub ticket, email, phone, or in person to explain what actions have been taken and why, and what services may be affected. Disabling an account credential that accesses multiple services, such as CruzID Blue or Gold, can impact all services accessed with that credential.

The ITS Support Center or other support organization will also work with the credential holder to identify other services accessed with the compromised credential(s), assist with changing those passwords, and provide any relevant education to help the person avoid a similar problem in the future.

ITS Service Providers/Support Center: Refer to SlugHub tech-only KB articles #16640, 16724, and 17053 for additional procedures.

Recourse for disabled account credentials
If a user believes that his or her access has been inappropriately disabled, the user may request a review of the decision by the ITS Director of Client Services and Security. If there is still a disagreement with the decision, it may be further reviewed by the Vice Chancellor, Information Technology, and if necessary, by the Executive Vice Chancellor and Provost. It is important to note, however, that once a password has been changed it cannot be restored. Standard password reset procedures will need to be followed to resume access even if it is determined that the password was disabled inappropriately.

IV. REFERENCES