NIST SP 800-234 日本語訳

Yang Guo Jeremy Licata Jeff Neel Gary Key James Waterman Ian Lee Catherine Hinton David Shrader Andrew Prout Albert Reuther Ted Bohrer Katsutoshi Ishisoko Kyle Earley Aron Warren Tony DeNardo Ian Czarnezki Erik Deumens

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-234

Yang Guo
Jeremy Licata
Computer Security Division
Information Technology Laboratory

Jeff Neel
Argonne National Laboratory

Gary Key*
James Waterman
DoD HPCMP

Ian Lee
Lawrence Livermore National Laboratory/ShorePoint, LLC

Catherine Hinton
David Shrader
Los Alamos National Laboratory

Andrew Prout
Albert Reuther
MIT Lincoln Laboratory

Ted Bohrer
Katsutoshi Ishisoko
NASA

Kyle Earley
Ohio Supercomputer Center

Aron Warren
Tony DeNardo
Sandia National Laboratories

Ian Czarnezki
University of Arkansas

Erik Deumens
University of Florida

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-234

May 2026

U.S. Department of Commerce Howard Lutnick, Secretary

National Institute of Standards and Technology

Craig Burkhardt, Acting Under Secretary of Commerce for Standards and Technology and Acting NIST Director

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies
Copyright, Use, and Licensing Statements
NIST Technical Series Publication Identifier Syntax

Publication History
Approved by the NIST Editorial Review Board on 2026-04-27

How to Cite this NIST Technical Series Publication
Guo Y, Licata J, Neel J, Key G, Waterman J, Lee I, Hinton C, Shrader D, Prout A, Reuther A, Bohrer T, Ishisoko K, Earley K, Warren A, DeNardo T, Czarnezki I, Deumens E (2026) High-Performance Computing (HPC) Security Overlay. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-234. https://doi.org/10.6028/NIST.SP.800-234

Author ORCID iDs
Yang Guo: 0000-0002-3245-3069 Jeremy Licata: 0000-0001-8793-5471 Jeff Neel: 0009-0004-5003-9429 Ian Lee: 0000-0001-6952-2585 Catherine Hinton: 0000-0002-5230-2428 Andrew Prout: 0000-0002-4408-0247
Albert Reuther: 0000-0002-3168-3663 Kyle Earley: 0009-0009-5681-8972 Aron Warren: 0000-0002-5090-2198 Erik Deumens: 0000-0002-7398-3090

Contact Information sp800-234-comments@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Additional Information
Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/234/final, including related content, potential updates, and document history.

All comments are subject to release under the Freedom of Information Act (FOIA).

High-performance computing (HPC) systems provide fundamental computing infrastructure for large-scale and complex simulations, big data analysis, and the training of artificial intelligence (AI) and machine learning (ML) models, all at exceptional speeds. Securing HPC systems is essential to safeguard AI models, protect sensitive data, and realize the full benefits of HPC. The HPC system utilizes specialized hardware, software, and high-speed networks within intricate user environments, and high performance is a fundamental requirement of the system. This NIST Special Publication introduces an HPC security overlay designed to address these unique security characteristics and requirements. Built on the moderate baseline defined in NIST SP 800-53B, the overlay tailors 60 security controls from NIST SP 800-53 with supplemental guidance and/or discussion to enhance their applicability in HPC contexts. This overlay aims to provide practical, performance-conscious security guidance that can be readily adopted. For many organizations, it offers a robust foundation for securing HPC environments while also allowing for further customization to meet specific operational or mission needs. This document is intended for use by IT security managers, compliance officers, HPC system administrators, and agency program managers responsible for securing HPC environments.

high-performance computing; HPC reference architecture; HPC security; moderate control baselines; security controls; security overlay; overlay.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

High-performance computing (HPC) systems provide fundamental computing infrastructure and play a pivotal role in economic competitiveness and scientific discovery. The capacity to analyze big data, rapidly conduct complex simulations, and train large-scale AI models is vital to the Nation’s vision for maintaining its global competitive edge. Therefore, it is essential to secure HPC systems to protect AI models, ensure data safety, and achieve the anticipated benefits.

This document develops an overlay, as defined in NIST Special Publication (SP) 800-53B [3]. It outlines the SP 800-53 [2] controls at the moderate impact level that require specific guidance applicable to HPC systems. This HPC security overlay was developed to provide supplemental guidance and discussions tailored to the unique characteristics of HPC systems. Its goal is to make the implementation of the security overlay achievable and effective while accounting for system performance impacts.

SP 800-223 [1] proposes a zone-based HPC reference architecture, as shown in Fig. 1.

Fig. 1. HPC system reference architecture

An HPC system is divided into four function zones: Access Zone, Management Zone, High-Performance Computing Zone (or Computing Zone for brevity), and Data Storage Zone. Each zone offers distinct services with specific performance requirements, features a unique architecture, and faces different threats.

While many security controls from SP 800-53r5 (Revision 5) [2] are applicable, some controls need to be tailored to suit the unique architecture and performance requirements of HPC systems. Additionally, different zones within the system face different threats, providing an opportunity to create customized guidance for each zone. Implementing fine-grained controls can effectively address security needs without compromising system performance.

This HPC security overlay uses the moderate baseline outlined in SP 800-53B [3] as the basic control baseline. The tailoring and augmented discussions are conducted at five levels: the entire High-Performance Computing (HPC) system (i.e., All Zones), the Access Zone, the Management Zone, the Computing Zone, and the Data Storage Zone. The moderate-impact baseline makes the HPC security overlay applicable to a wide range of HPC systems, since system compromise can have serious adverse — though not catastrophic — impacts. If necessary, operators can further customize this security framework to meet their specific needs. For instance, an HPC system that supports multi-tenancy may need its own security overlay that can be developed based on the overlay described in this document. As another example, an HPC system with a high baseline requires additional considerations and can be expanded with additional controls.

The rest of the document is organized as follows:

Table 1 summarizes the security controls in the HPC control overlay. It includes 287 controls that belong to the moderate control baseline, as defined in SP 800-53B [3]. While control AC-10 is not part of the moderate control baseline, it is relevant for controlling the number of user sessions in an HPC system and is tailored into several widely used control frameworks. It is indicated by the letter “N” in the Moderate Baseline column. The symbols used in the table are:

Table 1. A Summary of Security Controls in the HPC Control Overlay

The total 60 security controls are either supplemented with additional guidance and/or augmented with discussions. In this section, these tailored security controls are categorized into 14 groups and presented in subsections for easier comparison.

AC-2, Account Management Discussion for All Zones: An account’s role should dictate its access to the HPC system and specific zones.

Supplemental Guidance for the Access Zone: This zone should be accessible to all authorized accounts, including users and system administrators.

Supplemental Guidance for the Management Zone: This zone is only accessible to system administrators.

Supplemental Guidance for the Computing Zone: This zone can be accessed by system administrators and by user accounts authorized by the batch scheduler. Authorized users can access only high-performance computing nodes assigned by the batch scheduler.

Supplemental Guidance for the Data Storage Zone: This zone is only accessible to system administrators.

Discussion for the Data Storage Zone: The data storage zone provides data service to the other zones. Users can access data services via data service Application Programming Interfaces (APIs), but cannot log in directly to the data storage servers/nodes. A good example of an API to the storage system is by using a mounted POSIX file system.

AC-3, Access Enforcement Supplemental Guidance for All Zones: In HPC, the access privileges granted on one zone may not be automatically cascaded to another zone. For example, regular users have login access to the access zone and, through scheduler control, to certain nodes in the compute zone, but they do not have login access to the management and storage zones. Additionally, administrators should not automatically have cascaded access across the entire system. Instead, they should be separated according to their duties with respect to the scheduler, storage, and other management functions. Finally, modern operating systems, hardware, and other tools can be configured to monitor access patterns and stop access when patterns deviate from the expected behavior.

AC-6(5), Least Privilege | Privileged Accounts Discussion for All Zones: In addition to the principle of least privilege, the privileges assigned to users and system administrators should be appropriate for their roles. The number of separate roles and accounts for system administrators should align with local policy. For instance, system administrators may schedule system maintenance jobs (e.g., perform rolling upgrades) with root privileges using a scheduler. However, system administrators with root access should not — by policy — run user-type jobs with elevated privilege in the computing zone.

AC-17(4), Remote Access | Privileged Commands and Access Supplemental Guidance for the Management Zone: There should be an organizationally defined and approved path to connect to the management zone, such as a gateway or bastion host. Access to the Management Zone from other zones should be restricted, and these access paths should not overlap with user access paths. For instance, separate networks or VLANs should be used for login access and API access to the Management Zone.

AC-6(9), Least Privilege | Log Use of Privileged Functions Discussion for All Zones: Reducing the logging of privileged functions may pose a more significant risk than summarizing or discarding other logging events. Organizations should carefully consider this risk when evaluating the need to reduce logging. See AU-2 for further discussion.

AU-2, Event Logging Supplemental Guidance for All Zones: Organizations should examine logging events to ensure that there is no duplicate logging. They may also consider reducing the logging event set with tolerable risks to ensure HPC system performance.

Discussion for All Zones: Parallelization in HPC environments may result in duplicated logging of the same event, and the large logging volume may negatively impact HPC system performance. For further event logging guidance, see the Office of Management and Budget (OMB) Memorandum M-21-31 [4] and the Cybersecurity and Infrastructure Security Agency (CISA) OMB M-21-31 implementation guide [5], which provide detailed, extensive lists of events with guidance on how to categorize and handle them. Following the CISA guidance, there should be prioritized, detailed logging in the Management Zone over the Access Zone, with lower priority given to the Data Storage Zone and the Computing Zone. Increase logging based on the priority list and allocate resources (e.g., storage, performance) according to the risks that need to be managed through logging. Consider using an untamperable, versionable, and immutable logging infrastructure to ensure log integrity.

AU-3, Content of Audit Records Discussion for All Zones: For further guidance, see OMB M-21-31 [4] and the CISA guide [5] for its implementation. Following the CISA guidance, the level of detail in logging in the Management Zone should be prioritized over the Access Zone, followed by the Data Storage Zone and the Computing Zone at the lowest priority. Increase logging based on the priority list, and allocate resources (e.g., storage, performance) according to the risks that need to be managed through logging.

AU-4, Audit Log Storage Capacity Discussion for All Zones: The volume of logging in HPC systems can grow rapidly and unexpectedly. Organizations should customize their logging practices across zones to effectively manage log volume while also considering future logging requirements during procurements. Centralized logging is recommended for improved log retention and management.

AU-5, Response to Audit Logging Process Failures Discussion for All Zones: The volume of logging in HPC systems can increase rapidly and unexpectedly. Organizations must be alerted early and respond promptly to prevent their logging systems from overflowing and causing potential cascading failures. A swift response to logging failures is particularly essential for HPC systems that include diskless nodes, as these nodes lack local persistent storage to withstand an outage of the centralized logging service.

AU-11, Audit Record Retention Discussion for All Zones: Due to the system’s size and complexity, the volume of HPC system log data can be enormous. Organizations are encouraged to consider different retention policies based on their log data’s sensitivity and usefulness for audit purposes.

AC-2(5), Account Management | Inactivity Logout Discussion for All Zones: While it is best practice to log out whenever possible, a logout may negatively impact ongoing work. In such scenarios, consider implementing compensatory measures to regulate access to the login session. The organization needs to decide on approaches and policies that align with the mission requirements. Users should be trained to utilize the capability as necessary.

Supplemental Guidance for the Access Zone: The recommended logout time should align with the security policy for managing HPC user keyboard and mouse inactivity in the Access Zone. In HPC systems, it is crucial to distinguish a login session from the running processes that it controls. If it is feasible to log out of a session after inactivity without terminating the running process it controls, then the inactivity logout control can be implemented in HPC systems.

Discussion for the Access Zone: If the processes running under the login session are separated from the remote login session, the controlling remote session can be terminated without affecting the running processes. Organizations can educate their users on utilizing tools such as GNU Screen [6] or tmux [7] to enable the separation.

Supplemental Guidance for the Computing Zone: The recommended logout time frame should conform to the organization’s security policy regarding inactivity (e.g., no keyboard or mouse input) in interactive sessions in the Computing Zone. Users who have active running jobs or processes, i.e., batch jobs without a controlling interactive session, should not be logged out. Access to compute nodes should be terminated only when compute jobs are completed.

Discussion for the Computing Zone: User inactivity may occur while waiting for companion computing nodes to finish their tasks. Automatic user logout could lead to hanging jobs in the Computing Zone. AC-10, Concurrent Session Control³ Supplemental Guidance for All Zones: The maximum number of allowed concurrent sessions in an HPC system may be set at a greater value at the organization’s discretion. The maximum number of allowed concurrent sessions in different HPC zones may be set at different values.

Discussion for All Zones: Here, concurrent sessions refer to interactive concurrent sessions. Due to its scale and the number of interactive jobs that it supports, an HPC system generally requires more concurrent sessions than a typical enterprise system. Organizations are encouraged to conduct a proper risk assessment when choosing the maximum concurrent session threshold.

AC-12, Session Termination Supplemental Guidance for the Access Zone: The selected session termination threshold should reflect the security policy for handling HPC user inactivity in the Access Zone. In general, the session termination threshold is set at a higher value than in typical enterprise systems.

Discussion for the Access Zone: Session termination terminates the user’s interactive job and causes the user to lose their place in the scheduling queue. If the endpoints from which connections to the HPC system are made can be controlled, then a screen lock on the endpoint mitigates the risk of lengthening the termination threshold. Also, consider using tools that allow running processes to be disconnected from login sessions. In that case, the termination of the login session does not impact the running process.

Supplemental Guidance for the Computing Zone: The selected session termination threshold should reflect the security policy for handling HPC user inactivity in the Computing Zone. Sessions with current running jobs should not be terminated automatically in this zone.

Discussion for the Computing Zone: User inactivity may be caused by waiting for a companion compute node to finish processing the data. Terminating the session will lead to hanging jobs in the Computing Zone.

SC-10, Network Disconnect Discussion for All Zones: Most HPC jobs can continue running even if the external network connection to the login node is lost. This includes interactive debugging sessions, which may run for a long time. The debugging session should be managed using a tool that allows the running process to be temporarily disconnected from the login session. If the connection to that session is terminated, the user can still reconnect later.

CP-1, Policy and Procedures Discussion for All Zones: The contingency plan, policy, and procedures are heavily influenced by the mission of the HPC systems. For instance, research HPC systems may not be as critical as business support systems and may tolerate longer outages. Due to the cost of HPC systems, having a fully functional alternate site is often cost-prohibitive, and funds may be better spent upgrading the primary site. The reconstitution strategy should prioritize what data needs to be backed up. The policy and procedures should make clear to users what data is and is not backed up in HPC systems. Because of the large data sizes in HPC systems, reconstitution is often a shared responsibility that must be clearly established. For example, the system operator will be responsible for system and configuration data, whereas the data owners may need to establish appropriate reconstitution processes for their projects. The intermediate data that often change and have little intrinsic value may not be backed up. Accordingly, HPC contingency plans may focus on reconstitution, reloading user input data from external authoritative sources, and ensuring that users are trained to promptly copy their output data (i.e., computational results) to external archives.

CP-6, Alternate Storage Site Discussion for All Zones: It may not be feasible to back up all of the data on HPC systems. Configuration data and critical project information should be prioritized for backup at the alternate site to ensure that the HPC system can be restored to a functional state. The organization should identify critical data (e.g., user home directories, configuration management files) to be backed up to the alternate site. User training and contingency plans should clearly specify which data is backed up at the alternate site and which is not.

CP-7, Alternate Processing Site Discussion for All Zones: Based on its needs and mission requirements, an organization may be unable to fund an alternate HPC system. Alternate processing sites may include processing sites at similar institutions via a Memorandum of Understanding (MOU) or utilizing the capabilities offered by cloud HPC service providers. An alternate processing site’s architecture and capabilities may differ from those of the primary site as long as it meets the organization’s mission requirements.

CP-9, System Backup Discussion for All Zones: Full data backup may be prohibitive given the volume of data and the fact that intermediate results often change and have little intrinsic value. HPC systems typically have multiple data storage systems, some of which are designated as temporary and explicitly not backed up. Priority should be given to configuration data and critical project data to ensure that the HPC system can be restored to a functional state.

AC-4, Information Flow Enforcement Supplemental Guidance for All Zones: End-user access connections between external systems and the HPC system should be routed through the Access Zone. Such connections may need to support large data flows while following proper flow enforcement rules. The performance impact on the data flow due to security measures (e.g., firewall packet inspection, intrusion detection and prevention systems) may need to be accounted for and sometimes mitigated by doing the inspection on the replicated data flow while leaving the original flow unimpeded if such packet duplication and parallel detection do not negatively affect the security posture. The controlled interfaces within an HPC system should enforce the internal information flow rules.

CA-9, Internal System Connections Discussion for All Zones: In this control, an HPC system with four zones is treated as a single unified system component. Communication connections between zones are outlined in SP 800-223 [1]. Within the Computing Zone, user jobs can set up connections between authorized processes running on different nodes. These connections are confined to the Computing Zone and can be classified as authorized internal connections.

SC-8, Transmission Confidentiality and Integrity Discussion for All Zones: An HPC system resides on an enterprise network or is connected to national networks or the internet. Internal connections refer to connections inside the HPC boundary, as defined in SP 800-223 [1]. If this control cannot be effectively implemented in practice, compensating controls may serve as an alternative. For instance, encrypting traffic over internal connections may not be practical at this time. Compensating controls may use private, non-routable networks (e.g., for Message Passing Interface [4] jobs). Internal traffic encryption may become feasible in the future as hardware and software capabilities evolve.

SC-8(1), Transmission Confidentiality and Integrity | Cryptographic Protection Supplemental Guidance for All Zones: No additional guidance is needed for transmissions over external connections. However, due to the nature of HPC, cryptographic protection may not be feasible for internal transmissions. See the discussions in SC-8 regarding alternative controls.

IA-1, Policy and Procedures Supplemental Guidance for All Zones: When developing policies and procedures, the unique requirements for accessing HPC systems should be properly considered and addressed.

Discussion for All Zones: HPC systems often have unique access requirements for the different zones. Organizations should consider access within the HPC system as single sign-on (i.e., the same identity is granted access to other resources within the HPC system) only when deemed appropriate.

IA-2(1), Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Privileged Accounts Supplemental Guidance for All Zones: Multi-factor authentication (MFA) should be required for access to the HPC system. However, once access is acquired, non-MFA connections among nodes within the HPC system may be permitted using the same identity at the same level of privilege as a form of single sign-on (SSO). Changing identities or the level of privilege within the system should require MFA. Based on an organization’s policy, access to different zones may require MFA again.

IA-2(2), Identification and Authentication (Organizational Users) | Multi-Factor Authentication to Non-Privileged Accounts Supplemental Guidance for All Zones: MFA should be required for access to the HPC system. However, once access is acquired, non-MFA connections among nodes within the HPC system may be permitted using the same identity. Changing identities within the system should also require MFA. Based on an organization’s policy, different zones may require MFA again.

IA-2(12), Identification and Authentication (Organizational Users) | Acceptance of PIV Credentials Supplemental Guidance for All Zones: If Personal Identity Verification (PIV) is used to grant access to the HPC Access Zone, it should not be required again for internal access within the system. See IA-2(2).

Discussion for All Zones: Due to the large and diverse user base of HPC systems, organizations that require PIV as access identification (ID) may also consider accepting alternate forms of MFA for external users.

IA-11, Re-Authentication Discussion for All Zones: Re-authentication could disrupt HPC user operations (e.g., interactive visualization, interactive debugging, multiple file downloads) and is often problematic due to the long-lived connections that exist in and between zones. This control is often tailored, and the time to re-authenticate is often set to infinity. Compensating controls (e.g., screen lock) can be introduced to mitigate the risks.

Supplemental Guidance for the Access Zone: This control should be carefully considered. See Sec. 3.3.

Discussion for the Access Zone: Login nodes often need to support long-lived sessions.

Discussion for the Management Zone: Management Zone access is typically limited to system administrators, and normal re-authentication should be enforced.

Supplemental Guidance for the Computing Zone: This control should be carefully considered. See Sec. 3.3.

Discussion for the Computing Zone: High-performance computing nodes need to support long-running jobs. Re-authentication will disrupt job execution.

Supplemental Guidance for the Data Storage Zone: This control must be enforced to ensure proper access for system administrators.

Discussion for the Data Storage Zone: HPC users access data, metadata, and file folders in the Data Storage Zone via file system clients, which make API calls to their corresponding file system servers for data retrieval. Users are typically not authorized to log in to the Data Storage Zone directly. Instead, they access it through service components. No additional authorization should be required once a user acquires initial access to the HPC system.

PE-11, Emergency Power Supplemental Guidance for the Computing Zone: Depending on the HPC system’s mission requirements, this control can either be enforced or tailored.

Discussion for the Computing Zone: The Computing Zone consumes a large volume of power. Hence, providing emergency power requires a significant investment. A job terminated due to a power interruption can restart without affecting its correctness. User communication should alert users if a job has been interrupted and may need to be rerun or restarted from checkpoint data.

PE-15, Water Damage Protection Discussion for All Zones: In addition to water being used in fire suppression systems, other cooling technologies may involve liquids that can damage equipment. The risks should be evaluated in the context of costs and potential damage, and a mitigation plan should be developed.

CM-7, Least Functionality Discussion for All Zones: Many HPC systems support broad missions and often allow users to develop and run their own software. The least functionality can be difficult to achieve due to diverse user cases. User isolation technologies should be used to limit the effect of adverse software. This includes limiting user activities to and within the Access Zone and Computing Zone, thereby separating user activity from the more privileged and protected Data Storage Zone and Management Zone.

CM-7(1), Least Functionality | Periodic Review Discussion for All Zones: Privileged and non-privileged users should understand the different functionalities of each zone. The time period for conducting the least functional control review should not exceed one year. Due to the sensitivity and frequent changes of the Access Zone and Management Zone, a more frequent review (e.g., quarterly) should be considered.

CM-7(2), Least Functionality | Prevent Program Execution Discussion for the Access Zone and Computing Zone: Many HPC systems cater to a variety of missions and often allow users to develop and run their own software. However, additional guidance and compensating controls may be necessary. For example, users should run their self-developed software in non-privileged mode, and it is important to consider implementing segregation among different programs and projects.

CM-7(5), Least Functionality | Authorized Software — Allow-by-Exception Supplemental Guidance for the Access Zone and Computing Zones: Depending on the mission of an HPC system, a user’s self-developed software may be allowed to run. It may be impractical to maintain a list of explicitly allowed software when the mission of the HPC system allows users to bring in, develop, or compile software, as the list would need to be updated continuously to track user actions.

CM-11, User-Installed Software Supplemental Guidance for the Access Zone and Computing Zones: User software is only accessible to individual users and their collaborators, while system-wide software can be used by all authorized users of a system. Additionally, software that requires special privileges to execute (e.g., software that needs access to privileged ports) is different from software that does not require any additional privileges. This control specifically pertains to non-privileged software that is used by a limited group of users. Users may be allowed to install and develop software that is necessary for their mission. They should create and manage this software in user space and regulate access for other users. Software that is installed system-wide is generally accessible to all users through a default path, while user-installed software is often accessed via specific paths. Users should not install software in the default path of any zone unless it complies with approved organizational policies.

Supplemental Guidance for the Management Zone and Storage Zone: Unprivileged user software should not be allowed in these zones.

SI-10, Information Input Validation Discussion for All Zones: Users may be allowed to develop and run their own software on HPC systems that are designed to support a wide range of missions. For software created by users, it is crucial to follow safe and secure coding practices, adhere to acceptable use agreements, and implement security measures (e.g., input validation).

AC-8, System Use Notification Supplemental Guidance for the Computing Zone, Management Zone, and Data Storage Zone: System use notifications (e.g., message of the day, legal banners) may be omitted at secondary login points at the organization’s discretion to improve job output efficiency. The login banner should be displayed upon initial entry to the HPC enclave.

Discussion for the Computing Zone, Management Zone, and Data Storage Zone: Displaying system use notifications (e.g., message of the day, legal banners) adds an additional burden on users because they need to remove these messages from job output. In an HPC system, once users have accepted a system’s use notification, further display in the other zones may be skipped at the organization’s discretion.

SI-3, Malicious Code Protection Supplemental Guidance for All Zones: This control may need to be tailored for different zones if it negatively impacts HPC performance or poses risks to the system’s mission.

Discussion for All Zones: Real-time process scanning is an effective approach for this control. Periodically scanning large file systems is often infeasible and negatively impacts storage system performance. Scanning shared resources across multiple compute nodes may also result in duplicate scans of the same data. The endpoints used by authorized users to access the HPC system are covered by organizational policies and must have malicious code protection installed to ensure that data is scanned before reaching the HPC system. Malicious code protection may require different approaches for the user space and the system space.

SI-4, System Monitoring Discussion for All Zones: In HPC environments, there are often large, high-speed data flows to and from the Access Zone. These flows can overwhelm standard enterprise network monitoring tools. Consider deploying tools and techniques developed for high-bandwidth environments. Internal networking may also require special consideration to collect the necessary information without negatively affecting the HPC system’s performance or mission. See AU-2 for additional information.

SI-7, Software, Firmware, and Information Integrity Supplemental Guidance for All Zones: This control only applies to system software, firmware, and information, not to user-installed software or user-managed information. System-wide installed software is accessible via the default path for all users, while software within specific domains is often accessible via domain-specific paths. See CM-11.

Discussion for the Data Storage Zone: The parallel file systems in the Data Storage Zone often contain vast amounts of data and software, making it infeasible to conduct regular integrity checks on the entire file system. Organizations should consider the impact of data integrity checks during architecture design and implementation.

CM-8(3), System Component Inventory | Automated Unauthorized Component Detection Discussion for All Zones: Due to the size and complexity of HPC systems, automated inventory management scanning by enterprise tools from outside the HPC environment may lead to undesirable performance penalties and/or incorrect results. Out-of-band or idle-time assessment of the hardware components should be considered as alternatives.

CM-12(1), Information Location | Automated Tools to Support Information Location Discussion for All Zones: While no additional guidance is needed, unintended impacts on the cost and performance of HPC systems should be considered during the control implementation.

RA-5, Vulnerability Monitoring and Scanning Supplemental Guidance for All Zones: Due to the size and complexity of HPC systems, strategies should be developed to minimize the scanning overhead and possible scanning impacts on HPC processes and operations.

Discussion for All Zones: Scanning policies can be customized for different zones. Shared filesystems should avoid repeated scanning by multiple nodes. Given the filesystem size, data change rate, and/or scanning system load, scanning shared filesystems may not be feasible. HPC systems may also contain identical computing and data storage nodes. Scanning one node may be sufficient in this scenario. If a diskless system is employed, scanning one copy of the image is also sufficient.

SC-15, Collaborative Computing Devices and Applications Discussion for All Zones: This control is generally not applicable to HPC systems.

SC-18, Mobile Code Discussion for All Zones: Mobile code is rarely used in HPC environments.

SC-4, Information in Shared System Resources Supplemental Guidance for the Computing Zone: Computer systems equipped with accelerators (e.g., GPUs) should ensure that user data on the accelerator is cleared before being reassigned to the next user. The accelerator vendor should be consulted for appropriate techniques.

PL-11, Baseline Tailoring Supplemental Guidance for All Zones: Using this overlay implies tailoring the selected baseline. Additional tailoring is possible as governed by organizational requirements.

AT-1, Policy and Procedures Discussion for All Zones: Organizations are encouraged to develop HPC-specific documentation and training that capture their HPC system’s unique characteristics.

AT-3, Role-Based Training Supplemental Guidance for All Zones: HPC users and system administrators should receive HPC-specific training tailored to their roles. The specific training will depend significantly on the details of the HPC system and its mission.

Discussion for All Zones: The complexity and scale of HPC systems require skilled administrators and users. Users, administrators, and other organizational roles require additional training to facilitate communication between these specialized roles.

CA-2(1), Control Assessments | Independent Assessors Discussion for All Zones: Due to the unique characteristics of HPC systems, assessors who are familiar with these systems will yield more effective assessment results.

MA-6, Timely Maintenance Discussion for All Zones: The time period threshold parameters defined by the organization may vary based on the criticality and impact of maintenance on the components in HPC systems, including software.

SI-2, Flaw Remediation Discussion for All Zones: The organization-defined timing of fixing flaws may need special consideration for different HPC zones. For example, applying patches may be limited by vendor update schedules and the timing of integrating dependency patches from third-party sources. Additionally, both the Computing Zone and Data Storage Zone support long-running jobs that may exceed the organization-specified patch window, which requires special handling.

SI-5, Security Alerts, Advisories, and Directives Discussion for All Zones: HPC-specific alerts may not be widely disseminated by default. HPC operators should subscribe to vendor-specific channels to receive relevant alerts about their systems.

CM-2(2), Baseline Configuration | Automation Support for Accuracy and Currency Discussion for All Zones: Due to the complexity of HPC systems, baseline configuration automation support is important and may require professional resolution support.

CM-3(2), Configuration Change Control | Testing, Validation, and Documentation of Changes Discussion for All Zones: Testing should be specific to the requirements of individual zones. For example, the Computing Zone should emphasize performance; the Access Zone should emphasize authentication and authorization; the Management Zone should emphasize a continuous monitoring capability; and the Data Storage Zone should emphasize data security and access performance. While a testing environment is important, it is often impractical to have a testing environment at the same scale as the production system or with the same specialized hardware components.

CM-9, Configuration Management Plan Discussion for All Zones: The system configuration of a large-scale, complex HPC system is essential. A detailed system configuration plan is needed to describe the tight dependence among the zones and the components of the HPC system.

SC-5, Denial-of-Service Protection Discussion for All Zones: Denial-of-service (DoS) detection methods for the nodes in the Access Zone are crucial. A denial of service can be caused by malicious attacks or a user erroneously using a system. Proper guidance and training should be provided to users to raise their awareness of the potential impacts of incorrect system usage. HPC system operators are encouraged to monitor the system and provide feedback to users.

SC-28, Protection of Information at Rest Discussion for All Zones: For HPC systems, different protection approaches may be employed for various storage systems in different zones, accounting for performance impacts and security risks.

AC-17(3), Remote Access | Managed Access Control Points Discussion for All Zones: Due to their size and scale, HPC systems may quickly overwhelm the planned internet connection capacity. Organizations with Trusted Internet Connection (TIC) requirements should work closely with their TIC Access Provider (TICAP) to address the significant strains that HPC systems can place on organizational services.

AC-18, Wireless Access Discussion for All Zones: Although users can connect wirelessly to the Access Zone, wireless access is not typically part of the HPC system.

AC-20, Use of External Systems Discussion for All Zones: HPC systems typically have a far more permissive posture and descriptive process regarding the use of external systems than other systems in the organization. This control is often delegated to the team responsible for the organization’s infrastructure and external connectivity. Organizations should prepare for the detailed implementation of this control and corresponding enhancement controls to account for user trust, permissions, roles, and risks.

AC-20(2), Use of External Systems | Portable Storage Devices — Restricted Use Discussion for All Zones: HPC systems typically have data transfer systems, which are preferred over portable storage devices. When required, connecting portable storage devices to HPC systems must follow organization-approved processes.

This HPC security overlay is based on the moderate control baseline in SP 800-53 with one additional control. The overlay includes 288 security controls, of which 60 are tailored with supplemental guidance and/or discussion.

For many users, this overlay can serve as a guideline to secure their HPC systems. If necessary, users can further customize this security framework to meet their specific needs.

[1] Guo Y, Chandramouli R, Wofford L, Gregg R, Key G, Clark A, Hinton C, Prout A, Reuther A, Adamson R, Warren A, Bangalore P, Deumens E, Farkas C (2024) High-Performance Computing Security: Architecture, Threat Analysis, and Security Posture. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP)

NIST SP 800-223. https://doi.org/10.6028/NIST.SP.800-223

[2] Joint Task Force (2020) Security and Privacy Controls for Information Systems and

Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53r5. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5 [3] Joint Task Force (2020) Control Baselines for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-53B. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53B

[4] Office of Management and Budget (2021) Improving the Federal Government’s

Investigative and Remediation Capabilities Related to Cybersecurity Incident. (The White House, Washington, DC), OMB Memorandum M-21-31, August 27, 2021. Available at https://bidenwhitehouse.archives.gov/wp-content/uploads/2021/08/M-21-31-Improving-the-Federal-Governments-Investigative-and-Remediation-Capabilities-Related-to-Cybersecurity-Incidents.pdf [5] Cybersecurity and Infrastructure Security Agency (2022) Guidance for Implementing M-21-31: Improving the Federal Government’s Investigative and Remediation Capabilities. Available at https://www.cisa.gov/sites/default/files/2023-02/TLP%20CLEAR%20-%20Guidance%20for%20Implementing%20M-21-31_Improving%20the%20Federal%20Governments%20Investigative%20and%20Remedi ation%20Capabilities_.pdf

[6] Free Software Foundation (2016) GNU Screen. Available at https://www.gnu.org/software/screen/ [7] tmux. Available at https://github.com/tmux/tmux/wiki