Last modified 11 years ago Last modified on 08/18/2008 03:27:27 PM

Common Security Policies

Each System within the LSST computing grid will have a specific set of policies associated with it according to what that system must support and what it needs to protect. This section describes common policies that may be referred to from the system-level security policies.

1. Responsibilities

Each site is expected to have one person, a cybersecurity officer, who is responsible for overall managing and monitoring security for the site. This person will be responsible for ensuring proper configuration of security policies at the local site, ensuring that machines and processes deployed to the site comply with policy, monitors results of security issues detection mechanisms, and serves as the final point of contact on security issues requiring action by a human. The Archive Site will host one person at the 0.5 FTE level to not only carry out these activities for the Archive Site but also coordinate security management across all LSST sites.

In addition to the local security personnel, each site will have some form of general operations staff. At the Archive and Base Sites, these will be in the form of site operators that provide 24-7 operations support. Smaller DAC sites may rely on local site staff (who are not necessarily LSST employees) to serve in this role. As part of their routine operations, they will monitoring the site's systems for failures and warnings. In particular, reports from security issue detection mechanisms will routed first to this staff. They will make the initial assessments of failures or other unusual events that might indicate a security problem. When a problem is suspected, they have the ability to shut down or restart processes and Systems according to a defined procedure (to be defined later) in accordance with Security policy. In such cases, the local security cybersecurity officer would be contacted.

In all cases, the procedures for reacting to possible security issues and the use of personnel to manage site security must be consistent with the policies and practices of the local institution. In particular, the security officer may be required to report to and coordinate with an overall institutional security officer. Security incidents will have to be filed through the local incident reporting process.

2. Physical Operating Environment

3. System Descriptions

3.1. Network Architecture

  • Each System should be on its on sub-network to allow router-level enforcement of System security policies
  • Connections into a System should be through designated machines and ports; router-based firewalls can enforce this policy.

3.1.1. Connecting to a Network

  • Before a machine can be connected to the sub-network of a System (other than the Visitor Network), it must be reviewed and validated as complying the System's Security policies.

4. Management, Operational and Technical Controls

4.1. Access Control

4.1.1. Internal User Access

This subsection describes how a user (as opposed to service) who is logged into a machine inside a particular LSST System may gain access to services or shells on other machines within that System. Intra-System Shell Access

Unless the System security policy mandates additional restrictions, shell-level access to a remote machine will be allowed only through a secure remote shell protocol that includes:

  • an encrypted connection
  • client and server host authentication
  • public/private key user authentication

(SSH and Kerberos are both acceptable technologies for this.)

Password-less authentication for accessing a remote shell is discouraged unless it is needed for effective use of an application (e.g. SVN); this application can only use password-less authentication within the confines of the System.

Rationale: Use of SSH/Kerberos within a system can slow the propagation of unauthorized access and protect against network sniffers.

4.1.2. Remote User Access

This subsection describes how a user (as opposed to services) who is logged into a machine located outside of a particular System may gain access to services or shells on machines within the System. Public & Science User Access

All access by the general public and general science user (those without administrative access) will limited to the Community Service System (CSS), generally via a web portal or rich client interface. Please refer to the specific CSS policies for details.

Rationale: By-definition, non-CSS Systems will not have any services that require direct access by public/science users. Their services can be provided to users by using the CSS as a proxy. Portal-based Access

A System or software component within a System may support a (web) portal interface. When it does, it must support authentication and authorization policies from one or more of the four categories:

  1. passive monitoring::
    • The user connects only for retrieving (read-only) data.
    • authenticate with a username and password
  1. active monitoring::
    • user can change logging levels in a manner that may affect other users
    • two-factor (2F)/one-time password (OTP) authentication required
  1. non-critical control::
    • non-critical generally refers to control over operations that are not dangerous to life or property
    • user can change state of component, launch other components, etc.
    • two-factor (2F)/one-time password (OTP) authentication required
    • portal or underlying application need to determine if user has authorization for action
  1. critical control::
    • critical generally refers to control over operations that are dangerous to life or property; mainly applies to OCS
    • user can change state of component, launch other components, etc. In the case of OCS, this may mean controling camera or observatory hardware.
    • requires authorization enabled by human on a per-session basis
    • two-factor (2F)/one-time password (OTP) authentication required after authorization is enabled Direct Remote Shell Access
  • remote shell access allowed with features required in plus:
    • support of 2F/OTP authentication (password-less not allowed)
  • remote shell access from outside a Site should be restricted to designated machines within a System (e.g. login servers); it should not be enabled by default. Rich Client Access

A rich client is an application that runs on the user's "local" machine that talks to a specialized server application on the remote machine. Examples might include 3rd party products (e.g. LabView) or custom products talking to our own services. Such a client may be used under one of the following conditions:

  1. it directly supports the LSST 2F/OTP authentication mechanism
  2. it is run via an encrypted remote desktop (e.g. VNC) where the client application is actually running on the remote system.

4.1.3. Service Authentication [TODO]

4.2. Data

4.2.1. LSST Science Data

One of the main objectives of the security plan is to ensure the integrity and availability of data for scientific users. In this section, we highlight the classes of data that are critical both for end-user science and for the internal generation of end-user data products. Our general security concerns for the data include:

  • Raw observational data must be protected against corruption and deletion as this cannot be regenerated.
  • While generated data products may be recomputed from the raw data, a massive loss of this data would have a major impact on data availability: not only would it take considerable time to regenerate products, the regeneration would take resources away from normal operations and the creation of the next generation of products.
  • We must ensure that the data that is delivered to users is intact and represents the intended scientific content of the project.
  • We must ensure that the data delivered to users does not inadvertently provide a vector for computer viruses, malware, and data that is not part of the LSST mission (advertisements, pornography, MP3 file, etc.).
  • End users will create new scientific datasets from LSST products that will form the basis of new publishable results; thus, these datasets (which may be stored on LSST servers) are sensitive. Even database queries they submit will carry scientific insight. A scientist must be guaranteed that this data are not accessible by other users apart from those they explicitly wish to share them with.

We note again that the scope of this document limits the protection of data from corruption and loss by unauthorized access. Corruption and loss due to, for example, hardware failure is an issue for our fault tolerance plan and is thus out of scope here. Nevertheless, mechanisms for detecting corruption, whatever the cause, will be important.

In protecting data, we need to not only consider how to protect access the storage, but also how to ensure integrity while data moves from one platform to another. We thus summarize the major channels of data flow through the LSST systems:

Diagram needs revising

  1. Observatory to Base Facility (raw observation data)
    1. to Base Facility buffer
    2. buffer to permanent archive
    3. permanent archive to computation pipelines
    4. pipelines to events (including VOEvent)
  2. Base Facility to Archive Center (raw observation data)
    1. to Archive Center buffer
    2. buffer to permanent archive
    3. permanent archive to computation pipelines
    4. pipelines to database
  3. Archive Center to DACs
    1. to permanent archive for distributed backup of raw data
    2. to database Processed Data Products intended for Public Release

Confidentiality - low. The difficulty lies in making meaningful queries and managing bandwidth, not in protecting confidentiality.

Integrity - moderate. We should protect integrity, but if it is compromised we can recompute from archived raw data.

Availability - moderate. Our goal is 98% availability. Temporary unavailability should be avoided but is not catastrophic. Archival Science Data
  • Applications that manage archival data must be written to allow only reading and adding to archived raw data, and not over-writing during normal operations
  • Deletion of archival data must:
    • only be possible with one-time-password authentication
    • be accompanied by warnings to the user
    • display progress and be interruptible

Confidentiality - low. Archival science data is publicly available; the difficulty lies in making meaningful queries against it and managing bandwidth, not in protecting its confidentiality.

Integrity - high. In order to be useful for science, the data's integrity must be trusted.

Availability - moderate. Our goal is 98% availability. Temporary unavailability should be avoided but is not catastrophic. Internal Science Data

Certain data is not intended for public release; for example:

  • "Rough draft" data whose quality has not been assessed
  • Raw data that has not yet been processed
  • What else?

Confidentiality - low. Leaking internal science data would only cause unreduced or low-quality data to be distributed publicly, prematurely, and would not harm LSST's operations. It might have a minor impact on LSST's reputation. If it happened routinely, it could cause irritation in the astronomy community.

Integrity - high. Most internal science data will eventually be processed, archived, and released.

Availability - moderate. Our goal is 98% availability. Temporary unavailability should be avoided but is not catastrophic.

4.2.2. Personal Data

LSST will provide personal storage space for researchers.

Confidentiality - moderate (high?). Researchers require confidentiality before publishing.

Integrity - moderate. We will attempt to preserve personal data. If it is lost, we assume that researchers can regenerate it, even though it may be time-consuming and inconvenient. Researchers should keep backup copies of critical algorithms and code.

Availability - moderate. Our goal is 98% availability. Temporary unavailability should be avoided but is not catastrophic.