712-50 Question 317
Single answerUnderstand various system-engineering practicesA global manufacturer is replacing several legacy plant-floor applications with a new integrated platform that will connect operational technology (OT) systems, cloud analytics, and third-party maintenance services. The CIO wants rapid deployment, while the board has directed the CISO to reduce systemic risk and avoid costly redesign later in the program. During planning, engineering teams propose handling security validation after development is complete to prevent schedule delays. Which action should the CISO take FIRST to align with sound system-engineering practices and improve long-term security outcomes?
- A
Require a systems engineering approach that defines security requirements, trust boundaries, and lifecycle assurance activities at the architecture and design stages
- B
Approve the plan to defer security testing until user acceptance testing, because earlier testing would create unnecessary rework before features stabilize
- C
Focus the program on selecting a best-of-breed security toolset first, since tooling decisions will drive architecture and reduce integration complexity
- D
Accept the proposed design if the vendors can provide contractual statements that their components are secure and compliant with industry standards
Show answer and explanation
Correct answer: A
Explanation
The best first action is to embed security into the system-engineering lifecycle from the outset. In CCISO-level practice, this means influencing governance and architecture decisions early so that security is engineered into requirements, design, integration, verification, deployment, and maintenance. This is particularly important in hybrid environments where OT, cloud platforms, and third-party connectivity create complex interdependencies and attack paths.
Relevant best practices are consistent with NIST SP 800-160 Volume 1 on Systems Security Engineering, which emphasizes applying security across the system development life cycle, and NIST's Secure Software Development Framework (SP 800-218), which promotes early definition of security requirements and design review. These sources support a shift-left approach: identify mission needs, define security outcomes, establish trust boundaries, perform threat-informed design analysis, and plan assurance activities before implementation is complete. From an executive perspective, this approach reduces total cost of ownership, lowers redesign risk, and improves resilience more effectively than relying on late testing, standalone tools, or vendor attestations alone.
- A. Correct.
Correct. Sound system-engineering practice integrates security early across the system lifecycle rather than treating it as a final checkpoint. For a complex environment spanning OT, cloud, and third parties, the CISO should ensure security requirements, assumptions, trust boundaries, interface risks, and assurance activities are defined during architecture and design. This reflects secure-by-design and systems security engineering principles, reducing the likelihood of expensive retrofits and unmanaged emergent risk across interconnected components.
- B. Incorrect.
Incorrect. Deferring security validation until user acceptance testing is a common but flawed waterfall-era pattern that increases cost and risk. By that stage, architectural weaknesses, insecure interfaces, and poor trust-boundary decisions are harder and more expensive to fix. Earlier activities such as threat modeling, security requirements definition, and design review are intended to prevent exactly this type of late-stage discovery.
- C. Incorrect.
Incorrect. Tools support architecture; they do not replace system-engineering discipline. Selecting security tools before establishing system context, data flows, trust relationships, and security requirements can result in fragmented controls and poor integration. This option reflects the misconception that technology procurement alone can compensate for weak engineering practices.
- D. Incorrect.
Incorrect. Vendor assurances and compliance claims can be useful inputs, but they are not sufficient substitutes for the organization's own systems engineering, risk analysis, and assurance processes. Secure components can still create insecure systems when integrated improperly, especially in environments with OT, cloud connectivity, and external service providers.