712-50 Question 326
Single answerOS Hardening (5 questions)A global financial services company is preparing a fleet of Linux-based application servers for a new internet-facing customer platform. The CISO has mandated OS hardening before production go-live because the last audit found inconsistent builds, unnecessary services, and weak local account controls. Operations leadership is concerned that overly aggressive hardening could disrupt application support and incident response. As the security executive overseeing the hardening standard, which action is the MOST effective first step to reduce attack surface while preserving operational stability across the environment?
- A
Adopt a secure baseline based on a recognized benchmark, test it in a staging environment, and disable or remove only non-required services, packages, and ports before broad deployment
- B
Immediately disable all network services not explicitly approved by the security team, then allow application teams to submit exceptions after production deployment
- C
Require administrators to change the root password weekly and prohibit all remote administrative access to ensure the servers are hardened
- D
Install endpoint protection software on every server and defer OS-level hardening changes until after the platform is in production
Show answer and explanation
Correct answer: A
Explanation
The strongest executive decision is to establish and validate a standard hardened build before deployment. For OS hardening, the priority is to reduce attack surface in a controlled, repeatable way: standardize configurations, remove unnecessary components, restrict exposed services, harden authentication and privilege use, and verify compatibility through testing. Recognized guidance includes CIS Benchmarks, DISA STIGs, NIST SP 800-123 (Guide to General Server Security), and NIST SP 800-53 controls such as CM-6 (Configuration Settings), CM-7 (Least Functionality), SI-2 (Flaw Remediation), and AC-6 (Least Privilege). From a CCISO perspective, the key is balancing security objectives with business continuity by implementing policy-driven baselines, staged testing, exception management, and governance over configuration drift rather than ad hoc hardening changes.
- A. Correct.
This is the best answer because it reflects a risk-based, operationally sound hardening approach. Using a recognized baseline such as the CIS Benchmarks or DISA STIGs provides consistency and auditability. Validating the baseline in staging helps identify compatibility issues before production impact. Disabling or removing unnecessary services, packages, and exposed ports directly reduces attack surface while preserving required business functionality. This aligns with established secure configuration management practices in NIST SP 800-123 and NIST SP 800-53 controls such as CM-6 and CM-7.
- B. Incorrect.
This is plausible but not the most effective first step because it bypasses testing and formal baseline development. Disabling services first in production can create outages, break dependencies, and generate avoidable emergency exceptions. Hardening should be governed through a controlled baseline and change process, not by reactive shutdowns. The misconception here is that speed alone improves security; in practice, untested hardening can increase operational risk.
- C. Incorrect.
This is incorrect because frequent password changes for root do not address the primary hardening problem of inconsistent builds and unnecessary services. Prohibiting all remote administrative access may also hinder legitimate administration and incident response unless a controlled alternative exists. Modern hardening guidance typically emphasizes limiting direct root use, enforcing least privilege, central authentication, logging, and using secure remote administration methods rather than relying mainly on password rotation.
- D. Incorrect.
This is incorrect because endpoint protection is a complementary detective/preventive control, not a substitute for OS hardening. If unnecessary services, packages, weak configurations, and open ports remain in place, the underlying attack surface is still exposed. Deferring hardening until after production leaves the organization unnecessarily vulnerable during a critical deployment period. The misconception is treating security tooling as equivalent to secure configuration.