712-50 Question 316
Single answerUnderstand various system-engineering practicesA global manufacturer is replacing several legacy production-planning applications with a single cloud-hosted platform that will integrate with on-premises ERP systems, supplier portals, and factory-floor devices. The CIO wants the program delivered quickly, while the board has asked the CISO to ensure security is built in rather than added during final testing. The development teams use agile methods, and multiple vendors will contribute components and APIs. Which action should the CISO prioritize FIRST to align the program with sound system-engineering practices while reducing the risk of costly redesign later?
- A
Require a secure system development life cycle (SSDLC) with security architecture reviews, threat modeling, and security requirements baselined during design
- B
Delay formal security involvement until user acceptance testing so the business can validate functionality before security constraints are imposed
- C
Rely on the cloud provider's native security controls and obtain its compliance reports instead of performing internal architecture and design reviews
- D
Focus the security team on post-deployment vulnerability scanning and incident response planning because agile projects change too frequently for up-front security engineering
Show answer and explanation
Correct answer: A
Explanation
The best answer is to establish an SSDLC with security architecture reviews, threat modeling, and defined security requirements early in design. This is the most effective first step because system-engineering practices are about shaping the system from the outset: defining requirements, analyzing interfaces and dependencies, understanding trust boundaries, and ensuring security is engineered into the architecture. In a modernization program involving cloud services, on-premises ERP, supplier integrations, and factory-floor devices, early engineering rigor is critical to avoid design flaws that are expensive to fix later.
This aligns with recognized guidance such as NIST SP 800-160 Volume 1, which emphasizes systems security engineering across the lifecycle; NIST SP 800-218 (Secure Software Development Framework), which calls for preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities; and common secure-by-design principles endorsed by industry and government guidance. From a CCISO perspective, the CISO should champion governance and engineering practices that integrate security into business-led transformation rather than relying primarily on late-stage testing or inherited provider assurances.
- A. Correct.
This is correct because it applies core system-engineering discipline early in the lifecycle, when architectural decisions, trust boundaries, integration methods, and security requirements can still be shaped at lower cost. For a complex, multi-vendor, cloud-integrated environment, baselining security requirements and performing threat modeling during design helps identify issues such as insecure API trust relationships, weak segregation between operational technology and enterprise systems, authentication gaps, and data flow risks before they are embedded in the solution. This reflects well-established secure engineering practices in NIST SP 800-160 and NIST SP 800-218, which emphasize integrating security engineering and secure software development throughout the lifecycle rather than treating security as a late-stage check.
- B. Incorrect.
This is incorrect because postponing security until user acceptance testing is contrary to sound system-engineering practice. By that stage, core design decisions are largely fixed, making remediation more expensive and disruptive. A candidate might choose this because it seems to support delivery speed and business validation, but in practice it increases rework, project delays, and residual risk. Security constraints do not need to block agile delivery when they are translated into early requirements, design patterns, and acceptance criteria.
- C. Incorrect.
This is incorrect because cloud provider controls and compliance attestations are only one part of the risk picture. In a shared responsibility model, the organization remains accountable for secure architecture, identity design, integration security, data classification, API protection, and vendor component risks. Compliance reports cannot replace internal engineering analysis of how the solution is designed and operated. Someone might select this option because using cloud-native controls is a good practice, but relying on them instead of conducting architecture and design reviews is insufficient.
- D. Incorrect.
This is incorrect because vulnerability scanning and incident response are important operational activities, but they do not substitute for secure system engineering. Post-deployment testing tends to find implementation flaws after architectural weaknesses have already been built into the system. The misconception here is that agile delivery makes up-front engineering impractical; in reality, agile environments still require early security architecture, threat modeling, and iterative control validation integrated into sprints and release planning.