NIST 800-53 REV 5 • SYSTEM AND SERVICES ACQUISITION
SA-8(23) — Secure Defaults
Implement the security design principle of secure defaults in {{ insert: param, sa-08.23_odp }}.
Supplemental Guidance
The principle of secure defaults states that the default configuration of a system (including its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that follow a "deny unless explicitly authorized" strategy. The initial configuration aspect of this principle requires that any "as shipped" configuration of a system, subsystem, or system component does not aid in the violation of the security policy and can prevent the system from operating in the default configuration for those cases where the security policy itself requires configuration by the operational user. Restrictive defaults mean that the system will operate "as-shipped" with adequate self-protection and be able to prevent security breaches before the intended security policy and system configuration is established. In cases where the protection provided by the "as-shipped" product is inadequate, stakeholders assess the risk of using it prior to establishing a secure initial state. Adherence to the principle of secure defaults guarantees that a system is established in a secure state upon successfully completing initialization. In situations where the system fails to complete initialization, either it will perform a requested operation using secure defaults or it will not perform the operation. Refer to the principles of continuous protection and secure failure and recovery that parallel this principle to provide the ability to detect and recover from failure. The security engineering approach to this principle states that security mechanisms deny requests unless the request is found to be well-formed and consistent with the security policy. The insecure alternative is to allow a request unless it is shown to be inconsistent with the policy. In a large system, the conditions that are satisfied to grant a request that is denied by default are often far more compact and complete than those that would need to be checked in order to deny a request that is granted by default.
Practitioner Notes
Secure defaults means that systems should be secure out of the box. The default configuration should be the most secure configuration, requiring administrators to explicitly open things up rather than lock things down.
Example 1: When deploying new systems, start from a hardened baseline (DISA STIG, CIS Benchmark) where everything is locked down by default. Then selectively enable only the features and services actually needed. This is more secure than starting with defaults and trying to harden after the fact.
Example 2: In M365, new tenants come with a set of default security settings (Security Defaults). Review Microsoft's Secure Score recommendations immediately and implement the top-priority items before users start using the environment. Block legacy authentication, enable MFA, and disable external sharing by default.