diff --git a/Makefile b/Makefile index 11ae4f1..d962582 100644 --- a/Makefile +++ b/Makefile @@ -51,5 +51,5 @@ meta.tex: Makefile .FORCE # call as needed not automating in this doc tables: .FORCE - makeTablesFromGoogle.py ${GSHEET} matrix\!A1:F + makeTablesFromGoogle.py ${GSHEET} matrixR3\!A1:F diff --git a/aglossary.tex b/aglossary.tex index bc8db4c..3c4223e 100644 --- a/aglossary.tex +++ b/aglossary.tex @@ -9,8 +9,10 @@ \newglossaryentry{Association of Universities for Research in Astronomy} {name={Association of Universities for Research in Astronomy}, description={ consortium of US institutions and international affiliates that operates world-class astronomical observatories, AURA is the legal entity responsible for managing what it calls independent operating Centers, including LSST, under respective cooperative agreements with the National Science Foundation. AURA assumes fiducial responsibility for the funds provided through those cooperative agreements. AURA also is the legal owner of the AURA Observatory properties in Chile}} \newglossaryentry{Authorization} {name={Authorization}, description={The action of allowing an authorized or anonymous entity access to data or services.}} \newacronym{BTS} {BTS} {Base (La Serena) Test Stand} +\newglossaryentry{Baseline} {name={Baseline}, description={The point at which project designs or requirements are considered to be 'frozen' and after which all changes must be traced and approved}} \newglossaryentry{Broker} {name={Broker}, description={Software which receives and redistributes Alerts, and may also perform processing such as filtering for certain characteristics, cross-matching with non-LSST catalogs, and/or light-curve classification, in order to identify and prioritize targets for follow-up and/or make scientific analyses. }} \newglossaryentry{Butler} {name={Butler}, description={A middleware component for persisting and retrieving image datasets (raw or processed), calibration reference data, and catalogs}} +\newacronym{CCB} {CCB} {\gls{Change Control Board}} \newacronym{CCD} {CCD} {\gls{Charge-Coupled Device}} \newacronym{COS} {COS} {Center \gls{Operations} Services} \newacronym{CS} {CS} {citizen science} @@ -18,6 +20,8 @@ \newacronym{CUI} {CUI} {Controlled Unclassified Information} \newglossaryentry{Camera} {name={Camera}, description={The LSST subsystem responsible for the 3.2-gigapixel LSST camera, which will take more than 800 panoramic images of the sky every night. SLAC leads a consortium of Department of Energy laboratories to design and build the camera sensors, optics, electronics, cryostat, filters and filter exchange mechanism, and camera control system}} \newglossaryentry{Center} {name={Center}, description={An entity managed by AURA that is responsible for execution of a federally funded project}} +\newglossaryentry{Change Control} {name={Change Control}, description={The systematic approach to managing all changes to the LSST system, including technical data and policy documentation. The purpose is to ensure that no unnecessary changes are made, all changes are documented, and resources are used efficiently and appropriately}} +\newglossaryentry{Change Control Board} {name={Change Control Board}, description={Advisory board to the Project Manager; composed of technical and management representatives who recommend approval or disapproval of proposed changes to, deviations from, and waivers to a configuration item's current approved configuration documentation}} \newglossaryentry{Charge-Coupled Device} {name={Charge-Coupled Device}, description={a particular kind of solid-state sensor for detecting optical-band photons. It is composed of a 2-D array of pixels, and one or more read-out amplifiers}} \newacronym{ComCam} {ComCam} {The commissioning \gls{camera} is a single-raft, 9-CCD \gls{camera} that will be installed in LSST during commissioning, before the final \gls{camera} is ready.} \newglossaryentry{Commissioning} {name={Commissioning}, description={A two-year phase at the end of the Construction project during which a technical team a) integrates the various technical components of the three subsystems; b) shows their compliance with ICDs and system-level requirements as detailed in the LSST Observatory System Specifications document (OSS, LSE-30); and c) performs science verification to show compliance with the survey performance specifications as detailed in the LSST Science Requirements Document (SRD, LPM-17)}} @@ -97,6 +101,7 @@ \newglossaryentry{National Science Foundation} {name={National Science Foundation}, description={primary federal agency supporting research in all fields of fundamental science and engineering; NSF selects and funds projects through competitive, merit-based review}} \newacronym{OGA} {OGA} {Other Government Agencies} \newacronym{OPS} {OPS} {\gls{Operations}} +\newacronym{OS} {OS} {Operating System} \newacronym{OSS} {OSS} {Observatory System Specifications; \gls{LSE}-30} \newglossaryentry{Object} {name={Object}, description={In LSST nomenclature this refers to an astronomical object, such as a star, galaxy, or other physical entity. E.g., comets, asteroids are also Objects but typically called a Moving Object or a Solar System Object (SSObject). One of the DRP data products is a table of Objects detected by LSST which can be static, or change brightness or position with time}} \newglossaryentry{Operations} {name={Operations}, description={The 10-year period following construction and commissioning during which the LSST Observatory conducts its survey}} @@ -118,6 +123,7 @@ \newacronym{RSP} {RSP} {Rubin \gls{Science Platform}} \newacronym{RTN} {RTN} {Rubin Technical Note} \newglossaryentry{Review} {name={Review}, description={Programmatic and/or technical audits of a given component of the project, where a preferably independent committee advises further project decisions, based on the current status and their evaluation of it. The reviews assess technical performance and maturity, as well as the compliance of the design and end product with the stated requirements and interfaces}} +\newglossaryentry{Risk} {name={Risk}, description={The degree of exposure to an event that might happen to the detriment of a program, project, or other activity. It is described by a combination of the probability that the risk event will occur and the consequence of the extent of loss from the occurrence, or impact. Risk is an inherent part of all activities, whether the activity is simple and small, or large and complex}} \newacronym{SAL} {SAL} {Service Abstraction Layer} \newacronym{SLAC} {SLAC} {\gls{SLAC National Accelerator Laboratory}} \newglossaryentry{SLAC National Accelerator Laboratory} {name={SLAC National Accelerator Laboratory}, description={A national laboratory funded by the US Department of Energy (DOE); SLAC leads a consortium of DOE laboratories that has assumed responsibility for providing the LSST camera. Although the Camera project manages its own schedule and budget, including contingency, the Camera team’s schedule and requirements are integrated with the larger Project. The camera effort is accountable to the LSSTPO.}} @@ -144,6 +150,7 @@ \newacronym{UKDF} {UKDF} {United Kingdom Data Facility} \newacronym{US} {US} {United States} \newacronym{USDF} {USDF} {United States Data Facility} +\newacronym{UTC} {UTC} {Coordinated Universal Time} \newacronym{VLAN} {VLAN} { Virtual Local Area Network} \newacronym{VPN} {VPN} {virtual private network} \newacronym{VRO} {VRO} {(not to be used)Vera C. Rubin Observatory} diff --git a/compliance.tex b/compliance.tex index c448916..32c9ea2 100644 --- a/compliance.tex +++ b/compliance.tex @@ -1,53 +1,198 @@ \tiny \begin{longtable} {|p{0.5\textwidth}|p{0.05\textwidth}|p{0.05\textwidth}|p{0.4\textwidth} |} \caption{This table provides an overview of the \citeds{NIST.SP.800-171} and Rubin compliance with it. \label{tab:compliance}}\\ \hline -\textbf{NIST 800-171}&\textbf{2024 Status}&\textbf{Intended Compliance}&\textbf{Note} \\ \hline +\textbf{NIST 800-171r3}&\textbf{2024 Status}&\textbf{Intended Compliance}&\textbf{Note} \\ \hline {3.1 ACCESS CONTROL}&&& \\ \hline -{3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).}&{Y}&{Y}& \\ \hline -{3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute.}&{Y}&{Y}&{IPA groups are in place on the summit restriiiicting users abilities. Legacy systems use the active directory groups for this.} \\ \hline -{3.1.3 Control the flow of CUI in accordance with approved authorizations.}&{Y}&{Y}& \\ \hline -{3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.}&{Y}&{Y}&{Principle of least privilege is applied. Many users have access to hosts that is unneeded.} \\ \hline -{3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.}&{N}&{Y}&{Targeted sudo rules are needed for common operations. IPA controls sudo centrally } \\ \hline -{3.1.6 Use non-privileged accounts or roles when accessing nonsecurity functions.}&{Y}&{Y}& \\ \hline -{3.1.7 Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.}&{}&{Y}&{This is probably sudo attempts audits. Full commands can be logged in at the cost of extra load for the servers.} \\ \hline -{3.1.8 Limit unsuccessful login attempts.}&{Y}&{Y}&{Web Services such as love, foreman, ipa console, nublado, etc. may need rate limiting. We don't use passwords in ssh hosts, only ssh keys (which many consider more secure). We are not aware of a retry limit for ssh-key access; an appropriate extra level of security would be to not use the default port 22. However, we do limit attempts to 6 with a block of 600 minutes, which will effectively block failed SUDO logins.} \\ \hline -{3.1.9 Provide privacy and security notices consistent with applicable CUI rules.}&{N}&{Y}&{Check login notices etc. A login banner can be displayed upon login } \\ \hline -{3.1.10 Use session lock with pattern-hiding displays to prevent access and viewing of data after a period of inactivity.}&{Y}&{Y}&{This is our policy.} \\ \hline -{3.1.11 Terminate (automatically) a user session after a defined condition.}&{Y}&{Y}&{ssh sessions are generally not limited on hosts but VPN will timeout daily; some network equipment has timeouts set;} \\ \hline -{3.1.12 Monitor and control remote access sessions.}&{N}&{Y}&{We currently check who and from where is connecting.} \\ \hline -{3.1.13 Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.}&{Y}&{Y}&{VPN is in use} \\ \hline -{3.1.14 Route remote access via managed access control points.}&{Y}&{Y}&{Bastion nodes -- IPSec routers now inplace also.} \\ \hline -{3.1.15 Authorize remote execution of privileged commands and remote access to security-relevant information.}&{Y}&{Y}& \\ \hline -{3.1.16 Authorize wireless access prior to allowing such connections.}&{Y}&{Y}&{All devics attaching in Chile need to be registered by Mac address.} \\ \hline -{3.1.17 Protect wireless access using authentication and encryption.}&{Y}&{Y}& \\ \hline -{3.1.18 Control connection of mobile devices.}&{Y}&{Y}&{In the sense there is no open wifi, and on the summit devices must be registered. } \\ \hline -{3.1.19 Encrypt CUI on mobile devices and mobile computing platforms.23}&{Y}&{Y}&{Data will not exist on mobile devices - in the case where an image may exist on say commissioning team laptop we will have disk encryption enabled. } \\ \hline -{3.1.20 Verify and control/limit connections to and use of external systems.}&{Y}&{Y}&{This implies vetting of devices that connect to the control network - we use mac address for laptops and personal mobile phones can not connect to the control network. We also have a separation with the \gls{LHN} \gls{SSID} and \gls{VLAN}s.} \\ \hline -{3.1.21 Limit use of portable storage devices on external systems.}&{N}&{Y}&{Can be rolled out with puppet but there are some servers that need usb. } \\ \hline -{3.1.22 Control CUI posted or processed on publicly accessible systems.}&{Y}&{Y}&{We do not intend to post images on publicly accessible systems. (DMTN-286)} \\ \hline +{03.01.01 Account Management + +a. Define the types of system accounts allowed and prohibited. + +b. Create, enable, modify, disable, and remove system accounts in accordance with policy, procedures, prerequisites, and criteria. + +c. Specify: + +1. Authorized users of the system, + +2. Group and role membership, and + +3. Access authorizations (i.e., privileges) for each account. + +d. Authorize access to the system based on: + +1. A valid access authorization and + +2. Intended system usage. + +e. Monitor the use of system accounts. + +f. Disable system accounts when: + +1. The accounts have expired, + +2. The accounts have been inactive for [Assignment: organization-defined time period], + +3. The accounts are no longer associated with a user or individual, + +4. The accounts are in violation of organizational policy, or + +5. Significant risks associated with individuals are discovered. + +g. Notify account managers and designated personnel or roles within: + +1. [Assignment: organization-defined time period] when accounts are no longer required. + +2. [Assignment: organization-defined time period] when users are terminated or transferred. + +3. [Assignment: organization-defined time period] when system usage or the need-to-know changes for an individual. + +h. Require that users log out of the system after [Assignment: organization-defined time period] of expected inactivity or when [Assignment: organization-defined circumstances].}&{Y}&{Y}&{IPA groups are in place for summit and unix groups at SLAC which restrict privileges of individual users. +Off boarding and account disabling in place - considering active account with monthly reaffirmation instead. } \\ \hline +{03.01.02 Access Enforcement +Enforce approved authorizations for logical access to CUI and system resources in +accordance with applicable access control policies.}&{Y}&{Y}&{IPA groups are in place on the summit restriiiicting users abilities. Legacy systems use the active directory groups for this.} \\ \hline +{03.01.03 Information Flow Enforcement +Enforce approved authorizations for controlling the flow of CUI within the system and between connected systems.}&{Y}&{Y}&{DMTN-199 defines the control flow for pixel data. Its implentation enforces it.} \\ \hline +{03.01.04 Separation of Duties}&{Y}&{Y}&{Principle of least privilege is applied. Some users have access to hosts that is unneeded.} \\ \hline +{03.01.05 Least Privilege}&{Y}&{Y}&{Targeted sudo rules are needed for common operations. IPA controls sudo centrally } \\ \hline +{03.01.06 Least Privilege – Privileged Accounts}&{Y}&{Y}&{Most user accounts are not privileged. Our systems have no form of selecting a role to use. } \\ \hline +{03.01.07 Least Privilege – Privileged Functions}&{Y}&{Y}&{We log sudo attempts .} \\ \hline +{03.01.08 Unsuccessful Logon Attempts}&{Y}&{Y}&{Web Services such as love, foreman, ipa console, nublado, etc. may need rate limiting. We don't use passwords in ssh hosts, only ssh keys (which many consider more secure). We are not aware of a retry limit for ssh-key access; an appropriate extra level of security would be to not use the default port 22. However, we do limit attempts to 6 with a block of 600 minutes, which will effectively block failed SUDO logins.} \\ \hline +{03.01.09 System Use Notification. +Display a system use notification message with privacy and security notices +consistent with applicable CUI rules before granting access to the system.}&{N}&{Y}&{Check login notices etc. A login banner can be displayed upon login } \\ \hline +{03.01.10 Device Lock}&{Y}&{Y}&{This is our policy.} \\ \hline +{03.01.11 Session Termination. +Terminate a user session automatically after [Assignment: organization-defined +conditions or trigger events requiring session disconnect].}&{Y}&{Y}&{ssh sessions are generally not limited on hosts but VPN will timeout daily; some network equipment has timeouts set;} \\ \hline +{03.01.12 Remote Access}&{Y}&{Y}&{We currently check who and from where is connecting. IPA groups conrol access (and 2FA VPN). Bastion nodes are used to control ingress. UNIX groups are used at SLAC for access control.} \\ \hline +{03.01.13 Withdrawn}&{}&{}&{Withdrawn in revision 3} \\ \hline +{03.01.14 Withdrawn}&{}&{}&{Withdrawn in revision 3} \\ \hline +{03.01.15 Withdrawn}&{}&{}&{Withdrawn in revision 3} \\ \hline +{03.01.16 Wireless Access}&{Y}&{Y}&{All devices attaching in Chile need to be registered by Mac address. We further consider still requiring 2FA VPN to access privileged systems from the WiFi.} \\ \hline +{03.01.17 Withdrawn}&{ }&{ }&{Withdrawn in revision 3} \\ \hline +{03.01.18 Access Control for Mobile Devices}&{Y}&{Y}&{Mobile devices must be registered on the summit - mobile devices do not contain pixel data. In the case where an image may exist on say commissioning team laptop we will have disk encryption enabled. } \\ \hline +{03.01.19 Withdrawn}&{Y}&{Y}&{Withdrawn in revision 3} \\ \hline +{03.01.20 Use of External Systems}&{Y}&{Y}&{This implies vetting of devices that connect to the control network - we use mac address for laptops and personal mobile phones can not connect to the control network. We also have a separation with the \gls{LHN} \gls{SSID} and \gls{VLAN}s.} \\ \hline +{03.01.21 Withdrawn}&{ }&{ }&{Withdrawn in revision 3} \\ \hline +{03.01.22 Publicly Accessible Content}&{Y}&{Y}&{We do not intend to post images on publicly accessible systems. (DMTN-286). We intend to roll out training.} \\ \hline {3.2 AWARENESS AND TRAINING}&&& \\ \hline -{3.2.1 Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.}&{Y}&{Y}& \\ \hline -{3.2.2 Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.}&{P}&{Y}&{OUO trainign at SLAC} \\ \hline -{3.2.3 Provide security awareness training on recognizing and reporting potential indicators of insider threat.}&{Y}&{Y}&{We would like to do more here like capture flag exercises for developers or blue/red teams events} \\ \hline +{03.02.01 Literacy Training and Awareness}&{Y}&{Y}&{A specific course for DMTN-199 is in prep. Each org has cyber security training already.} \\ \hline +{03.02.02 Role-Based Training}&{P}&{Y}&{OUO training at SLAC, DMTN-199 training for commissioners, Specific training for satellite catalog handlers. +We would like to do more here like capture flag exercises for developers or blue/red teams events} \\ \hline +{03.02.03 Withdrawn}&{ }&{ }&{Withdrawn in revision 3} \\ \hline {3.3 AUDIT AND ACCOUNTABILITY}&&& \\ \hline -{3.3.1 Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.}&{Y}&{Y}& \\ \hline -{3.3.2 Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.}&{Y}&{Y}& \\ \hline -{3.3.3 Review and update logged events.}&{P}&{Y}&{We may look for a third party contract for this.} \\ \hline -{3.3.4 Alert in the event of an audit logging process failure.}&{N}&{Y}& \\ \hline -{3.3.5 Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.}&{N}&{Y}&{Again shall look for third party contract for this} \\ \hline -{3.3.6 Provide audit record reduction and report generation to support on-demand analysis and reporting.}&{Y}&{Y}&{Observability system} \\ \hline -{3.3.7 Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate timestamps for audit records.}&{Y}&{Y}& \\ \hline -{3.3.8 Protect audit information and audit logging tools from unauthorized access, modification, and deletion.}&{Y}&{Y}& \\ \hline -{3.3.9 Limit management of audit logging functionality to a subset of privileged users.}&{Y}&{Y}& \\ \hline +{03.03.01 Event Logging}&{Y}&{Y}&{Observability contract.} \\ \hline +{03.03.02 Audit Record Content +a. Include the following content in audit records: +1. What type of event occurred +2. When the event occurred +3. Where the event occurred +4. Source of the event +5. Outcome of the event +6. Identity of the individuals, subjects, objects, or entities associated with the +event}&{N}&{Y}& \\ \hline +{03.03.03 Audit Record Generation}&{P}&{Y}&{We may look for a third party contract for this.} \\ \hline +{03.03.04 Response to Audit Logging Process Failures + +a. Alert organizational personnel or roles within [Assignment: organization-defined time period] in the event of an audit logging process failure. + +b. Take the following additional actions: [Assignment: organization-defined additional actions].}&{N}&{Y}& \\ \hline +{03.03.05 Audit Record Review, Analysis, and Reporting + +a. Review and analyze system audit records [Assignment: organization-defined frequency] for indications and the potential impact of inappropriate or unusual activity. + +b. Report findings to organizational personnel or roles. + +c. Analyze and correlate audit records across different repositories to gain organization-wide situational awareness.}&{N}&{Y}&{Again shall look for third party contract for this} \\ \hline +{03.03.06 Audit Record Reduction and Report Generation + +a. Implement an audit record reduction and report generation capability that supports audit record review, analysis, reporting requirements, and after-the-fact investigations of incidents. + +b. Preserve the original content and time ordering of audit records.}&{Y}&{Y}&{Observability system} \\ \hline +{03.03.07 Time Stamps + +a. Use internal system clocks to generate time stamps for audit records. + +b. Record time stamps for audit records that meet [Assignment: organization-defined granularity of time measurement] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.}&{Y}&{Y}& \\ \hline +{03.03.08 Protection of Audit Information + +a. Protect audit information and audit logging tools from unauthorized access, modification, and deletion. + +b. Authorize access to management of audit logging functionality to only a subset of privileged users or roles.}&{Y}&{Y}&{Only specific admin users have access to audit logs} \\ \hline +{03.03.09 Withdrawn}&{ }&{ }&{Withdrawn in revision 3} \\ \hline {3.4 CONFIGURATION MANAGEMENT}&&& \\ \hline -{3.4.1 Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles.}&{Y}&{Y}&{We use mainly infrastructure as code approaches so the software is well tracked. IT inventory all the hardware. } \\ \hline -{3.4.2 Establish and enforce security configuration settings for information technology products employed in organizational systems.}&{Y}&{Y}& \\ \hline -{3.4.3 Track, review, approve or disapprove, and log changes to organizational systems.}&{Y}&{Y}&{We have CCBs and code change process in place which also cover the infrastructure as code. } \\ \hline -{3.4.4 Analyze the security impact of changes prior to implementation.}&{Y}&{Y}& \\ \hline -{3.4.5 Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.}&{Y}&{Y}& \\ \hline -{3.4.6 Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities.}&{Y}&{Y}& \\ \hline -{3.4.7 Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.}&{Y}&{Y}&{We get a lot of this by mainly containerizing the applications and having users work within deployed containers.} \\ \hline -{3.4.8 Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.}&{Y}&{Y}&{SUDO lists to restrict access so users can not install applicaitons on the summit nor in SLAC (outside a container). } \\ \hline -{3.4.9 Control and monitor user-installed software.}&{Y}&{Y}& \\ \hline +{03.04.01 Baseline Configuration + +a. Develop and maintain under configuration control, a current baseline configuration of the system. + +b. Review and update the baseline configuration of the system [Assignment: organization-defined frequency] and when system components are installed or modified.}&{Y}&{Y}&{We use mainly infrastructure as code approaches so the software is well tracked. IT inventory all the hardware. } \\ \hline +{03.04.02 Configuration Settings + +a. Establish, document, and implement the following configuration settings for the system that reflect the most restrictive mode consistent with operational requirements: [Assignment: organization-defined configuration settings]. + +b. Identify, document, and approve any deviations from established configuration settings.}&{Y}&{Y}&{ConConfiguration settings are defined and documented in the lsst-it rancher, puppet and phalanx repos. } \\ \hline +{03.04.03 Configuration Change Control + +a. Define the types of changes to the system that are configuration-controlled. + +b. Review proposed configuration-controlled changes to the system, and approve +or disapprove such changes with explicit consideration for security impacts. + +c. Implement and document approved configuration-controlled changes to the +system. + +d. Monitor and review activities associated with configuration-controlled changes +to the system.}&{Y}&{Y}&{We have an operatons CCB (https://rtn-072.lsst.io/) and code change process in place which also cover the infrastructure as code. } \\ \hline +{03.04.04 Impact Analyses + +a. Analyze changes to the system to determine potential security impacts prior to change implementation. + +b. Verify that the security requirements for the system continue to be satisfied after the system changes have been implemented.}&{Y}&{Y}&{Continuous integrations checks on puppet and phalanx check any changes prior to test deploy which is done prior to production. } \\ \hline +{03.04.05 Access Restrictions for Change + +Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.}&{Y}&{Y}&{At infrastructure level this is is controlled by the Chile DevOps team and the SLAC IT team.} \\ \hline +{03.04.06 Least Functionality + +a. Configure the system to provide only mission-essential capabilities. + +b. Prohibit or restrict use of the following functions, ports, protocols, connections, and services: [Assignment: organization-defined functions, ports, protocols, connections, and services]. + +c. Review the system [Assignment: organization-defined frequency] to identify unnecessary or nonsecure functions, ports, protocols, connections, and services. + +d. Disable or remove functions, ports, protocols, connections, and services that are unnecessary or nonsecure.}&{Y}&{Y}&{Most application level functionality is controlled via phalanx. The OS level is puppet controlled.} \\ \hline +{03.04.07 Withdrawn}&{ }&{}&{Withdrawn in revision 3} \\ \hline +{03.04.08 Authorized Software – Allow by Exception + +a. Identify software programs authorized to execute on the system. + +b. Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system. + +c. Review and update the list of authorized software programs [Assignment: organization-defined frequency].}&{Y}&{Y}&{SUDO lists restrict access so users can not install applications on the summit nor in SLAC (outside a container). Mainly we containerize the applications and have users work within deployed containers. All containers are controlled/deployed via phalanx configuration.} \\ \hline +{03.04.09 Withdrawn}&{ }&{ }&{Withdrawn in revision 3} \\ \hline +{03.04.10 System Component Inventory + +a. Develop and document an inventory of system components. + +b. Review and update the system component inventory [Assignment: organization- +defined frequency]. + +c. Update the system component inventory as part of installations, removals, and +system updates.}&{Y}&{Y}&{phalanx.lsst.io} \\ \hline +{03.04.11 Information Location + +a. Identify and document the location of CUI and the system components on which +the information is processed and stored. + +b. Document changes to the system or system component location where CUI is +processed and stored.}&{Y}&{Y}&{DMTN-199- Embargo rack and pixel zones are our places for restricted items.} \\ \hline +{03.04.12 System and Component Configuration for High-Risk Areas + +a. Issue systems or system components with the following configurations to +individuals traveling to high-risk locations: [Assignment: organization-defined +system configurations]. + +b. Apply the following security requirements to the systems or components when +the individuals return from travel: [Assignment: organization-defined security +requirements].}&&& \\ \hline {3.5 IDENTIFICATION AND AUTHENTICATION}&&& \\ \hline {3.5.1 Identify system users, processes acting on behalf of users, and devices.}&{Y}&{Y}& \\ \hline {3.5.2 Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.}&{Y}&{Y}& \\ \hline @@ -106,8 +251,9 @@ {3.13.4 Prevent unauthorized and unintended information transfer via shared system resources.}&{Y}&{Y}&{DMTN-286 and SITCOMTN-076 cover ground rules on this} \\ \hline {3.13.5 Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.}&{Y}&{Y}& \\ \hline {3.13.6 Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).}&{Y}&{Y}&{We may need to bring up iptables on each host} \\ \hline -{3.13.7 Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).}&{Y}&{Y}& \\ \hline -{3.13.8 Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.}&{Y}&{Y}&{IPSec and encryption at rest} \\ \hline +{03.13.07 Withdrawn}&{Y}&{Y}&{Withdrawn in revision 3} \\ \hline +{03.13.08 Transmission and Storage Confidentiality +Implement cryptographic mechanisms to prevent the unauthorized disclosure of CUI during transmission and while in storage.}&{Y}&{Y}&{IPSec and encryption at rest. 2FA VPN to access summit.} \\ \hline {3.13.9 Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.}&{Y}&{Y}& \\ \hline {3.13.10 Establish and manage cryptographic keys for cryptography employed in organizational systems.}&{Y}&{Y}& \\ \hline {3.13.11 Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.}&{Y}&{Y}& \\ \hline @@ -123,7 +269,7 @@ {3.14.4 Update malicious code protection mechanisms when new releases are available.}&{Y}&{Y}& \\ \hline {3.14.5 Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.}&{Y}&{Y}& \\ \hline {3.14.6 Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.}&{Y}&{Y}& \\ \hline -\textbf{Total requirements}&\textbf{}&\textbf{108}& \\ \hline -\textbf{Total Rubin Intends to comply with }&\textbf{}&\textbf{107}& \\ \hline -\textbf{Total Rubin Complies with in 2024}&\textbf{}&\textbf{95}& \\ \hline +\textbf{Total requirements}&\textbf{}&\textbf{111}& \\ \hline +\textbf{Total Rubin Intends to comply with }&\textbf{}&\textbf{100}& \\ \hline +\textbf{Total Rubin Complies with in 2024}&\textbf{}&\textbf{91}& \\ \hline \end{longtable} \normalsize