CSAIL IT Policy

The purpose of this page is to catenate CSAIL specific computing policies on http://tig.csail.mit.edu into one location. These policies apply to all users utilizing CSAIL computing infrastructure, including students, faculty and staff, and any others granted the use of CSAIL computing resources.

This document is not a guideline for IT acceptable use. The MIT IT accpetable use policy is covered by MIT IS&T here: https://ist.mit.edu/about/it-policies

Accounts

CSAIL Kerberos Account Password requirements

In accordance with NIST SP800-63B version 4, we require:

• Minimum password length: 15
• Password must not contain username (or vice versa)
• Password must not be on a list of known trivial or compromised passwords

Existing accounts created before this policy was adopted in 2024 may have weaker passwords, but in the absence of compromise we do not force them to be changed. (Passwords older than July, 2019, were expired after a compromise.)

Not every user interface for changing passwords is currently able to check the database of compromised passwords.

CSAIL Kerberos Account Expiration

CSAIL accounts for certain classes of users—students, visitors, affiliates, guests, alumni, and certain temporary employees—automatically expire at the end of every fiscal year (specifically, at midnight UTC on July 1, which is 8 PM on June 30 local time here in Cambridge).

Users who have changed PIs should notify help@csail.mit.edu of the name of the new PI and the name of the new research group so that their account can be updated. Notifications to PIs and supervisors are sent out annually at the beginning of June (usually the first business day). Users whose accounts are not renewed receive a notification email on or around July 1. Users’ accounts must be renewed or reactivated by their PI, supervisor, or CSAIL Human Resources. TIG CANNOT RENEW USER ACCOUNTS. Users may send individual reminders to their PI or supervisor to renew or reactivate their account, which can be done at inquir.csail.mit.edu/users/INSERT CAPITALIZED USERNAME (Some users have unusual expiration dates set by their supervisors and will not receive any notifications.)

Operating system and software security

All servers on the CSAIL network must run up-to-date and supported operating systems. Each version of CSAIL Ubuntu is supported by Canonical for 5 years after its release, with support concluding at the end of April. All users and research groups are expected to maintain their servers on a regular basis, and to keep them upgraded to a supported and secure operating system version. This also applies to software running on servers within the CSAIL network, which must also be kept on a vendor-supported version.

If a system is running an unsupported operating system version, or if the software isn’t upgraded and causes a potential security issue, it may be removed from the network without warning for the security of the lab.

Network

CSAIL host registration policy

All devices on the CSAIL network must use registered IP addresses. An IP address is considered registered if there is a host name associated with it (PTR record) in the appropriate reverse mapping zone of the DNS. Hosts using unregistered IP addresses may be removed from the network without warning or recourse. IP addresses on most CSAIL networks are assigned solely by WebDNS; DNS entries which TIG believes to be erroneous are liable to be removed at any time.

Note: Hosts using dynamic addresses do not need to be registered individually, provided that the dynamic pool has been registered. Addresses in a dynamic pool are not registered for specific machines, but for the DHCP server on that network; pool addresses may not be reassigned to individuals without the permission of the system administrators. If your host has a dynamic address and you wish to switch to a static address, you will have to change IP addresses.

MITnet Rules of Use summarizes the rules that apply to all users of MITnet. We expect you to follow all these rules, and we hope you will encourage others to follow them as well.

MITnet Rules of Use

MITnet Rules of Use

Log Retention

Storage

All CSAIL users are responsible for properly classifying and storing their data according to its sensitivity level. See Data Security at CSAIL for guidance on Low, Medium, and High Risk data classification and approved storage locations for each level.

Backup Policy

TIG-managed AFS and NFS storage space¹ is backed up according to the following schedule:

Backup Schedule

Full backups

• Taken upon creation and population
• Mirrored tape writes
• One copy stored offsite for one year

Monthly backups

• Taken monthly
• Mirrored tape writes
• One copy stored offsite for one year

Daily backups (incremental)

• Taken daily
• Archived for one month

Backup Granularity and Recovery

The monthly backup is the only level of granularity guaranteed over time. For recovery requests:

• Less than two weeks old: Single-day resolution usually available
• 30-40+ days old: Monthly-level resolution only

We archive backup tapes as long as possible, but cannot guarantee physical tape integrity beyond one year or the availability of drives to read legacy media.

Snapshots

AFS storage is snapshotted nightly. A copy-on-write snapshot of each volume is available; only the AFS home directory has the snapshot mounted by default (as ~/.snapshot).

If you need the snapshot feature enabled for your AFS project directory or AFS group directory, email help@csail.mit.edu.

Three-Level Backup System

This backup approach with mirrored full backups provides several benefits:

• Conserves tape storage (full data written once; monthlies are ~20% of full size)
• Protects against single tape loss (mirrored monthlies mean no data loss from one failure)
• Enables recovery from lost full backups using previous monthly and full tapes
• Maintains two copies of each monthly backup

Email