The following FAQs provide additional information on the guidance.
A security measure might not be relevant for a particular situation based on the nature of the software deployment or other factors. If a particular security measure cannot be implemented, other security measures could be identified and implemented to mitigate the risk and achieve the outcome that the missing security measure was intended to address. Agencies are still expected to apply risk management activities as part of their overall cybersecurity programs.
Potentially. However, all of the security measures for EO-critical software are anticipated to apply to all types of EO-critical software in all deployments.
CISA, GSA’s FedRAMP program, and OMB are currently developing a federal cloud-security strategy and cloud-security technical reference architecture documentation in support of Section 3 of the EO. The security measures for using EO-critical software could be applied to cloud-based environments by cloud service providers.
Yes, see NIST’s C-SCRM project website for links to all the resources. An example is the Federal C-SCRM Forum, which NIST hosts; the Forum fosters collaboration and the exchange of C-SCRM information among federal agencies to improve the security of federal supply chains. Examples of NIST C-SCRM guidance include SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations and SP 800-161 Rev. 1 (Draft), Cyber Supply Chain Risk Management Practices for Systems and Organizations.
Section 3 of the EO directs each federal agency to plan to implement zero trust architecture. All of the security measures for EO-critical software defined in this guidance are also components of a zero trust architecture, although by no means are they complete. Agencies developing plans for migrating to zero trust architecture can incorporate the security measures for EO-critical software use into those plans. For more information on zero trust architecture, see the following Federal Government resources:
Agencies should continue to take risk-based approaches for protecting data, and thus should only apply the types of protection that will reduce risk for a particular scenario. For example, protecting the confidentiality of publicly available information typically will not reduce risk, and thus would not be necessary.
Verifier impersonation-resistant authentication protocols and credentials ensure that when a user or administrator attempts to connect to EO-critical software or an EO-critical software platform over a network, both parties (the person and the platform) are legitimate. Verifier impersonation resistance helps prevent people from having their credentials stolen by phishing attacks, and also helps prevent attackers from using stolen authentication information to impersonate a user or administrator. There are several ways to achieve verifier impersonation resistance; an example of a verifier impersonation-resistant protocol is client-authenticated Transport Layer Security (TLS). See Section 5.2.5 of NIST SP 800-63B for more information.
Additional information is available at this webpage. It includes a set of FAQs that provide more details and context about EO-critical software.
Yes, the list below includes the first sentence of each security measure. The summary is intended to improve understanding of the security measures and is not a substitute for the formal definition of the security measures for EO-critical software use in the previous table, which contains additional details for some security measures and provides informative references for all security measures.
Objective 1: Protect EO-critical software and EO-critical software platforms from unauthorized access and usage.
Objective 2: Protect the confidentiality, integrity, and availability of data used by EO-critical software and EO-critical software platforms.
Objective 3: Identify and maintain EO-critical software platforms and the software deployed to those platforms to protect the EO-critical software from exploitation.
Objective 4: Quickly detect, respond to, and recover from threats and incidents involving EO-critical software and EO-critical software platforms.
Objective 5: Strengthen the understanding and performance of humans’ actions that foster the security of EO-critical software and EO-critical software platforms.