Fermilab Computer Security & Strong Authentication Project Mark Kaletka Computing Division Operating Systems Support Department

Philosophy "Scientific thinking and invention flourish best where people are allowed to communicate as much as possible unhampered.” -- Enrico Fermi

Security Philosophy  Like an academic institution, we want to maintain an atmosphere which encourages free exchange of ideas;  Yet, we have an obligation to protect our data and systems;  We allow wide latitude within certain limits;

Security Policy “… Fermilab’s single mission is science and the laboratory’s stated policy is to maintain an open scientific environment where the free exchange of ideas is encouraged and protected. We want there to be unhindered freedom to use computers within a wide area, but this area is surrounded by extremely high walls. …”

Policies and Rules  All computer and network usage at the Laboratory is subject to the “Fermilab Policy on Computing”;  Includes “Policies and Rules to Protect Fermilab Computers” aka computer security policy;  Copies are available on the web at:

Rules for General Systems  Mandatory incident reporting;  Report all suspicious activity:  If urgent to FCC Helpdesk, x2345, 24x7;  Or to system manager (if immediately available);  Non-urgent to  Incidents investigated by Fermi Computer Incident Response Team (FCIRT);  Not to be discussed!

Rules for General Systems  “Blatant disregard” of computer security;  First time warning, repeat offense disciplinary action;  Unauthorized or malicious actions;  Damage of data, unauthorized use of accounts, denial of service, etc., are forbidden;  Ethical behavior;  Same standards as for non-computer activities;

Rules for General Systems  Restricted central services;  May only be provided by Computing Division;  Security & cracker tools;  Possession (& use) must be authorized;  System managers;  Must be registered with FCSC;  See:

Rules for General Systems  Backup Policy - Users  Users (data owners) responsible for determining:  What data requires protection;  How destroyed data would be recovered, if needed;  Coordinating backup plan w/ sysadmins;  or doing their own backups;

FCIRT  Investigate (“triage”) initial reports;  Coordinate investigation overall;  Work with local system managers;  Call in technical experts;  May take control of affected systems;  Maintain confidentiality;

Computer Security Organization

Strong Authentication "Techniques that permit entities to provide evidence that they know a particular secret without revealing the secret."

Goals of Strong Authentication  Primary -  Prevent network disclosure of passwords.  Secondary -  Provide a single-signon environment.  Integrate AFS accounts & systems.  Simplify account management, especially terminations - take this burden off the system administrators.  Enforce password policies.

Fermilab Strong Authentication Project  Based on MIT Kerberos v5 w/ enhancements:  integration w/ AFS  CryptoCard challenge/response one-time passwords  additional clients (sshv1)  features for unattended jobs

Kerberos Authenticated Access Strengthened RealmPortal Untrusted Realm On-Site Off-Site Kerberos KDC Trusted Realm KDC Kerberos

CryptoCard

Limited Production Phase  CDF & D0 Run II  Strengthen Run II systems & applications:  Analysis systems  Farms  Mass storage  Desktops – on- & off-site

Production Phase  “… the present plan calls for the whole Fermilab site to be in the strengthened realm by the end of 2001.”  Specific exceptions are allowed:  Non-authenticated read-only access;  Web or db form data entry;  Restricted physical access;  Access restricted via prior Kerberos authentication

Strong Authentication Issues for Farms  Secure distribution, installation, backup, restoration of host service principal keytabs;  Creation, distribution of (host-specific) user cron principals & keytabs;  Authenticating processes which don’t belong to an individual;  Ticket expiration, forwarding, & renewal;

Running Unattended Jobs  As root:  use that host’s keytab;  As an individual:  kcroninit creates a special principal, valid for that host, & gets & stashes a keytab;  kcron gets the tickets & runs the job;

Running Unattended Jobs  As a “group”:  “group” (& group admin) approved by the KDC admin;  group admin creates principals, valid for that host, for “job” & “group”, also extracts & stashes the keytab;  file permissions control members of “group”;  As a “group” on a farm:  as above, but valid for any host in farm;

References     mon-problems.txt mon-problems.txt

A Final Thought... “The quest for security is no picnic!” -- Linus van Pelt