LSST Data Management
Cybersecurity Draft Plan
July 30, 2009
Bill Baker, NCSA
Kirk Borne, GMU
Tom Handley, IPAC
Jeff Kantor, LSST
Jim Hughes, NOAO
Ron Lambert, NOAO
Lee Le Clair, Ephibian
Heather Larrieu, SLAC
Ray Plante, NCSA
Introduction ................................................................................................................................................................3
LSST’s Overall Goals ...........................................................................................................................................3
Fault Tolerance ....................................................................................................................................................3
Design Principles .................................................................................................................................................4
Strategies ................................................................................................................................................................4
Costs..........................................................................................................................................................................6
Scope of this Document ....................................................................................................................................7
Organization: Sites and Subsystems............................................................................................................7
Partners and Sponsoring Institutions .........................................................................................................9
To Be Defined During Construction Phase ............................................................................................ 10
1
Common Policies ......................................................................................................................................... 10
1.0
1.1
1.2
1.3
1.4
1.5
2
DM Subsystems ............................................................................................................................................ 19
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3
Observatory Control Subsystem ................................................................................................ 20
Archive Operations Subsystem ................................................................................................... 22
Distributed Processing Subsystem ............................................................................................ 25
Community Service Subsystem................................................................................................... 26
Visitor Network ................................................................................................................................. 27
Event Messaging Component ...................................................................................................... 29
Operation Center .............................................................................................................................. 33
Sites ................................................................................................................................................................... 33
3.1
3.2
3.3
3.4
4
Definition of Terms .......................................................................................................................... 11
Responsibilities ................................................................................................................................. 11
Subsystems.......................................................................................................................................... 13
Science Data ........................................................................................................................................ 13
Physical Operating Environment ............................................................................................... 16
Management, Operational, and Technical Controls ........................................................... 16
Summit and Base Site (JK - Ron Lambert review for accuracy) .................................... 33
Archive Site ......................................................................................................................................... 37
Standalone Data Access Centers ................................................................................................. 38
Headquarters and Education and Public Outreach Center ............................................. 39
Threats............................................................................................................................................................. 40
Introduction........................................................................................................................................................ 40
4.1
Vulnerabilities .................................................................................................................................... 41
4.2
Control Analysis ................................................................................................................................ 42
4.3
Likelihood Determination ............................................................................................................. 43
4.4
Impact Analysis ................................................................................................................................. 44
Draft
LSST Security Plan
Page 3 of 49
Introduction
This document presents policies and architecture to address cybersecurity across LSST Data
Management facilities.
LSST has significant cybersecurity demands. It will be a highly visible, premier scientific
endeavor with both open data and real-time processing demands; it will attract attention
from friends and troublemakers alike. At the same time, its staff and user base will be large
and diffuse; they will need secure and convenient access to its infrastructure and services.
LSST’s Overall Goals
LSST has two apparently conflicting goals:


Openness – generous access to data by scientists and the public, in particular within
regions and nations that sponsor LSST, and in some cases world-wide
Security – long-term data integrity and dependable infrastructure
LSST’s cybersecurity priorities are to protect data, infrastructure, and software processes.
1. Protect data against corruption and loss due to unauthorized access
a. Data in transit between sites, such as from Chile to the Archive Center
b. Archive data, both raw and processed
c. User-generated data in scientists’ personal LSST scratch space
2. Protect data processing systems—both software and hardware—that are integral to
LSST’s science goals
a.
b.
c.
d.
Prevent unauthorized access to infrastructure
Secure communication among automatic software processes
Provide secure administrative access for staff
Provide appropriate security mechanisms for external users, including
scientists and the general public, balancing ease of use and security
e. Prevent and detect misuse of LSST resources (hijacking, malware)
3. Detect and remedy actual and attempted violations
a. Constitute a cybersecurity team that is ready to handle incidents.
b. Maintain monitoring systems on the computing infrastructure, network and
gateways.
Fault Tolerance
LSST’s goal of dependability hinges on both security and fault-tolerance, the latter of which
is articulated in the LSST DMS Fault Tolerance Architecture document. When a fault is
detected, the responsibilities will be:

Fault Tolerance:
o
Recover from the fault and continue operations, regardless of the origin of
the fault (hardware failure, security breach, etc.)
Page 4 of 49

LSST Security Plan
Draft
Cybersecurity:
o
o
o
Investigate whether the fault is due to a security failure
Correct the security failure and consider preventative measures
Follow up with an incident response and investigation if appropriate
A security breach will not necessarily cause a fault directly. However, correcting it may
require engaging fault tolerance measures; for example, if a server is compromised, a
failover may need to be engaged while the breach is remedied.
Design Principles
The cybersecurity architecture is implemented as an integral part of the overall system
design. Cybersecurity considerations enter into the decision process at the architectural,
physical, and logical levels. These considerations are:



Architectural: the architecture of the system considers cybersecurity and data
integrity issues as a fundamental tenet of the design process.
For example, end user access outside of observatory staff is only permitted via the
Data Access Centers.
Physical: the entire LSST System is protected by access filtering at the gateway(s);
only selected systems are permitted full access. Critical systems are further
protected by isolating them from any direct access by any outside user, system or
network.
For example, Alert and Data Release Production servers at Archive Center are
isolated from end user accessible servers.
Logical: only selected interface protocols on selected servers are open for outside
access, and secure user authentication is used as broadly as possible.
For example, public-facing EPO servers are firewalled for all traffic except necessary
protocols such as HTTP and FTP.
Strategies
LSST will follow two main cybersecurity strategies:

Network perimeters around major subsystems
o
o
o
o

Minimal open ports and protocols
Gateways for all external Internet traffic and some inter-subsystem traffic
Configuration standards (approved software) for hosts within network
perimeters
Convenient “Visitor Network” for non-approved hosts
Appropriate authentication of users and software processes
o
o
o
Two-factor authentication for administrative access
Revocable cryptographic keys for software processes
Adjustable authentication and authorization for external users (scientists,
public)
Draft
LSST Security Plan
Page 5 of 49
Network Perimeters around Major Subsystems
LSST will set clear boundaries around the various pieces of its infrastructure, and control
access at these perimeters. In the diagram below, the green boxes, representing “Systems”
and “Subsystems”, mark the main security perimeters.
Exposure to the public Internet is limited to:



Community Service Subsystems (CSS) present LSST’s public face. These are the only
systems that permit direct end user interaction.
Visitor Networks (VN) provide Internet access for staff and visitors at each site and
are not trusted by the rest of LSST’s infrastructure.
Trusted, locked-down gateway machines in each of the internal Systems.
LSST Sites and Systems. Systems and Subsystems (green) are primary security perimeter.
Multiple Systems are housed together at Sites (brown outer boxes). Needed: simplified version
of this diagram, but include reference to more detailed version in Infrastructure Design.
Authentication of Users and Software Processes
Access to all internal systems will only be allowed through designated gateway machines,
and will generally require:

Host-based certificates (for automatic software processes) that are subject to both
revocation and expiration
Page 6 of 49
o
o

LSST Security Plan
Draft
Encryption is required for control channels, preferably using the host-based
certificates that are used to authenticate the connection
Data channels across Subsystem boundaries must be checked for integrity, if
it is not feasible to encrypt them
Administrators will use two-factor authentication, such as one-time-password
(OTP) hardware tokens, for administrative access to internal systems.
Configuration Standards for Internal Networks
Only approved configurations will be allowed to connect to internal networks. In particular,
the DM Technical Control Team, in conjunction with the cybersecurity team, will approve
operating systems, software configurations, and kernel revisions for hosts that operate
within subsystems’ network perimeters.
For convenience, a separate “Visitor Network” will be created at each site. It will be more
permissive than the internal networks, but it will be topologically external to LSST, subject
to the same cybersecurity precautions as the public Internet.
Costs
Costs to implement this cybersecurity plan are discussed below qualitatively. Quantitative
costs are included in the LSST DMS MREFC and Operations cost estimates.
Infrastructure
Cybersecurity requirements that are likely to affect LSST infrastructure costs:



Two-factor authentication system
o Authentication Server. Modest processing requirements. May be shared with
a partner organization such as NOAO or NCSA.
o Tokens for LSST system administration staff. Current costs are around $100
per hardware token, which is typically a keychain dongle or small calculator
form factor. Options will continue to proliferate over the next few years,
potentially driving the price down and improving convenience.
o Note that end users will not require two-factor authentication; only LSST
system administrators will need them. Username/passphrases is expected
to be sufficient for end users.
Network partitioning
o Commercial routers are capable, in their standard configurations, of
implementing LSST’s network partitioning plans, at no additional cost. For
example, we expect that Firewalls, VLANs, and even some packet inspection
will be built into the router configuration, without the need for separate
hardware.
Monitoring
o Traffic analysis and intrusion detection will require separate physical
hardware or virtual machines at each Site or Subsystem and at the Control
Center. The individual site monitoring mechanisms are embedded in a
software WBS element in the DM cost estimates. See monitoring and logging,
section 1.5.3.
Draft
LSST Security Plan
Page 7 of 49
Management
Cybersecurity management costs include:




Testing and verifying that cybersecurity requirements are met
Helping users with authentication and access difficulties
Administering hardware tokens and host certificates
Debugging and maintaining network configurations
Refer to the Responsibilities section (1.1) below for a more detailed description of
cybersecurity personnel roles and responsibilities, and to the LSST Operations Plan for
staffing levels.
Software Development
LSST software development will be impacted by cybersecurity requirements, mainly by
authentication requirements when communicating across Subsystem boundaries. Some of
the open-source software that LSST intends to leverage already sufficiently supports
certificate-based security, but we will have to do additional work for integration and when
developing custom software. This effort is included in LSST software development cost
estimates.
Scope of this Document
This document addresses LSST’s cybersecurity plan at an abstract level. It does not specify
implementation details, except as examples to demonstrate feasibility.
Even so, we believe that LSST’s cybersecurity requirements can be met at reasonable cost
by current technologies and products, including network routers and firewalls, intrusion
detection, and authentication. In particular, current commercial firewalls and routers are
capable of meeting LSST’s traffic requirements.
Organization: Sites and Subsystems
This document is mostly organized by DM Subystem. LSST infrastructure is made up of selfcontained subsystems, each in their own logical network partitions, which are installed
together at physical Sites, as portrayed in the following diagram. The network partitions,
with carefully controlled interfaces, delineate cybersecurity and organizational boundaries.
Page 8 of 49
LSST Security Plan
Draft
LSST Sites and Subsystems. Sites (brown outer boxes) house combinations of Subsystems
(green). Cybersecurity policy is defined mainly at the level of Subsystems. Need to update
diagram to use WBS terms (subsystem, component, etc).
Legend:






Brown: Hardware & other Infrastructure
Green: Systems
Blue Text: Software components, data
Blue Lines: Software control
Black Lines: Bulk data transport
Red: Event channel communication
Definitions:


Site: Physical space in a building managed by an institution that hosts LSST DM
Subsystems.
DM Subsystem: A defined combination of configured hardware, a software stack, a
set of running processes, and the people that manage them.
DM Subsystems

Observatory Control Subsystem (OCS): controls the camera, telescope and
observatory hardware, and data acquisition.
Draft




LSST Security Plan
Page 9 of 49
Archive Operations Subsystem (AOS): manages on-going operations of a site,
including long-term storage, the main archive storage cache, data access services,
and the brain of operations, data management control (DMC).
Data Processing Subsystem (DPS): used to run pipelines
Community Services Subsystem (CSS): hosts services and associated storage that
are accessed by outside users.
Visitor Network (VN): a relatively open network that allows easy network access to
the Internet.
LSST Sites
Sites each host a combination of DM Subsystems. For example:



Base Site = OCS + DPS + AOS + CSS + VN
Archive Site = DPS + AOS + CSS + VN
Stand-alone DAC Site = AOS + CSS + VN
Partners and Sponsoring Institutions
LSST shares infrastructure and operations with many scientific and academic institutions,
and is sponsored by a broad base of governmental and private supporters. These partners
and sponsors have their own cybersecurity requirements and arrangements that affect
LSST.
Funding Agencies’ Cybersecurity Requirements
NSF – The National Science Foundation is still formulating its cybersecurity requirements
for projects that it funds. NSF-appointed Concept Design Reviewers asked that LSST include
a cybersecurity plan in the upcoming Preliminary Design Review (PDR). LSST will be
working with other NSF-funded institutions, such as NCSA (see below) that have their own
cybersecurity policies and practices, which both LSST and NSF can look to for examples.
DOE – The Department of Energy generally has extremely strict security requirements for
its projects. Since these security requirements are intended to deal with extremely sensitive
national security information, such as nuclear weapons programs, we do not expect to be
required to follow DOE’s security standards during operation; we will focus, instead, on
NSF's requirements and on our own inherent cybersecurity priorities. This plan sets the
base level for all LSST sites, if certain sites are subject by location to more stringent DOE
requirements, those requirements will be applied at those sites specifically.
Private sponsors – We are not aware of separate cybersecurity requirements from private
sponsors, other than the need to protect researchers’ proprietary data if it is derived from,
created, or stored on LSST community access resources from LSST data.
Participating Institutions
These institutions have helped to develop the LSST cybersecurity plan

NCSA (National Center for Supercomputer Applications, Illinois)
o
o
Experience operating large open-access computational science facilities.
Will operate the LSST Archive Center.
Page 10 of 49
o

o
o
Will host LSST’s South American infrastructure—telescope, base station, and
Chilean Data Access Center—and provide facilities management, including
physical security.
Experience with open-access astronomy with Sloan Digital Sky Survey and
numerous proprietary astronomy projects.
Operates flight and ground missions such as the Spitzer Space Telescope and
the Palomar Transit Factory, whose infrastructure and goals have close
parallels to LSST.
Contributing to LSST software development.
Ephibian
o

Contributing to LSST software development.
IPAC (Infrared Processing and Analysis Center, Caltech)
o

Draft
NOAO (National Optical Astronomy Observatory)
o

LSST Security Plan
Security and software consultants with experience in security and
operations control systems especially in the defense sector.
SLAC (Stanford Linear Accelerator Center)
o
o
Experience operating secure DOE and NSF funded science projects.
Contributing to LSST software development.
To Be Defined During Construction Phase
LSST will define the following plans and procedures during the Construction phase. They
will be effective during the Construction and Operation phases.


Incident Response Plan
Certain technical details, based on the cybersecurity environment at the time
o
o
o

Encryption and hash strength
A specific two-factor authentication mechanism
Network monitoring and intrusion detection systems
Security Procedures for LSST Sites
o
o
o
o
o
o
o
o
Awareness and training
Audit and accountability
Contingency planning
Media protection
Physical and environmental protection
Security planning
Personnel security
Communication policy
1 Common Policies
Each DM Subsystem in LSST’s infrastructure will have a specific set of policies associated
with it according to what it supports and what it needs to protect. This section describes
common policies that may be referred to from the subsystem-level cybersecurity policies.
Draft
LSST Security Plan
Page 11 of 49
1.0 Definition of Terms
1.0.1 Cybersecurity Objectives: Confidentiality, Integrity, and Availability
As a useful model, Federal Information Systems define1 the “security objectives” of
confidentiality, integrity, and availability for information and information systems as:
Confidentiality: “Preserving authorized restrictions on information access and disclosure,
including means for protecting personal privacy and proprietary information…” A loss of
confidentiality is the unauthorized disclosure of information.
Integrity: “Guarding against improper information modification or destruction, and
includes ensuring information non-repudiation and authenticity…” A loss of integrity is the
unauthorized modification or destruction of information.
Availability: “Ensuring timely and reliable access to and use of information…” A loss of
availability is the disruption of access to or use of information or an information system.
1.0.2 Impact Levels: Low, Moderate, and High
High: Exercise of the vulnerability would have a severe or catastrophic impact on LSST, to
an extent or duration that it is unable to perform one or more of its primary functions. The
failure may:



Severely violate, harm, or impede LSST’s mission, reputation, or interest
Result in highly costly loss of LSST’s major assets or resources
Cause severe or catastrophic harm to individuals or research projects
Moderate: Exercise of the vulnerability could have a serious adverse effect; a system may
still be able to perform its primary functions, but its effectiveness could be significantly
reduced. A failure may:



Violate, harm, or impede LSST’s mission, reputation, or interest
Result in the costly loss of LSST’s assets or resources
Cause significant harm to individuals or research projects
Low: Exercise of the vulnerability could have a significant but limited effect; a system would
continue to perform its primary functions, but the failure may:



Reduce a system’s performance or effectiveness
Cause minor damage to assets
Cause minor, recoverable harm to individuals or research projects
1.1 Responsibilities
Each site is expected to have one person, a cybersecurity officer, who is responsible for
overall managing and cybersecurity monitoring for the site. This person will be responsible
for ensuring proper security configuration of machines and processes at the local site,
FITS PUB 199, Standards for Security Categorization of Federal Information and Information Systems,
Computer Security Division, Information Technology Laboratory, NIST.
1
Page 12 of 49
LSST Security Plan
Draft
responding to alerts from cybersecurity monitoring mechanisms, and serving as the final
point of contact on cybersecurity issues requiring action by a human. The Archive Site will
host personnel to not only carry out these activities for the Archive Site but also coordinate
cybersecurity management across all LSST sites. Associated with the cybersecurity officer is
an appropriate budget per the LSST Operations Plan.
In addition to local security personnel, each site will have some form of general operations
staff. At the Archive and Base Sites, these will be site operators who provide 24-7
operations support. Data Access Centers (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, this
staff will monitor the site's systems for failures and warnings. In particular, alerts from
cybersecurity monitoring mechanisms will be routed first to this staff. They will make the
initial assessments of failures or other unusual events that might indicate a cybersecurity
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 overall Operations and Security policy. In such cases, the local cybersecurity officer
would be contacted.
In all cases, the procedures for reacting to possible cybersecurity 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. Cybersecurity incidents will have to
be submitted to the local incident reporting process as well as the LSST operations and
control system.
1.1.1 Incident Response
LSST’s priorities in the face of cybersecurity incidents are:
1. Recover from the incident and resume operations
2. Prevent recurrence
3. Pursue and prosecute serious or repeat attackers
Even though LSST’s top priority is recovery, LSST personnel should make reasonable efforts
to preserve forensic evidence, especially in the case of more serious incidents, for use in
follow-up investigations.
1.1.1.1
Incident Response and Security Team
LSST will designate, from among its operating staff, an Incident Response and Security
Team (IRST). It should include:



Individuals with system-level access to LSST’s computing infrastructure
Individuals with expertise in cybersecurity incident analysis and response
LSST’s security officer(s)
The incident response team should maintain a 24-hour contact point that is well known to
LSST staff. It would be expedient to have the contact point be the same as a general LSST
help desk.
JK – What is relationship of IRST to security officer, i.e. does security officer lead IRST?
Draft
1.1.1.2
LSST Security Plan
Page 13 of 49
Reporting Incidents
Any staff member who becomes aware of or suspects a cybersecurity incident should report
it to the IRST. The IRST will investigate the incident, notify affected parties (if needed), and
recommend corrective actions.
1.2 Subsystems
1.2.1 Network Architecture
Each major subsystem should be logically isolated—for example on its own sub-network or
VLAN—to allow router-level enforcement of security policies. Communication with
machines in other major subsystems should be through a DMZ where possible.
Figure 1.1 Basic network perimeter for an individual DM Subsystem (need to updated diagram
text to match document text)
1.3 Science Data
LSST data products are divided into three groups, as described in the DM System
Requirements:

Level 1 data products: Automatically generated by processing the stream of data
from the camera system during normal observing. Level 1 data products are
therefore being continuously generated and / or updated every observing night.
Page 14 of 49


LSST Security Plan
Draft
Level 2 data products: Generated from Level 1 as part of an annual Data Release.
They include data products for which extensive computation is required, often
because they combine information from many exposures.
Level 3 data products: Derived from Level 1 and/or Level 2 to support particular
science goals. Typically, a research team will create them, with the help of DMS
infrastructure, and will store them temporarily at LSST Data Access Centers (DACs).
From time to time, Level 3 products that are found to be especially useful may be
archived and supported by LSST and even promoted to Level 2.
Level 1 and Level 2 data products that have passed quality control tests are required to be
accessible to the public without restriction. The access policies for Level 3 data products
will be product- and source-specific, and in some cases will be proprietary.
One of the main objectives of the cybersecurity plan is to ensure the integrity and
availability of data for scientific users, both in storage and during network transfers. 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, including its supporting metadata such as calibration and
pointing, must be protected against corruption and deletion, as it cannot be
regenerated.
Generated data products, while they may be recomputed from the raw data, may
also be very valuable, as a massive loss of generated 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.
Delivery of data to users must ensure integrity and appropriate confidentiality. It
should contain the intended scientific content of the project and must not
inadvertently provide a vector data that is not a part of the LSST mission (malware,
advertisements, illicit media, etc.).
New scientific data sets created by end users from LSST products will form the
basis of new publishable results; thus, these datasets (which may be stored
temporarily on LSST servers) are sensitive. Even database queries they submit will
carry scientific insight. A scientist must be guaranteed, while using LSST resources,
that their data and session/command history are not accessible by other users apart
from those with whom they explicitly wish to share them.
We note again that the scope of this document relates only to the protection of data from
corruption and loss by unauthorized access. Corruption and loss due to hardware failure,
for example, is an issue for LSST’s fault tolerance design. Mechanisms for detecting
corruption, whatever the cause, are also primarily a concern of fault tolerance, and not
cybersecurity.
1.3.1 Processed Data Products Intended for Public Release
By and large, external audiences will be interested in Level 2 and 3 data products—rather
than the more raw Level 1 data products.
Confidentiality: low. The challenge lies in making meaningful queries and managing
bandwidth—not in protecting confidentiality.
Draft
LSST Security Plan
Page 15 of 49
Integrity: moderate. We should protect integrity, but if it is compromised it can be
recomputed it from archived raw data. However, detection of corruption should be regarded
as a high priority.
Availability: moderate. Temporary unavailability should be avoided, but is not
catastrophic.
1.3.2 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.
Deletion of archival data must:




Only be possible with two-factor authentication, by a highly privileged user
Be accompanied by warnings to the user
Display progress verbosely and be interruptible
Be logged, so that deleting can be tracked and reasons noted
Confidentiality: low. Archival science data is publicly available; the challenge 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, including its metadata
and provenance, must be trusted. Once lost, it is not retrievable.
Availability: moderate. Temporary unavailability should be avoided but is not catastrophic.
1.3.3 Internal Science Data
Certain data is not intended for public release—in particular, data whose quality has not
been assessed.
Confidentiality: low. An individual leak of internal science data would only cause
unreduced or low-quality data to be distributed publicly, prematurely, and would not
significantly harm LSST's operations. It might have an impact on LSST's reputation. If it
happened routinely, it would cause significant irritation and mistrust in the astronomy
community.
Integrity: high. Most internal science data will eventually be processed, archived, and
released, and therefore its requirement for integrity is the same as Archival Science Data,
above.
Availability: moderate. Temporary unavailability should be avoided but is not catastrophic.
1.3.4 User-generated Data
LSST will provide private storage space for researchers that is:



Externally accessible via standard protocols such as VOSpace
Local to LSST compute resources for efficient HPC access
(Potentially) subject to spatial quotas and time limits
Confidentiality: moderate. Researchers require confidentiality before publishing.
Page 16 of 49
LSST Security Plan
Draft
Integrity: moderate. We will attempt to preserve user-generated 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. Temporary unavailability should be avoided but is not catastrophic.
1.4 Physical Operating Environment
LSST DMS will operate almost entirely on the premises of partner institutions. As such, each
Site has its own unique physical environment, as described in its own section of this
document.
1.5 Management, Operational, and Technical Controls
1.5.1 Access Control
1.5.1.1
Internal User Access
This subsection describes how a user (as opposed to a service) who is logged into a machine
inside a particular DM Subsystem may gain access to services or shells on other machines
within that Subsystem.
1.5.1.1.1
Intra-Subsystem Shell Access
Unless the Subsystem 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
Cryptographically secure 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 Subsystem.
Rationale: Use of SSH/Kerberos within a Subsystem can slow the propagation of
unauthorized access and protect against network sniffers.
1.5.1.2
Remote User Access
This subsection describes how a user (as opposed to a service) who is logged into a machine
located outside of a particular Subsystem may gain access to services or shells on machines
within the Subsystem.
All such access shall be included in system logs described in Monitoring and Logging,
section 1.5.3.
Draft
LSST Security Plan
1.5.1.2.1
Page 17 of 49
Public & Science User Access
All access by the general public and general science user (those without administrative
access) will be limited to the Community Service Subsystem (CSS), generally via a web
portal or rich client interface. Refer to the specific CSS policies for details.
Rationale: By definition, non-CSS Subsystems 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.
1.5.1.2.2
Portal-based Access
A software component may support a portal (web) interface. When it does, it must support
authentication and authorization policies from one or more of the four categories:
1. Passive monitoring
o
o
The user connects only for retrieving (read-only) data.
Authenticate with a username and password
2. Active monitoring
o
o
User can change logging levels in a manner that may affect other users
Two-factor (2F)/one-time password (OTP) authentication required
3. Non-critical control
o
o
o
o
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
4. Critical control
o
o
o
o
1.5.1.2.3
Critical generally refers to control over operations that are dangerous to life
or property; mainly applies to the LSST Observatory Control Subsystem
(OCS) and the Telescope and Camera Control Systems (TCS and CCS)
User can change state of component, launch other components, etc. In the
case of OCS, this may mean controlling 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 Intra-Subsystem Shell Access, plus:


Support of two-factor authentication (password-less not allowed)
Remote shell access from outside a Subsystem should be restricted to designated
machines within that Subsystem (e.g. login servers); it should not be enabled by
default.
Page 18 of 49
1.5.1.2.4
LSST Security Plan
Draft
Rich Client Access
A rich client is an application that runs on the user's "local" machine and establishes a
network connection with a specialized server application on the remote machine. Examples
include 3rd party products (e.g. LabView) and custom products talking to our own services.
Such a client may be used under one of the following conditions:
1. It supports the LSST two-factor authentication mechanism, and all communication
with the server is encrypted.
2. It is run via an encrypted remote desktop (e.g. VNC)—the client application is
actually running on an internal LSST Subsystem, with a user interface outside.
1.5.1.3
Service Authentication
1.5.1.3.1
Intra-Subsystem
Software processes that communicate with each other within the protected boundaries of a
Subsystem must use some form of authentication, such as host certificates or username and
password. Heavy traffic flows, such as bulk data transfers, do not need to be encrypted.
However, control information, such as within the Event Messaging Subsystem, shall be
encrypted.
1.5.1.3.2
Intra-Site, Inter-Subsystem
Software processes that communicate across Subsystem boundaries but within a single Site,
for example database queries from the CSS to the AOS:





Shall flow through designated gateways
Shall authenticate securely, using LSST-issued host certificates where possible
Shall use an encrypted channel for control signals such as commands and queries
Shall encrypt data where computationally reasonable
May send high-volume open data unencrypted, but shall include strong integrity
checks such as checksum hashes
1.5.1.3.3
Inter-Site
Software processes that communicate between LSST Sites shall follow the policy for intrasite communication, with the addition that any potentially sensitive data (such as usergenerated data) shall be encrypted.
1.5.1.3.4
Public Internet
LSST software processes that communicate with the public Internet, for example, externally
accessible web services:




Shall flow through designated public gateway machines in the CSS
Shall allow for basic authentication (username and password) on behalf of an LSST
registered user
Where possible, shall establish encrypted channels
May, with certification by the cybersecurity officer, comply with current standards,
for the sake of compatibility—for example, if a VO-compliant query mechanism that
LSST supports doesn’t encrypt returned data
Draft
LSST Security Plan
Page 19 of 49
1.5.2 Host Requirements
Before a machine can be connected to an internal LSST network—other than the Visitor
Network—it must be reviewed and validated by the cybersecurity officer as complying with
that LSST subsystem’s security policies. Generally this will require:


An approved operating system and patching strategy
Cleanliness attestation from a trusted party, such as an LSST administrator, who has
expertise with the machine’s operating system and installed software
It may also require:

An up-to-date host certificate generated by an LSST trusted Certificate Authority
(CA)
1.5.3 Monitoring and Logging
Logging and Network monitoring systems shall feed information in real-time to both local
security personnel and to a central LSST operations center.
Selected DM Subsystem components shall relay system logs and access logs into a
centralized system that will store them and flag anomalies. The DM components selected to
relay logs should include control machines, any machines that have network connections
outside of their subsystems, and any components selected by security officers or operating
staff as important to monitor.
Networks shall be monitored by intrusion detection and traffic analysis systems, with
particular attention to traffic across subsystem boundaries. Specific network-monitoring
technologies will be determined during the construction phase.
2 DM Subsystems
Jeff writes: [This section needs to be re-written to talk specifically about the security
considerations in these subsystems and not about what the subsystems are and what they
do, that will be covered in other documents. We should presume that the functions and
data flows of each system are defined in the Infrastructure and Middleware design and
operations documents and do not need repeating here. You can simply refer other users to
those designs, the document will still stand alone enough.
It appears that some items are characterized by Confidentiality, Integrity, Availability (CIA)
assessment but not others. This should be consistent, that is, the Intro and Mgt/Ctrl
sections do not include the CIA, but the Systems and Data Products sections do.
Alternatively, all the CIAs could be collected in a table in an Appendix.
Similarly, some Mgt/Control sections have Risk Assessments and some don’t. This should
first be covered with a Common Policy specifying at least an annual risk assessment, and
then subsystem-specific risk concerns can be addressed in each Subsystem section.]
Page 20 of 49
LSST Security Plan
Draft
2.1 Observatory Control Subsystem
The Observatory Control Subsystem (OCS) is a Telescope and Site Subsystem, and not a DM
subsystem, although it is included in the DM cybersecurity plan because of its close links
with the DMS.
The OCS has some key differences from the DMS:




Much of its operation has hard real-time requirements because of its strict data
acquisition cadence.
It spans two physical locations: the mountaintop observatory and base facility,
connected by a 30km dedicated fiber-optic link.
It is not replicated—unlike DMS subsystems, there is only one OCS.
It is mostly the domain of the camera and telescope teams, less so the data
management team—particularly in the area of real-time requirements.
Therefore, compared to the DMS, interruptions or damage to OCS systems have the
potential to be both more difficult to repair and more likely to halt critical LSST operations
such as capturing science data and issuing real-time alerts. Thus, security policy in the OCS
is more stringent.
Figure 2.1 Summit and Base Sites, including Observatory Control Subsystem (OCS)
To Do: update diagram language
2.1.1 OCS Security Objectives
Security objectives for the OCS are described for each subsystem separately, below.
2.1.2 OCS Responsibilities
The LSST observatory operations staff will administer the OCS. The Data Management team
will administer the Event Broker and Data Replicator.
2.1.3 Physical Operating Environment
The OCS shares its physical environment with its site, the Summit and Base Facility—see
Section 3.1.2.
Draft
LSST Security Plan
Page 21 of 49
2.1.4 OCS Subsystems
2.1.4.1
Camera & Telescope Control Systems
These subordinate control systems to the OCS are described as part of the Camera and
Telescope designs. Refer to [Get document reference from German Schumacher].
2.1.4.2
Interface with DMS Control and Management Systems
2.1.4.2.1
Data Replicator
The OCS contains a real-time facility database, into which the TCS and CCS continuously
feed the status of LSST’s observatory systems. The Base Facility will contain a replicator
that will archive facility events and state transitions at its AOS.
Confidentiality: low. Although it is proprietary, disclosure of data about the real-time state
of the OCS would not cause harm to LSST. [Is that true? Could someone use the data for
nefarious purposes?]
Availability: moderate. Loss of the real-time facility database feed would likely halt realtime processing of science data, since the feed provides important metadata. [True?]
Integrity: high. Since the real-time feed is used to generate science metadata, undetected
corruption would bleed into the science data. [True?]
[This needs to be discussed with German Schumacher/Dave Mills to confirm the interface
and documented in the OCS – DM ICD. The replicator will likely be a client of the OCS that is
provided by the OCS team and deployed as a part of the AOS. The AOS accesses the facility
database using that client and does the replication. The database will not be sent to all DM
facilities, but will go to the Base and Archive.]
2.1.4.2.2
Event Broker
The DMS will include an Event Broker which will interface with the OCS real-time event
system bidirectionally—both sending and receiving events. See Section 2.6, the Event
Messaging Component.
2.1.5 OCS Science Data
(Check with Gregory on how to word this section)
OCS Science data includes Calibration Data as well as Raw and Crosstalk-corrected images
and associated metadata. The data originates with the primary and auxiliary telescopes,
external sensors, and the camera. It is transferred to the DMS via one of two paths:

Primary telescope images are transferred by the CCS Science Data Acquisition
Subsystem (SDS) in both raw and crosstalk-corrected forms.

Calibration data and image metadata are written by the TCS and CCS to the OCS
Engineering and Facility Database and subsequently accessed from there by the
DMS.
Page 22 of 49

2.1.5.1
LSST Security Plan
Draft
The above data are all collected and stored by the Base Facility AOS and also
transferred to the Archive Center AOS.
Calibration Data
Calibration images and data are an input for all image processing, and are necessary in
order to extract scientifically meaningful data.
Confidentiality: low. Leaked calibration data would not be significant problem for LSST.
Integrity: high. Data integrity is central to the success of LSST’s scientific mission.
Availability: low. Down time is to be avoided, but is not catastrophic.
2.1.5.2
Astronomical Image Data and Metadata
The CCS SDS will stream data from the telescope to the Base Site’s Subsystems. It will
consist of raw images, crosstalk-corrected images, and metadata from the telescope and
camera.
Confidentiality: low. LSST should avoid leaking raw and crosstalk-corrected data, since it
has not been examined for scientific validity, but it would not be serious problem.
Integrity: high. Data integrity is central to the success of LSST’s scientific mission.
Availability: moderate. Although brief interruptions are recoverable, it may be difficult to
catch up after prolonged disruptions, since the LSST DM System is architected to operate
near maximum capacity. See LSST Fault Tolerance for more details.
2.1.6 OCS Management, Operational, and Technical Controls
Aside from the details listed below, see Common Policies, section 1.5.
2.1.6.1
Access Control
Access control policies for the OCS will be determined by the Camera and Telescope teams.
The OCS will use an identity and authentication system provided by Data Management.
2.2 Archive Operations Subsystem
Every LSST DM Site (apart from the summit) includes an Archive Operations Subsystem
(AOS). The purpose of this system is to host and manage the on-going operational processes
of the site.
The AOS hosts the most important assets of a site. It directly manages the data that is served
to outside users as well as to internal processing within the Distributed Processing
Subsystem. The long-term storage subsystem holds permanent copies of released data
products that would be accessed not only for data reprocessing, but also for disaster
recovery. Consequently, this Subsystem will feature stronger protections against
unauthorized access than other systems, as well as the strictest integrity guarantees.
Draft
LSST Security Plan
Page 23 of 49
2.2.1 AOS Security Objectives
Unless otherwise specified, refer to Common Policies on Science Data, Section 1.2. Each type
of data has different security priorities, but most AOS systems will need to support all types,
so their security goals are the most-restrictive combination:
Confidentiality: moderate. Limited by user-generated data, Section 1.2.4.
Integrity: high. Limited by Archival and Internal Science Data, Sections 1.2.2 and 1.2.3.
Availability: moderate. Shared by all science data.
2.2.2 AOS Responsibilities
In addition to the site-wide security personnel (see section 2.1), the AOS will have
associated with it personnel who will be responsible for operating and monitoring the dayto-day processes of the site. These personnel will handle the typical faults and may be the
ones to discover evidence of a security problem. These personnel must be aware of the
procedures for reporting and reacting to possible security issues.
2.2.3 AOS Physical Operating Environment
The AOS shares physical facilities with its Site. See Common Policies—Physical Operating
Environment, Section 1.3.
2.2.4 AOS Components
2.2.4.1
Long-term Storage Component
Not all sites will have this component. This component provides permanent storage for core
data products, including raw images, calibration data, release catalogs, and co-added sky
images.
2.2.4.2
Data Cache Component
This is component provides temporary storage for the datasets of greatest interest at any
given time. It is assumed that any data stored here can be automatically reproduced from
another source, either by replicating a copy from another site or recreating the dataset from
original data in long-term storage.
Interfaces: The AOS provides a read-only interface to the data cache component to the DPS
and CSS.
2.2.4.3
Database servers
These servers provide access to the data catalogs, both the previously released catalogs
(which are static) as well as the current unreleased catalog (if available at the site).
Interfaces: The AOS provides a read-only interface to these servers for use by the CSS and
the DPS. If the site features a DPS for internal production, the AOS will provide a read-write
interface exclusively for updating the current unreleased catalog.
Page 24 of 49
2.2.4.4
LSST Security Plan
Draft
Dataset Access servers
These servers provide access to file-based data products. Data access services will first look
in the Data Cache for requested data sets; if the data products are not cached, the service
may request them from external sites or trigger their re-creation (via the DPS) and recaching in the Data Cache.
Interfaces: The AOS provides a read-only interface to the CSS and outward-facing DPS, and
a read-write interface to an internal DPS, if one exists.
2.2.4.5
Data Replicator service
This service copies datasets from and to other sites, via secure, authenticated connections.
2.2.4.6
Event Broker
The Event Broker routes Event messages in and out of the AOS. When exchanging events
with other systems either on site or off, it is done via secure, authenticated connections to
other Event Brokers on defined ports. This component will also maintain its own historical
database of events.
For more details, refer to section 2.6, Event Messaging Component.
2.2.4.7
Miscellaneous Operational Processes
The AOS will host all of the processes that carry out automated operations of data
management. This includes the routine execution of pipelines on the DPS, and packaging
and distributing science Alerts.
See section 1.3.3.3, Service Authentication, for security requirements.
2.2.4.8
Administrative Portal
Operational processes will be launched, controlled, and monitored from outside the system
(possibly from off-site) via an Administration Portal.
Only LSST operations personnel shall have access to this interface. It shall conform to
section 1.3.3.2, Remote User Access.
Confidentiality: high. Since the administrative portal can control operational processes,
unauthorized access could allow interference with LSST’s core functioning.
Integrity: moderate. Loss of integrity at the administrative portal would be an
inconvenience, but it would not prevent LSST’s operation. As a backup to the portal, remote
personnel can contact on-site operators by other means.
Availability: moderate. As a backup to the portal, remote personnel can contact on-site
operators by other means.
2.2.5 AOS Science Data
The AOS provides the primary storage for the following products:

Raw Science Data (crosstalk-corrected data is not stored)
Draft




LSST Security Plan
Page 25 of 49
Temporary Processed Data Products
Released Data Products
Unreleased Science Data
User Science Data
See section 1.2, Common Policies for Science Data, for security considerations for these
types of data.
2.3 Distributed Processing Subsystem
Distributed Process Subsystems (DPSs) perform internal processing for LSST:



Real-time processing (at the Base Site)
Nightly processing (Archive Site)
Processing for annual data release (Archive Site)
A DPS is a purely internal DM subsystem with no major public or cross-site network
connections. As such, its administration and security arrangements are simpler than other
DMS subsystems.
2.3.1 DPS Security Objectives
Confidentiality: low. A DPS is an internal DM subsystem that processes only Level 1 and 2
science data (see Science Data, section 1.3), which are intended for eventual public release.
A premature release would not cause major problems, as long as it is not construed to be an
“official” LSST release, which could damage LSST’s reputation for data quality.
Integrity: moderate. The computations performed by a DPS can only be relied upon if it is
known to not be compromised.
Availability: moderate. Individual nodes within a DPS are expected to have low availability
requirements, and systems that use them must be tolerant of faults such as disk failures and
memory errors, but the DPS as a whole must be generally available for LSST use and is
therefore rated moderate.
2.3.2 DPS Responsibilities
A DPS is always associated with an AOS; DPSs will be operated and maintained by the same
personnel who operate the associated AOS.
2.3.3 DPS Physical Operating Environment
A DPS will be housed next to its AOS and thus will share its physical environment.
2.3.4 DPS Components
TBD
2.3.5 DPS Science Data
The DPS will host LSST public data (Levels 1 & 2). For security objectives, see common
policies on Science Data, section 1.3.
Page 26 of 49
LSST Security Plan
Draft
2.4 Community Service Subsystem
The Community Services Subsystem (CSS) is the community’s portal into LSST data and
services. It provides:



The community access web portal
Service-based interfaces, such as VOSpace, for researchers
Private workspaces and compute resources for researchers
As the data server to the community, the CSS balances user convenience, fairness, and
security. It operates in a distributed heterogeneous environment that is connected to the
Internet to serve LSST project installations and users around the world.
Significantly, the CSS shall provide fair real-time allocation of bandwidth and compute
power, based on user profiles, which requires a robust user identity system.
2.4.1 CSS Security Objectives
The CSS provides access to all types of LSST data products. Its security objectives are driven
mainly by its handling of researchers’ private data, as described in Section 1.2.4.
Confidentiality: moderate. Researchers’ private data, code, and research methods must be
protected.
Integrity: moderate. Users need to be able to trust the integrity of their private research
data and public LSST data that they retrieve through the CSS.
Availability: moderate.
2.4.2 CSS Responsibilities
The CSS shall be administered together with the other Subsystems in its Site. For details, see
AOS Responsibilities, section 2.2.2.
2.4.3 CSS Physical Operating Environment
The CSS shares physical facilities with its Site. See Common Policies—Physical Operating
Environment, Section 1.3.
2.4.4 CSS Components
The “Sites and Subsystems” diagram illustrates when CSS fits within each Site’s overall
environment including high-level services provided. The CSS provide general access to the
public services of LSST.
2.4.5 CSS Science Data
The CSS provides data discovery and delivery services to the LSST user community. As such,
all publicly released data and their associated metadata are available through the CSS. In
addition, it provides resources to further process and store tertiary scientific data in private
scratch space that it provides to researchers.
Draft
LSST Security Plan
Page 27 of 49
The CSS provides access to the following data whose permanent storage is in the AOS, but
which may be cached and post-processed on the fly within the CSS:


Raw observational data and processed Level 1 data products (e.g. Alerts, and
DIAsources) (“Level 1” as described in Section 1.3)
Processed Level 2 data products (e.g. Source and Object catalogs) (“Level 2” as
described in Section 1.3)
In addition, the CSS provides primary storage and compute facilities for:


Researchers’ private data, derived from public LSST data (“Level 3” as described in
Section 1.2), which must be kept private to protect researchers’ work
Researchers’ metadata, code, queries, which also must be kept private
The main security drivers are fairness and isolation.


Fairness: Applications running in the CSS will need to allocate bandwidth and
computation resources fairly based on users’ privileges.
Isolation: All users have access to all LSST data, but the data they generate using
LSST facilities is private and protected from other users.
2.5 Visitor Network
Visitor Networks (VN) at each LSST site provide general-purpose connectivity to the
Internet. These networks are logically located outside of the core science networks and will
be regarded as part of the open Internet.
The LSST sites expect to receive large numbers of visitors, including researchers,
conference attendees, contractors and other personnel, most of whom need access to
Internet-based services. To meet the needs of this diverse community LSST project sites will
implement a Visitor Network. This network is logically located outside of the core networks.
It will be primarily a wireless network, but will have some hardwired Ethernet connectivity.
The goal of the network is to provide Internet connectivity for visitors and non-secure
machines. Users that require connectivity to internal resources must use one of the remote
access methods provided by LSST; there is no direct connection between the Visitor
Networks and internal LSST project networks. All traffic from the Visitor Networks will be
treated the same as traffic from the open Internet.
Host institutions may already have visitor networks that can serve in the place of a network
provided by LSST.
2.5.1 VN Security Objectives
Confidentiality: low. The Visitor Network, like the public Internet provides no
confidentiality guarantees.
Integrity: low.
Availability: low. The Visitor Network will make a reasonable attempt to be available at all
times, but it is not a core LSST service.
Page 28 of 49
LSST Security Plan
Draft
2.5.2 VN Responsibilities
The Subsystem Owners for individual implementations of the Visitor Network are
designated for each site in the LSST Operations Plan.
2.5.3 VN Physical Operating Environment
The Visitor Network resides within the physical environment described for each of the
three security domains the Base Site at La Serena, the Archive Site at NCSA, and the
standalone DAC sites (if any). The security polices and controls relevant to the servers and
network devices that serve as the core infrastructure for the Visitor Network are covered in
the LSST Network Design (document-7354).
2.5.4 VN Subsystems
The “Sites and Subsystems” diagram shows how the Visitor networks fit within the site’s
environments. The Visitor networks provide general-purpose access to the Internet. This
requires a different security model than the other LSST general support systems.
2.5.4.1
Wireless Access Points
The Wireless Access Points (WAPs) provide Internet access for visitors to the LSST sites.
Anyone physically located on the site with a system that has wireless capabilities can access
the wireless networks. The WAPs’ security includes controls that facilitate what the
reasonably expected level of service is for users of the Visitor Networks.
Policy does not allow anyone other than designated infrastructure managers at the
individual sites to install WAPs. Each site shall have the capability to detect and removed
unauthorized WAPs.
The signal from wireless access points shall be generally contained within the physical
boundaries of the sites.
Visitor network users shall only be able to connect to LSST internal resources via approved
externally facing services. They shall be treated the same as any general entity on the
Internet.
Upon connection to the Visitor Network, users shall be presented with a personal user
agreement that identifies the network and presents the acceptable use policy and the
conditions of use policy. Acceptance of the appropriate policies shall be required prior to
allowing full access to the Visitor Network services.
2.5.4.2
Ethernet Ports
Although the primary method of connection to the Visitor Network will be wireless, there
will be Ethernet ports provided. Security controls on these hardwired ports shall be
equivalent to those on the wireless network. When users initially access the network they
shall be presented with the same policies as on the wireless network. As in the wireless
network, there shall be no direct access between the Visitor Network wired infrastructure
and the LSST project’s internal networks.
Draft
LSST Security Plan
Page 29 of 49
2.5.5 VN Science Data
The Visitor Network will not bear any special responsibility for LSST data products.
2.5.6 VN Management, Operational, and Technical Controls
2.5.6.1
Access Control
Unlike other LSST networks, the visitor networks offer open access to the Internet. Specific
access controls for this network shall include:

Wireless Access points
The SSID shall not be broadcast or shall have an SSID indicative of their
nature (e.g. Visitor, Guest)

Ethernet Backbone
Users will not be required to authenticate, but must agree to the acceptable
use policy prior to being granted access.

Infrastructure systems
Administrator access to the servers in these networks shall be consistent
with central networks management policies.
The Visitor Network will not require authentication to use, unless host institutions’ policies
say otherwise. If authentication is required, it may be through the host institution rather
than LSST.
2.5.6.2
Awareness and Training
Visitors to the sites who use the Visitor Network for Internet access only and who do not
have internal accounts may receive no training other than acknowledgement of the
Acceptable Use Policy, but this should include information about the security of the network
and indicate the level of monitoring.
2.6 Event Messaging Component
The Events component functions as a nervous system for the LSST infrastructure. It is a
general-purpose publish-subscribe message system based on ActiveMQ. Jeff says to move
(copy?) the rest of this summary to the Infrastructure Reference Design: Some of its
primary uses are:





Logging
Pipeline coordination
VOEvent alerts
Internal status notifications
Error & exception alerts
Each LSST DM Subsystem has a single Event Broker that is the sole source and sink of
messages within that subsystem. Broker policies determine which events are routed intersubsystem, and which remain local.
Page 30 of 49
LSST Security Plan
Draft
Event messages are transmitted over transport-layer security and include information
about their origin (host and timestamp). Since they are unsigned, the EMC carefully controls
their creation and takes measures to prevent false message injection, including
authenticating brokers and disallowing “upstream” transmission (for example from a DAC
to the OCS).
Figure 2.2 The Event component, spanning multiple LSST Sites and Subsystems, with signed
channels (red) among brokers and event producers. To Do: update diagram language to
match document (subsystem, component, etc.)
2.6.1 EMC Security Objectives
Confidentiality: moderate. Some events may be intended for a limited audience, but
leakage is not considered to be a critical failure. In particular, events may contain
researchers’ confidential personal data and methods. Security information such as
passwords and private keys should never be transmitted via events without additional
safeguards such as out of band encryption.
Integrity: high. The highest priority is accuracy and authenticity of events. Certain types of
events must only originate from certain systems—for example, only the real-time pipeline
at the Base facility may publish Moving Object notifications. Injections must be prevented.
Availability: moderate to high. The EMC availability goal is significantly higher than the
DMS as a whole. With reasonable measures such as redundant hardware and automatic
failover, we should be able to achieve high-two-nines reliability (such as 99.5%,
independent of externalities that would also affect the subsystems in which the Event
Brokers are embedded). For more in-depth discussion, see the LSST Fault Tolerance design
document.
Draft
LSST Security Plan
Page 31 of 49
2.6.2 EMC Responsibilities
The EMC backbone shall be centrally managed, to ensure uniform compatibility and
security policy enforcement. Individual event brokers and event sub-networks may be
managed centrally, or their management may be delegated to administrators of the Systems
where they reside, according to centrally-defined policies. All event brokers shall adhere to
LSST policies, and LSST will provide software and guidelines for maintaining them.
2.6.3 EMC Physical Operating Environment
The components of the Event subsystem will share the physical environment of each
subsystem where they reside. Event Brokers will be virtual machines that share hardware
with other control components.
2.6.4 EMC Components
2.6.4.1
Event Brokers
The core of the EMC is a tight confederation of autonomous brokers. Each broker has its
own policies that determine how events are propagated:



Import: from outside the local Subsystem (from other brokers) into the broker's
subsystem
Export: exposing events from inside the local Subsystem to external brokers
Local: events that originate locally and are not offered to external brokers
Brokers authenticate to each other using centrally-issued host certificates that are
revocable and which expire and must be re-issued after a set time (probably a year). If a
broker presents a revoked certificate, other brokers will refuse to connect to it. A recently
expired (or soon-to-expire) certificate shall provoke a warning.
Brokers authenticate with their local clients (event consumers) using a host certificate as
well. It may be the same host certificate used to connect with other brokers or a locally
issued one.
2.6.4.2
Event Producers
Event Brokers are responsible for verifying and propagating events that originate within
their local subsystems. To export events to other Brokers, they shall adhere to the policies
described here or risk having their host certificates revoked.
Event producers should authenticate with their local broker using a host certificate. If the
events are to be exported outside of the local subsystem, the producer’s host certificate has
the same requirements as event brokers’ certificates.
2.6.4.3
Event Consumers
Any application in the subsystem is permitted to subscribe to (consume) events.
Event consumers subscribe to events from their local broker but are not required to present
host certificates. They shall connect via a secure channel and authenticate their broker's
identity based on its host certificate.
Page 32 of 49
LSST Security Plan
Draft
2.6.5 EMC Data
The EMC manages the flow of control data, rather than bulk observational data. The main
concern is with integrity and authenticity—event messages must really be from whom they
claim to be from.
2.6.6 EMC Management, Operational, and Technical Controls
2.6.6.1
Monitoring and Logging
Messages shall be logged, with
2.6.6.1.1
Detecting Anomalies
Messages shall be monitored and filtered for anomalies, in an effort to detect interruptions
as well as false messages such as injections and malfunctions. The central system log
monitor may be sufficient, or a separate system may be needed. More details will be
determined during construction.
2.6.6.1.2
Event Archive
The EMC will maintain a central database at the AOS that archives events from across the
DM system.
If it is necessary to periodically flush low-interest messages, those of potentially long-term
interest shall be retained. Specific policies shall be developed once the contents of messages
are better understood, and shall be reviewed regularly, at least annually.
Confidentiality: moderate. Event records could contain confidential science data and
methods belonging to individual researchers.
Integrity: high. The event archive represents an important record of LSST’s operational
details. It could also be a target for deletion or corruption by an intruder wishing to hide
tracks.
Availability: low. Operations would not be threatened if access to this data archive were
interrupted.
2.6.6.2
Network Routing
Routing rules should be in place to enforce the Events communication topology



Each LSST Subsystem, except for Visitor Networks, will have its own Event Broker,
probably a main and a backup for failover.
External communication (outside the local Subsystem): only allowed to other Event
Brokers
Internal communication (inside the local Subsystem): allowed with any host
Draft
LSST Security Plan
2.6.6.3
Risk Assessment
2.6.6.3.1
False Message Injection
Page 33 of 49
False events could cause serious problems, especially if they propagate to sensitive Systems,
or if there are large numbers of them.




Extraneous logging
False VOEvent alerts
Erroneous status notifications ("telescope preparing for exposure", "nightly data
transfer complete")
False exceptions ("the camera is malfunctioning", "error during nightly processing",
"DAC X has lost Y raw data")
False events could originate from:



Injection into a Broker by a rogue client
A rogue Broker sending to clients or other Brokers
A software bug or operational error in an otherwise properly functioning LSST
subsystem
2.6.6.3.2
Interruption
Event messages, like all LSST network traffic, are vulnerable to network disruptions. That
subject is covered in network design and fault-tolerance design documents.
2.7 Operation Center
The DM System Operation Center (DMSOC) will … see Ephibian document.
3 Sites
3.1 Summit and Base Site (JK - Ron Lambert review for accuracy)
The Summit and Base Site (SBS) are situated on Cerro Pachon and La Serena, Chile, in
facilities operated by the AURA.
Page 34 of 49
LSST Security Plan
Draft
Figure 3.1 Summit and Base Sites
They house:



Summit
o Observatory—observatory building, telescope, camera
o The mountain end of the Observatory Control Subsystem (see section 2.1)
Summit-Base Network Link
o Connects Summit to Base site
Base Site
o The base end of the Observatory Control Subsystem (see section 2.1)
o The Base Facility, comprised of:
 Archive Operations Subsystem (see Section 2.2)—responsible for a
full archive of raw data
 Distributed Processing Subsystem (see Section 2.3)—responsible for
real-time processing
o The Chilean Data Access Center
 Community Service Subsystem (see Section 2.4)—responsible for
Chilean public data access
 Visitor Network (see Section 2.5)
The Summit Network provides the infrastructure used by systems such as the Observatory
Control Subsystem to support the safe acquisition, transport, control and other operational
activities related to LSST data and provides the communications path down to the La Serena
Base Site, from whence the data is passed on to the other major LSST subsystems such as
Data Access Centers and LSST data end users.
The goal of LSST Summit/Base Site security is to provide physical and logical defense in
depth to maintain the confidentiality, integrity and availability of LSST data and resources
at the LSST Pachon and La Serena facilities, along with the long-haul communications
infrastructure that connects LSST Pachon to the La Serena Base Site and beyond. This
protection requires the prudent application of industry best practices and technologies in
security as available at the moment of system acquisition and design.
3.1.1 SBS Responsibilities
Most responsibilities are covered in Common Policies—Responsibilities, section 1.1 of this
document.
Draft
3.1.1.1
LSST Security Plan
Page 35 of 49
Partner Institution: AURA
The summit and base are housed in facilities operated by the AURA. AURA and LSST have
signed a Cooperative Agreement that covers security responsibilities and staffing.
3.1.2 SBS Physical Operating Environment
The Summit Site is located on Cerro Pachon in Chile, at 3300m altitude, roughly 40km into
the AURA property shared between Cerro Tololo Interamerican Observatory, Gemini, SOAR
and other tenants. Physical access to this site is restricted by the site's remoteness from
populated areas as well as guards at the CTIO/AURA gate at the entrance to the AURA
property from public access roads.
The La Serena Base Site is located at the CTIO/AURA facilities in La Serena, Chile. Physical
access to LSST resources at this site is controlled by guards and physical technical access
controls into the LSST offices and computer center.
3.1.3 SBS Subsystems
The LSST Summit and Base Site network infrastructure is defined in the LSST Network
Design (document-7354). The network is safeguarded and controlled by various
authentication solutions and monitored through network and host based Intrusion
Detection Systems and centralized log file analyzers.
Other than network devices that are specifically part of other LSST subsystems such as the
Observatory Control Subsystem or the Camera System, the LSST Summit infrastructure also
includes necessary system servers such as DNS, authentication servers, system log servers,
intrusion detection sensors, and monitoring console systems.
Further, the Summit network communications infrastructure provides a tunneled, enforced
transmission path between acquired LSST data and the La Serena Base Site via leased
communication lines, with the La Serena and Pachon networks falling within very similar
Security Policy domains connected via a so called "Metropolitan Area Network". Within La
Serena, there is a dedicated, enforced communication path for LSST data to the local Chilean
DAC at La Serena.
Confidentiality: moderate. While the confidentiality of the SBS should be protected, leakage
of operational information or live data would not seriously impede LSST’s operations.
Integrity: high. LSST’s highest security priority is the integrity of its scientific data; if that is
called into question, it throws doubt on LSST’s central mission.
Availability: moderate, with the Summit network requiring somewhat higher availability
than the La Serena Base Site.
A preliminary risk assessment of the expected elements of the Summit and La Serena LSST
network suggests that these portions of the LSST infrastructure will require medium
Confidentiality, high Integrity, and medium Availability, with the Summit network requiring
somewhat higher availability than the La Serena Base Site.
Page 36 of 49
LSST Security Plan
Draft
3.1.4 SBS Management, Operational, and Technical Controls
Operational controls are the most important element of security at the LSST Summit facility,
with the goal of preventing any security incident that might disturb the data taking and data
flow missions of the telescope. Detecting and correcting any anomalous events is also very
important. The La Serena Network's mission is to support the Summit Network, and to
provide the operational communication infrastructure necessary to safely send the LSST
data on to Archive Sites and the LSST DACs.
3.1.4.1
Access Control
The Summit network is the most private and protected network in LSST’s infrastructure.
Only authorized LSST principals shall be granted access to it, and only from authorized
hosts. As a purely internal subsystem, no external access will be granted. Remote user
access will be limited to fixed gateways such as SSH servers or terminal servers, so that
direct remote access can be avoided.
Access to the Summit network is governed by Common Policies—Access Control, Section
1.4.2. In particular, access shall be granted only to specific LSST personnel.
Individual LSST Applications software at the Archive and DACs will need to have network
access to the LSST Summit and Base Site resources. These Applications shall have security
designed in and shall use secure and enforced communications paths into the LSST
Summit/Base Site facilities using security packages such as SSL or SSH tunnels.
3.1.4.2
Awareness and Training
LSST Support personnel both at the Summit and Base Site shall complete the necessary
security training to operate LSST facilities safely and to be aware of security concerns. They
shall be required to sign off on LSST Security Policy documents including those addressing
"acceptable use" and LSST Summit/Base Site monitoring policy, and that this acceptable use
and monitoring policy shall be reinforced by logon banners when access to the LSST
Summit/Base Site Network is made.
3.1.4.3
Audit, Accountability, and Monitoring
There shall be centralized security logging and monitoring facilities for both the LSST
Summit and Base Site Networks that will collect traffic, system log and other audit records
from all critical computers and devices, including routers and firewalls. The centralized
security logging and monitoring servers will provide data mining in order to analyze traffic
and logs for intrusions and anomalies, and automatic alarm/event notification capabilities
to alert personnel to the occurrence of significant events. Candidate technology would
include event reporting features that are capable of near-real-time reporting and automatic
alarms via local console, email, pagers and cell phones.
Critical LSST Summit and Base Site computers shall be configured to periodically run
integrity-checking tools and send their results to the central monitoring servers.
Along with the host based intrusion described above, the LSST Summit and Base Site
Network shall also support network based intrusion detection, using a subsystem which
includes non-invasive network packet sensors that sample network traffic, and central
monitoring servers that collect and analyze these packets to discover unusual network
activity, security incidents or other events of interest.
Draft
3.1.4.4
LSST Security Plan
Page 37 of 49
Identification and Authentication
Two-factor authenticated VPN and/or SSH access shall be required to access Summit/Base
Site computers and network resources both from over the network and from within the
LSST Summit or Base Site Network, through a centralized Identification Management
system of a level To Be Determined, ranging from a simple authentication server to a more
sophisticated single sign on (SSO) solution.
The identification and authentication process shall be logged and correlated with other
audit information including logs provided by physical technical access control devices
necessary to gain access to La Serena server rooms.
3.1.4.5
Physical and Environmental Protection
The LSST Summit and Base Site infrastructures will need additional protection in the layout
of cable trays and equipment positioning and isolation due to the possibility of earthquakes
at both sites. While tsunamis are possible in La Serena, the actual location of the
CTIO/AURA facilities at 90m above sea level and 3.5km distant from the seashore should
minimize the risk posed by this threat if historical records are any guide.
The LSST Summit and Base Site facilities will need well sized UPS and power conditioning
as historically in La Serena and at the AURA telescope sites power outages and brownouts
are fairly common.
Disaster recovery plans are documented in the LSST Operations Plan.
3.2 Archive Site
The Archive Site (AS) will:




House a full archival copy of LSST’s raw observational data
Perform nightly processing and processing for annual data releases
Provide services for the public and researchers
House a co-located Data Access Center
3.2.1 AS Security Objectives
The Archive Center’s security objectives differ for each of its subsystems; for more details,
see DMS Subsystems, Section 2 of this document.
3.2.2 AS Responsibilities
The Archive Center will be operated cooperatively by NCSA and LSST.
3.2.3 AS Physical Operating Environment
The Archive Center will be housed in Champaign, Illinois, on the campus of the University of
Illinois, at the Illinois Petascale Computing Facility, which will also house the Blue Waters
supercomputing cluster (to be commissioned in 2010) and other NCSA-operated
supercomputers. The facility will be operated by NCSA.
Physical access to the building will be restricted, controlled by NCSA.
Page 38 of 49
LSST Security Plan
Draft
3.2.4 AS Subsystems
The Archive Site will house:





An Archive Operations Subsystem (AOS)
A Distributed Processing Subsystem (DPS)
A Community Service Subsystem (CSS)
A Visitor Network
Event Brokers as part of the Event Messaging Component (EMC)
3.3 Standalone Data Access Centers
The LSST project will operate co-located DACs at the Archive Site and Base Site. Subject to
expanded or external funding, one or more Standalone Data Access Centers (DACs) will be
commissioned. Each Standalone DAC will house:




A Community Service Subsystem (CSS)
An Archive Operations Subsystem (AOS)
A Visitor Network
Event Brokers as part of the Event Messaging Component (EMC)
Standalone DACs are similar in organization to the Archive Center, although the scale may
differ; for example, a DAC’s AOS will be smaller, housing only a fraction of the archived LSST
data, rather than a full copy, and caching frequently-accessed data retrieved from the main
Archive Center.
Draft
LSST Security Plan
Page 39 of 49
Figure 3.2 Network Perimeter for a Data Access Center
3.4 Headquarters and Education and Public Outreach Center
The DM Headquarters Site will house an Education and Public Outreach (EPO) Center (see
section 2.8) and a DM System Operations Center (DMSOC) (see section 2.7). Refer to EPO
use cases/estimates.
TBD. Contain a CSS only? Event Brokers? (JK – Will contain a DM System Operations Center
(DMSOC, refer to Ephibian concept document. Will also feed/house EPO database (KB:
user-writable by the external EPO community), refer to EPO use cases/estimates)
Page 40 of 49
LSST Security Plan
Draft
4 Threats
Introduction
Physical threats are covered in a separate document about operational risks.
LSST cyber-threats include both unintentional acts (inadvertent data entry) and deliberate
actions (network based attacks, malicious software upload, unauthorized access to
confidential information). LSST is a high profile project providing data to the public.
Therefore, there is little risk of public interest in obtaining LSST public data through illegal
means. However, the nature of LSST’s computing resources (massive storage, processing,
and network capability) will be an attractive target for a variety of reasons.
Threat Source
Public User
Hacker, Cracker
Motivation




Unintentional
Denial of Service
(DOS)
Challenge
Ego; bragging
rights
Rebellion
Threat Actions








Organized computer
criminals


Monetary gain
Hijacked
resources







Insiders (poorly trained,
disgruntled, malicious,
negligent, dishonest, or
terminated employees,
graduate students,
scientists, etc.)






Curiosity
Ego
Intelligence
Monetary gain
Revenge
Unintentional
errors and
omissions (e.g.,







Denial of Service through
automated queries or poorly
constructed queries
Unauthorized system access
System intrusion
Web page defacement
Warez storehouse
Social engineering
Vector for further internal
and external attacks (account
subversion, DOS, etc.)
Intrusion via automated
virus, worms, etc.
Unauthorized system access
System intrusion
Blackmail
Data storehouse (warez,
porn, etc.
Malicious code (e.g., virus,
logic bomb, Trojan horse)
System sabotage
Vector for further internal
and external attacks (account
subversion, DOS, etc.)
Phishing
Blackmail
Browsing of proprietary
information
Computer abuse
Unauthorized system access
Fraud and theft
Input of falsified, corrupted
data
Draft
LSST Security Plan
data entry error,
programming
error, denial of
service)
Page 41 of 49





Malicious code (e.g., virus,
logic bomb, Trojan horse)
System bugs
System intrusion
System sabotage
Denial of Service through
automated queries or poorly
constructed queries
4.1 Vulnerabilities
4.1.1 Known Sources
As with any organization implementing large-scale Information Technology resources, LSST
faces human threats to infrastructure and availability. Human threat motivations differ but
impacts vary primarily based on the type of access they have or can obtain. Human threats
utilize a toolset based on their level of access, permissions, and technical capability. The
following are common vulnerability classes posed by various human threats:















Shoulder surfing
Social engineering
Brute force password guessing
Data deletion/corruption
Phishing
Spam
Unauthorized remote access
Denial of Service
Buffer overflow
Cross-site scripting
SQL injection
Virus/worm/malware
Unauthorized privilege elevation
Application exploit
OS exploit
4.1.2 Other Sources of Vulnerabilities
The technical and nontechnical vulnerabilities associated with an IT system’s processing
environment can be identified via the information-gathering techniques including:




Questionnaire
On-site Interviews
Document Review
Automated Scanning Tool
LSST will conduct an annual review of other industry sources (e.g., vendor Web pages that
identify system bugs and flaws) in preparing for the interviews and in developing effective
questionnaires to identify vulnerabilities that may be applicable to specific IT systems (e.g.,
a specific version of a specific operating system). In addition, LSST designers and
administrators will use resources available on the Internet as another source of information
Page 42 of 49
LSST Security Plan
Draft
on known system vulnerabilities posted by vendors, along with hot fixes, service packs,
patches, and other remedial measures that may be applied to eliminate or mitigate
vulnerabilities. Documented vulnerability sources that will be utilized in an on-going
vulnerability analysis include, but are not limited to, the following:







The IT system’s audit reports, system anomaly reports, security review reports, and
system test and evaluation reports
Vulnerability lists, such as the NIST I-CAT vulnerability database
(http://icat.nist.gov)
Security advisories, such as FedCIRC and the Department of Energy’s Computer
Incident Advisory Capability bulletins
Vendor advisories
Commercial computer incident/emergency response teams and post lists (e.g.,
SecurityFocus.com forum mailings)
Information Assurance Vulnerability Alerts and bulletins for military systems
System software security analyses.
Note that the for LSST, the types of vulnerabilities that will exist, and the methodology
needed to determine whether the vulnerabilities are present, will vary depending on the
phase of development:



During the R&D phase, the search for vulnerabilities should focus on the
organization’s security policies, planned security procedures, and system
requirement definitions, and the vendors’ or developers’ security product analyses
(e.g., white papers). This is the current LSST phase.
During the Construction phase, the identification of vulnerabilities should be
expanded to include more specific information, such as the planned security
features described in the security design documentation and the results of system
certification test and evaluation. This is the next phase for LSST.
During the Commissioning and Operations phases, the process of identifying
vulnerabilities should include an analysis of the IT system security features and the
security controls, technical and procedural, used to protect the system. This will be
the final phase for LSST.
4.2 Control Analysis
The goal of this step is to analyze the controls that are planned for implementation by LSST
to minimize or eliminate the probability of a threat’s exercising a system vulnerability. The
following sections discuss control methods, control categories, and the control analysis
technique.
4.2.1 Control Methods
Security controls consist of the use of technical and non-technical methods (e.g., firewalls as
well as processes and procedures). Technical controls are described in section 1.1.12 but
are summarized below. Process and procedural controls are not completely defined yet but
will include Management Security and Operational Security.
4.2.2 Technical Security Controls
Technical security controls are described in more detail in section 1.1.12 but will consist of:
Draft















LSST Security Plan
Page 43 of 49
Access Control Lists
Firewalls
Network Intrusion Detection/Prevention Systems (NIDS/NIPS)
Host-Based Intrusion Detection/Prevention Systems (HIDS/HIPS)
Logical Network Separation
Virtual Private Network (VPNs)
Operating System Access Controls
Application Access Controls
Application Proxies
Remote Gateway Systems
Demilitarized Zones (DMZs)
Encryption
One-time Password Mechanisms
Anti-virus/anti-malware software
Anti-spam appliance/service
4.2.3 Management Security Controls
Management security will consist of:










Assignment of responsibilities
Continuity of support
Incident response capability
Periodic review of security controls
Personnel clearance and background investigations
Risk assessment
Security and technical training
Separation of duties
System authorization and reauthorization
System or application security plan
4.2.4 Operational Security Controls
Operational security will consist of:









Control of air-borne contaminants (smoke, dust, chemicals)
Controls to ensure the quality of the electrical power supply
OS and application patch application
Data media access and disposal
External data distribution and labeling
Facility protection (e.g., computer room, data center, office)
Humidity control
Temperature control
Control of workstations, laptops, and stand-alone personal computers
4.3 Likelihood Determination
The likelihood that a potential vulnerability could be exercised by a given threat-source can
be described as high, medium, or low. These are described below.
Page 44 of 49
LSST Security Plan
Draft
High: The threat-source is highly motivated and sufficiently capable, and controls to
prevent the vulnerability from being exercised are ineffective.
Medium: The threat-source is motivated and capable, but controls are in place that may
impede successful exercise of the vulnerability.
Low: The threat-source lacks motivation or capability, or controls are in place to prevent, or
at least significantly impede, the vulnerability from being exercised.
4.3.1 Vulnerabilities from Human Threats.
Breach or loss of data or computing resources from hacker/cracker/criminal computer
organization – LOW. The LSST facilities and systems within the scope of this document will
not have significant public exposure. There will be extremely limited port and protocol
exposure and these will be heavily protected by multiple, powerful technical control
mechanisms (e.g., VPN, one-time passwords, proxies, secure gateways, intrusion detection
monitoring, etc.), plus procedural controls (i.e., timely patch application, etc.).
Breach or loss of data or downtime due to insiders – LOW. LSST controls to mitigate insider
threats include one-time passwords for administrative accounts, logical network
separation, access control lists, and full data replication. Motivation for most insider threats
is not considered high and the control mechanisms planned for implementation (both
technical and non-technical) should mitigate the threats sufficient to warrant a low
likelihood of impact.
4.4 Impact Analysis
The adverse impact of a security event can be described in terms of loss or degradation of
any, or a combination of any, of the following three security goals: integrity, availability, and
confidentiality. The following list provides a brief description of each security goal and the
consequence of its not being met.



Loss of Confidentiality: System and data confidentiality refers to the protection of
information from unauthorized disclosure. The impact of unauthorized disclosure of
confidential information can range from the jeopardizing of national security to the
disclosure of Privacy Act data. Unauthorized, unanticipated, or unintentional
disclosure could result in loss of public confidence, embarrassment, or legal action
against the organization.
Loss of Integrity: System and data integrity refers to the requirement that
information be protected from improper modification. Integrity is lost if
unauthorized changes are made to the data or IT system by either intentional or
accidental acts. If the loss of system or data integrity is not corrected, continued use
of the contaminated system or corrupted data could result in inaccuracy, fraud, or
erroneous decisions. Also, violation of integrity may be the first step in a successful
attack against system availability or confidentiality. For all these reasons, loss of
integrity reduces the assurance of an IT system.
Loss of Availability: If a mission-critical IT system is unavailable to its end users,
the organization’s mission may be affected. Loss of system functionality and
operational effectiveness, for example, may result in loss of productive time, thus
impeding the end users’ performance of their functions in supporting the
organization’s mission.
Draft
LSST Security Plan
Page 45 of 49
4.4.1 Magnitude of Impact Definitions
High: Exercise of the vulnerability (1) may result in the highly costly loss of major tangible
assets or resources; (2) may significantly violate, harm, or impede an organization’s
mission, reputation, or interest; or (3) may result in human death or serious injury.
Medium: Exercise of the vulnerability (1) may result in the costly loss of tangible assets or
resources; (2) may violate, harm, or impede an organization’s mission, reputation, or
interest; or (3) may result in human injury.
Low: Exercise of the vulnerability (1) may result in the loss of some tangible assets or
resources or (2) may noticeably affect an organization’s mission, reputation, or interest.
4.4.2 Magnitude of Impacts due to Vulnerabilities
Loss of Integrity – LOW. The effect of a successful human threat breach to data integrity is
anticipated to be low. Full daily data replication between multiple facilities and multiple
integrity checks would ensure that any core data that becomes compromised could be
discovered and corrected or restored unless it was compromised before any replication
occurred.
In that event, impact would be a potential loss of data for one day or however long the
hacker/cracker/criminal remains undetected. Network control mechanisms and
procedures are expected to be in place such that data flows from Summit to Base to local
data store to main archive but with access restricted to pipeline data.
Logical network controls should contain a breach to a facility. Most harmful would be a
breach at a Chile facility since those facilities will contain the most recent data and a full
copy of all data. Each day, new data will be replicated to the main archive center in the US.
Even if all Chile data were corrupted or lost, the data at the US facility could be used to reconstitute all data except the data lost since the breach occurred.
Loss of Availability – MEDIUM. The impact of a loss of availability is based on the facility
where a breach occurred. If either full data store facility (Chile or US) were taken offline or
became unavailable due to data loss, there would be an impact to those public users
requiring access to archival data. Assuming a vulnerability was exploited to compromise the
availability of a single facility, the remaining facility could provide sufficient availability,
albeit with some degradation of performance, so that scientific and public availability would
not be significantly affected.
However, if all data at a facility were compromised and needed to be restored, the process
of rebuilding complete systems from backup and then full repopulation of the complete data
set across the available communications links would be highly time consuming; it would
take more time the longer the LSST systems are in operation as the full data set will grow
enormously over time. It could take a considerable amount of time for full data restoration
especially with normal operational data flows occurring at the same time. The end result
could be degraded performance for a lengthy period of time.
Loss of Confidentiality – LOW. LSST data is generally not confidential. The primary
confidentiality concerns are based on proprietary academic researchers’ data processing. A
loss of confidentiality would likely lead to a loss of confidence in the administration of the
system, embarrassment, and loss of reputation to LSST among researchers. While these
Page 46 of 49
LSST Security Plan
Draft
losses could be considerable to LSST prestige and to researcher peace of mind, the general
public would not be directly affected and amateur astronomers could continue personal
research since the integrity of core LSST data would not be impugned.
4.4.3 Mitigation Strategies
4.4.4 Vulnerabilities from Human Threats
The LSST facilities at the summit, base, and national archive center are subject to
vulnerabilities due to human threats from hackers/crackers, computer criminal
organizations, and insiders.
Vulnerability: Shoulder surfing
Mitigations:



Security awareness training
Physical security
One-time password mechanisms for administrative functions
Residual Risk: LOW
Vulnerability: Physical theft of resources or media
Mitigations:




Physical security
Procedures require visitor escort
Procedures limit visitor access
Logically separated visitor network segment
Residual Risk: LOW
Vulnerability: Social engineering
Mitigations:


Security Awareness training
One-time passwords
Residual Risk: LOW
Vulnerability: Brute force password guessing
Mitigations:



One-time passwords
OS access controls
Firewalls and network ACLs (for remote attempts to obtain a password file)
Residual Risk: LOW
Draft
LSST Security Plan
Vulnerability: Data deletion/corruption
Mitigations:



Operations training (against accidental deletion/corruptions)
Data replication and restoration processes
Incident response process
Residual Risk: LOW
Vulnerability: Phishing
Mitigations:


Security Awareness training
Anti-virus/anti-malware software
Residual Risk: LOW
Vulnerability: Spam
Mitigations:


Mail Transfer Agents configured not to allow open relays
Anti-spam appliance/service
Residual Risk: LOW
Vulnerability: Unauthorized remote access
Mitigations:






Firewall limited exposure of remote access ports and protocols
Encrypted VPN connectivity
Strong authentication (one-time password)
Network Intrusion Prevention systems
Application access controls
Remote gateway desktops
Residual Risk: LOW
Vulnerability: Denial of Service
Mitigations:




Firewall limited exposure of remote access ports and protocols
Network Intrusion Prevention systems
Host configurations to limit syn flood connections
Incident Response process
Residual Risk: LOW
Vulnerability: Buffer overflow
Mitigations:
Page 47 of 49
Page 48 of 49




LSST Security Plan
Applications written to limit and verify all user input fields
Application proxy devices
Short turn-around patch application
Network Intrusion Prevention systems
Residual Risk: LOW
Vulnerability: Cross-site scripting
Mitigations:


Applications written to limit and verify all user input fields
Applications written with cookie security
Residual Risk: LOW
Vulnerability: SQL injection
Mitigations:



Applications written to limit and verify all user input fields
Applications written with strong typing whenever possible
User input translated to parameterized statements or escaped at minimum
Residual Risk: LOW
Vulnerability: Virus/worm/malware
Mitigations:





Anti-virus/anti-malware software required on all LSST owned Windows-based
workstations and servers
Logical network segmentation to limit propagation
Network access controls lists to limit propagation
Network Intrusion Prevention systems
Host-based Intrusion Prevention systems
Residual Risk: LOW
Vulnerability: Unauthorized privilege elevation
Mitigations:








Firewalls (for protection from external threats)
Network Intrusion Prevention Systems
Host-based Intrusion Prevention Systems
OS access controls
Logical network separation
Network access control lists
Application access controls
Separation of duties
Residual Risk: LOW
Draft
Draft
LSST Security Plan
Page 49 of 49
Vulnerability: Application exploit
Mitigations:





Applications written to limit and verify all user input fields
Applications written with cookie security
Applications written with strong typing whenever possible
User input translated to parameterized statements or escaped at minimum
Short-turnaround application patch application from patch release
Residual Risk: LOW
Vulnerability: General OS exploit
Mitigations:


Minimal OS features necessary enabled
Short-turnaround application patch application from patch release
Residual Risk: LOW
The controls provide mitigation for the vulnerabilities associated with human threats and
provide a high degree of protection against data loss, corruption, and confidentiality
however there is always residual risk associated with human threats, especially insider
threats and remote attacks based on zero day exploits.