Systems Security Engineering Foundations practice questions

Patch Management Policy

Why it fails: A patch management policy defines operational workflows for remediating software vulnerabilities after deployment, making it useless for capturing foundational security missions during early design phases. It appears tempting because it establishes proactive security constraints and governance frameworks, and it would be the correct choice when organisations need to operationalise vulnerability remediation timelines and testing procedures for production systems.

System Security Plan (SSP)

Why it fails: The SSP is the primary document detailing security implementation and goals.

Incident Response Plan

Why it fails: An Incident Response Plan fails to satisfy this requirement because it dictates operational containment, forensic preservation, and recovery workflows following a confirmed compromise rather than establishing foundational security goals during architectural inception. It is tempting because it represents a primary governance artifact that organizations must draft early to satisfy compliance mandates. This document becomes the correct choice when preparing an enterprise to detect, analyze, and contain active operational threats and security breaches.

Vulnerability Assessment Report

Why it fails: A vulnerability assessment report evaluates an operational or nearly completed system to identify known flaws, misconfigurations, and weakness patches that require remediation. This option is tempting because it represents a foundational security document produced during system development or maintenance. However, it fails this scenario because it focuses on discovering technical implementation defects rather than establishing the high-level security-relevant mission goals and constraints required during the earliest lifecycle stages. Such a report would be the correct choice later in the lifecycle when testing an active or staged environment against a vulnerability database.

Recovery Planning (RC.RP)

Why it fails: Recovery planning focuses on restoring systems after a disruptive incident rather than the foundational engineering of security controls during the initial asset discovery phase. While this option addresses the 'Recover' function of the NIST framework, it is tempting because organisations often integrate security engineering requirements into their broader disaster recovery documentation. It would be the correct choice if the question asked which process ensures business continuity and service resilience following a catastrophic failure or security breach.

Access Control (PR.AC)

Why it fails: Access Control (PR.AC) addresses runtime identity verification and permission enforcement, which fails the requirement to support engineering-level design processes within the Identify function. Practitioners often select this category when focusing on operational user provisioning and boundary defense during the Protect stage. It becomes the correct choice when evaluating policies that govern logical access to assets and facilities during runtime execution rather than architectural risk identification.

Detection Processes (DE.DP)

Why it fails: Detection Processes (DE.DP) focus on the continuous monitoring of information systems to identify anomalous activity, whereas the Identify function prioritises the foundational understanding of organisational risk and asset management. This option appears relevant because security engineering informs monitoring requirements; however, it belongs to the Detect function rather than the Identify function. You would select this category when configuring alerts or log aggregation tools, such as those integrated with Microsoft Entra ID, to ensure timely notification of potential security incidents within the operational environment.

Sales and Marketing Specification

Why it fails: Commercial promotional materials focus on product positioning and revenue generation rather than rigorous technical verification, making them irrelevant to the Common Criteria (ISO/IEC 15408) framework which relies on formal Security Targets and Protection Profiles to scientifically evaluate IT security functionality. This distractor is tempting because vendors frequently publish extensive commercial data sheets detailing product capabilities to prospective buyers during procurement, which would be the correct documentation to consult when evaluating budgetary alignment, licensing tiers, and high-level enterprise feature availability before initiating a formal technical evaluation.

Employee Training Records

Why it fails: Employee training records document personnel completion of operational policies, yet they fail because ISO/IEC 15408 evaluates technical product functionality and implementation trustworthiness rather than human administrative compliance. This distractor is tempting because training records are vital components of broader organisational governance frameworks, such as ISO/IEC 27001, where they would be the correct choice to prove staff awareness and competency during operational audits.

The administrator configures the firewall rules

Why it fails: Configuring firewall rules is a standard administrative task that falls within the scope of a system administrator’s authorised role, meaning it does not inherently violate separation of duties unless the individual also possesses the authority to approve those changes or audit the logs. This option appears relevant because firewall management is a critical security function within the Trusted Computing Base, and it would be the correct choice if the question asked to identify a primary administrative responsibility for securing network traffic flow.

Two administrators are required for root access

Why it fails: Requiring two administrators for root access implements dual-control authorisation rather than violating the separation of duties principle. Dual-control is actually a security best practice designed to prevent unilateral privilege abuse by ensuring critical administrative actions require joint authorisation from distinct individuals. While tempting because it involves administrative accounts and security partitioning, it addresses multi-person authorisation rather than assigning conflicting responsibilities across different roles, which is the specific structural failure evaluated by the audit regarding the Trusted Computing Base.

The security team monitors logs

Why it fails: Assigning the security team to monitor logs fulfils independent oversight rather than creating a dangerous operational overlap, which makes this choice tempting because logging and monitoring are standard defensive controls for verifying system integrity within a Trusted Computing Base architecture. This duty does not violate separation of duties because security analysts lack the authorisation to modify system configurations or bypass access controls they monitor. In an audit scenario, this separation between operational execution and independent review represents a correctly implemented security control, whereas a violation requires a single user to possess conflicting capabilities such as both authorising transactions and reconciling them.

No Write Down

Why it fails: Enforcing the "No Write Down" rule permits a subject at a high integrity level to modify data at a lower integrity level, which directly violates the Biba integrity model's invocation property by risking the contamination of trustworthy information with untrustworthy modifications. This rule is tempting because it forms a foundational axiom in confidentiality-focused frameworks like the Bell-LaPadula model, where it prevents sensitive information from leaking downwards to lower clearance levels; consequently, it would be the correct choice when designing a system primarily intended to protect data secrecy rather than system reliability and data correctness.

No Read Up

Why it fails: This is a Bell-LaPadula rule, not Biba.

NIST SP 800-160 Volume 1 Systems Security Engineering

Why it fails: SP 800-160 Vol. 1 offers systems security engineering guidance and principles for designing trustworthy systems. It is valuable for engineering activities but does not contain the authoritative control catalog that the RMF uses for control selection and traceability.

NIST SP 800-30 Revision 1 Guide for Conducting Risk Assessments

Why it fails: SP 800-30 focuses on risk assessment methodology, including threat identification and likelihood determination. It informs risk-based decisions but does not provide the control baseline or catalog required for selecting and tracing security requirements in the RMF Select step.

NIST SP 800-37 Revision 2 Risk Management Framework

Why it fails: SP 800-37 is the overarching RMF process guide; it describes the steps and tasks but does not contain the detailed control catalog needed to select specific controls. While essential for process guidance, it is not the primary source for deriving individual security controls for a system.

No read down (simple integrity property).

Why it fails: No read down is a rule from the Biba integrity model, which prevents a subject from reading lower integrity data. Bell-LaPadula focuses on confidentiality, not integrity. The simple integrity property is not part of Bell-LaPadula. This option mixes models, and thus is incorrect for a Bell-LaPadula system.

No write up (*-property).

Why it fails: The *-property (star property) of Bell-LaPadula actually states no write down: a subject cannot write to a lower security level. No write up is not a rule of Bell-LaPadula; that concept belongs to the Biba integrity model. Confusing the two models is a common mistake. Here, the correct rule is no read up, not no write up.

No write down (simple security property).

Why it fails: No write down is indeed a rule of Bell-LaPadula, but it is the *-property (star property), not the simple security property. The simple security property is no read up. The option incorrectly attributes no write down to the simple security property. While the rule itself exists, the association is wrong, making this option technically inaccurate.

Develop a system security plan that documents the implemented controls and their configuration settings.

Why it fails: A system security plan documents how controls are implemented and how the system is operated, but it is a descriptive artifact, not an analytical technique for confirming that the security requirements are complete and correctly allocated. It is produced after design decisions are made and does not by itself establish correctness of the control set.

Conduct a vulnerability assessment of the system after it is deployed to identify any missing security controls.

Why it fails: A vulnerability assessment identifies weaknesses in a deployed system and is a detection activity, not a requirements-engineering method. It cannot ensure that the security controls are correct and complete before fielding because it occurs after deployment and only finds known weaknesses rather than verifying requirement coverage.

Conduct a security control assessment to verify that the implemented controls meet the specified security requirements.

Why it fails: A security control assessment evaluates implemented controls against requirements, but it occurs after implementation and does not ensure the control set itself is correct and complete during requirements definition. The question asks how the ISSE ensures the controls are correct and complete before fielding, which is a requirements-engineering activity, not post-implementation testing.

It must be able to enforce both discretionary and mandatory access control policies simultaneously.

Why it fails: A reference monitor can enforce various policies, but the question asks for the design property that makes it effective. Simultaneous enforcement of discretionary and mandatory policies is a policy capability, not the fundamental property that ensures the monitor cannot be bypassed or tampered with.

It must be small enough to be thoroughly analyzed and tested.

Why it fails: While a small reference monitor is easier to analyze, the three essential properties are that it mediates all accesses, is tamperproof, and is small enough to be verified. Smallness alone is not sufficient; a small monitor that does not mediate every access or can be bypassed would not provide the required enforcement.

It must log all access attempts to an immutable audit trail for later review.

Why it fails: Auditing is an important supporting function, but it is not one of the defining properties of a reference monitor. A reference monitor that logs accesses but does not mediate every access or is not tamperproof would still fail to enforce the policy, so logging alone does not satisfy the effectiveness requirement.

It must log all access attempts to a write-once audit trail for later review

Why it fails: Auditing records activity for accountability and after-the-fact detection, but it does not prevent the prohibited Secret-to-Unclassified flow in the first place. A reference monitor that only logs would allow the violating write to succeed and merely document it. The mandatory flow restriction demands prevention through complete mediation, not detective logging, so an audit trail alone does not meet the requirement.

It must authenticate all users with multifactor credentials before granting any access

Why it fails: Strong authentication establishes identity but does not constrain how authenticated subjects may move information between sensitivity levels. An authenticated Secret-cleared user could still write Secret data into an Unclassified object unless mandatory flow rules are enforced. Authentication is a prerequisite for access control, not the flow-enforcement guarantee the reference monitor must provide, so it does not satisfy the covert-channel-resistant requirement.

It must encrypt all data at rest using FIPS 140-3 validated modules

Why it fails: Encryption at rest protects confidentiality of stored data but does not enforce mandatory information flow direction. A Secret file could still be decrypted and written to an Unclassified object if the access control policy is not mediated. The reference monitor's purpose is to enforce the mandatory policy on every access, not to provide cryptographic protection of storage, so this property does not satisfy the flow restriction requirement.

Relying solely on perimeter authentication

Why it fails: Relying solely on perimeter authentication creates a single point of failure that violates the principle of layered security, allowing an adversary who bypasses the initial gateway unrestricted lateral movement throughout the internal network. Administrators are often tempted by this approach because it centralises access control at the network edge, thereby reducing administrative overhead and simplifying initial system integration. Such a centralised perimeter model would be appropriate for small, isolated networks with strictly homogeneous internal assets where internal threat actors are absent and resource constraints preclude granular micro-segmentation.

Maximizing system throughput by minimizing encryption

Why it fails: Prioritising maximum throughput by stripping away encryption directly undermines Defense in Depth by removing cryptographic confidentiality controls from data layers, creating a single point of catastrophic failure if perimeter defenses are breached. This approach is tempting because minimising computational overhead is a standard performance optimisation technique when engineering high-frequency trading platforms or real-time media streaming services where low latency and maximum throughput are operational requirements.

Implementing a single high-availability firewall

Why it fails: Relying on a single high-availability firewall violates the principle of defence in depth because a solitary security boundary creates a single point of failure and lacks layered redundancy. This option is tempting because such devices provide vital perimeter traffic filtering, network segmentation, and stateful inspection. Consequently, a redundant firewall deployment *would* be the correct choice when establishing a resilient network perimeter to protect against external intrusion at the edge of an enterprise network.

Detailed Design

Why it fails: Detailed Design occurs too late in the V-Model to establish high-level security functional requirements, as this phase focuses on translating component specifications into concrete logic rather than defining overarching architectural security constraints. This stage is tempting because engineers frequently map specific security controls to system components here, and it would be the correct choice if the task involved refining cryptographic algorithms or access control parameters for individual software modules rather than tracing architectural requirements.

System Integration and Testing

Why it fails: Defining security functional requirements during system integration and testing occurs far too late in the Systems Engineering V-Model, because discovering architectural misalignment at this stage prevents proper traceability and forces costly rework. This phase is tempting because engineers often validate security controls empirically against assembled hardware and software components. It would be the correct choice if the objective were to execute dynamic verification, vulnerability scanning, or penetration testing against a fully realised build to confirm that implemented security functions meet the specified functional baseline.

Operational Maintenance

Why it fails: Operational Maintenance occurs long after the system architecture has been established, meaning defining security functional requirements here would break traceability and arrive too late to influence foundational design. This stage is tempting because security controls must continuously be evaluated, patched, and updated as threats evolve post-deployment. It would be the correct choice if the question asked when to apply vulnerability management, patch lifecycles, or configuration audits to a live production environment.

DAST (Dynamic Application Security Testing)

Why it fails: Dynamic Application Security Testing (DAST) cannot inspect proprietary code during the 'Build' stage because it evaluates software externally from a black-box perspective, requiring a fully compiled and running application in a staging environment. DAST is tempting because it effectively automates runtime vulnerability detection, making it the correct choice for assessing deployed applications against live environmental threats during later release or staging phases rather than source-level code analysis within the pipeline.

IDS (Intrusion Detection System)

Why it fails: An Intrusion Detection System monitors network traffic or system logs for malicious activity and operational anomalies at runtime, meaning it cannot statically analyse source code during a CI/CD build stage. It is tempting because it provides automated security monitoring, which makes it the correct choice for detecting active network intrusions and live exploitation attempts within a deployed production environment rather than preventing software flaws in proprietary code repositories.

SIEM (Security Information and Event Management)

Why it fails: A Security Information and Event Management tool analyses runtime logs and security events generated across an infrastructure to detect active threats and policy violations, making it completely ineffective for statically scanning source code during the build stage. However, it is tempting because it performs automated security monitoring, which is a core component of a mature DevSecOps pipeline. A SIEM would be the correct choice later in the deployment lifecycle when collecting telemetry and correlating real-time log data from production environments to identify active security incidents.

Forcibly inject TLS 1.3 into the binary

Why it fails: Binary patching risks destabilising legacy software by introducing memory corruption or breaking hardcoded dependencies, which violates the integrity requirements of the engineering process. This approach is tempting when dealing with proprietary, closed-source legacy binaries where the source code is unavailable and standard wrapper solutions fail. In such isolated scenarios, binary instrumentation serves as a last-resort method to patch critical vulnerabilities or inject security hooks into immutable applications when no other configuration-based or architectural remediation path exists.

Ignore the finding because it is a legacy system

Why it fails: Dismissing architectural gaps simply because assets are outdated creates severe cryptographic blind spots that violate comprehensive threat modeling principles. Practitioners are often tempted to defer remediation when dealing with legacy constraints where native software modifications are economically unviable or technically impossible. Such an approach would be appropriate only when formal risk acceptance has been documented through an enterprise governance framework, accompanied by compensating network controls such as reverse proxy terminators or TLS termination gateways that isolate the vulnerable endpoint from untrusted networks.

Immediately shut down the system

Why it fails: Abruptly halting operations completely disregards business continuity requirements and fails to integrate the legacy system into the broader enterprise architecture. This heavy-handed measure is designed for critical incident containment where active data exfiltration or catastrophic kernel compromise threatens the entire organisational perimeter. It represents an emergency containment procedure for active security breaches rather than a measured engineering lifecycle response to an unencrypted protocol dependency.

Developing incident response plans

Why it fails: Developing incident response plans focuses on operational readiness and post-compromise recovery procedures rather than the foundational engineering of system architectures. This choice is tempting because operational resilience is a core governance goal within the broader NIST framework, and such plans would indeed be required later during the deployment and operations phases. However, the system design phase mandates embedding active technical controls—such as cryptographic mechanisms and least-privilege boundaries—directly into the component architecture to enforce confidentiality and integrity proactively, rather than preparing reactive measures for when those structural boundaries inevitably fail.

Performing final penetration testing

Why it fails: Final penetration testing focuses on black-box or grey-box vulnerability discovery against an integrated, deployed artifact to validate runtime defenses, rendering it premature during the foundational architecture phase where security controls must instead be engineered into component interfaces and data flows. This activity remains highly tempting because practitioners naturally associate security assurance with offensive verification, making it the definitive choice during the later 'Security Assessment and Authorization' or operational readiness phase once the physical or virtual implementation is fully realized.

Confidentiality

Why it fails: Confidentiality aims to protect data from unauthorised disclosure, which fails to address the direct modification of data or system parameters that characterises the STRIDE Tampering category. This option is tempting because malicious actors frequently alter data en route to stealing it, making information security controls appear universally applicable. Confidentiality would represent the correct choice if the threat modeling exercise specifically evaluated risks associated with unauthorised data exposure or eavesdropping rather than malicious alteration or integrity breaches.

Availability

Why it fails: Availability concerns the disruption of service or denial of access, which maps to the 'Denial of Service' threat category in the STRIDE model rather than Tampering. This option is tempting because malicious actors frequently modify system files or network traffic to halt operations, making disruption a natural assumption when system states are altered. It would be the correct choice if the question specifically addressed resource exhaustion attacks, deliberate flooding of network interfaces, or hardware sabotage designed to prevent legitimate users from accessing critical enterprise services.

Non-repudiation

Why it fails: Non-repudiation fails here because it ensures proof of data transmission or origin rather than protecting data in transit or storage from unauthorized alteration. This option is tempting because tampering involves unauthorized modifications to data or systems, making it easily confused with the need to prevent a sender from falsely denying the transmission of a message. Non-repudiation would be the correct choice in a scenario requiring cryptographic proof, such as verifying the exact origin and receipt of a signed digital contract to prevent a party from repudiating their actions.

To replace the need for a risk assessment

Why it fails: A security control baseline establishes a standardised minimum level of protection derived from legislative mandates or organisational policy, serving as a starting point that requires subsequent risk assessment to identify unique threats and contextual vulnerabilities. This option is tempting because baselines streamline compliance by providing pre-packaged safeguard configurations, which would be the correct approach when rapidly deploying identical, low-risk commodity systems governed by rigid regulatory frameworks where tailoring is explicitly prohibited.

To audit employee performance

Why it fails: Auditing employee performance falls under human resources management and administrative oversight rather than technical systems architecture, making it irrelevant to the System Development Life Cycle. This choice appears tempting because security frameworks do involve personnel monitoring, and evaluating staff adherence to security policies is a vital administrative control. Such an approach would be the correct choice when conducting a workforce productivity review, assessing human resources metrics, or investigating specific insider threat behaviors, but it does not establish the foundational technical security requirements needed for system design.

To automate the deployment of security patches

Why it fails: Automating the deployment of security patches addresses vulnerability management during the operational phase of the System Development Life Cycle rather than defining the initial security requirements and safeguards mandated by a security control baseline. This distracter appears tempting because patch management is a crucial operational security control used to maintain system integrity against newly discovered threats. It represents a valid and necessary administrative mechanism that would be the correct choice if the question specifically asked about maintaining software currency and mitigating known exploits in production environments.

Reduces the total number of lines of code

Why it fails: Dividing a system into discrete modules often results in code reuse and boilerplate encapsulation, which can inadvertently increase or leave the total source line count unchanged while still successfully isolating system functions. This option is tempting because developers frequently conflate modularity with refactoring techniques designed to compress codebases, a strategy that is valid when prioritising storage efficiency or reducing compilation overhead under strict resource constraints.

Eliminates the need for API gateways

Why it fails: API gateways manage north-south traffic routing, protocol translation, and rate limiting at the perimeter of distributed architectures, whereas modularity isolates internal components to contain security failures regardless of how external requests enter the system. This option appears attractive because consolidating microservices behind a unified routing layer simplifies ingress management and perimeter control, making it the correct choice when designing a secure entry point for a microservices architecture.

Guarantees the system cannot be hacked

Why it fails: Claiming that modularity guarantees immunity to hacking is fundamentally incorrect because compartmentalising code or system architecture only limits the blast radius of a breach rather than eradicating underlying vulnerabilities such as buffer overflows or logic flaws. This option appears tempting because modular design aims to isolate components and enforce strict boundaries to contain potential failures, which would indeed be the correct choice if the objective were to restrict privilege escalation and simplify maintenance by ensuring that a compromise in one module does not automatically cascade through the entire system.

Role-Based Access Control (RBAC)

Why it fails: Role-Based Access Control relies on static assignments that struggle to accommodate the dynamic, granular service-to-service communication requirements of microservices. While it effectively manages broad user permissions within monolithic applications or enterprise environments like Microsoft Entra ID, it lacks the fine-grained, context-aware policy enforcement necessary for zero-trust architectures. Consequently, it fails to provide the ephemeral, attribute-based authorization required to restrict individual service interactions, leading to excessive privilege accumulation rather than the precise, identity-centric control demanded by the principle of Least Privilege.

Discretionary Access Control (DAC)

Why it fails: Discretionary Access Control relies on individual object owners managing permissions, which fails in microservices because it lacks the centralised, policy-driven automation required to enforce least privilege across ephemeral, distributed service identities. This approach remains tempting for local file system security or small-scale collaborative environments where data owners require granular, ad-hoc control over specific resources. In such scenarios, it provides the flexibility needed for manual permission assignment, whereas microservices demand the programmatic, identity-based governance provided by frameworks like Microsoft Entra ID.

Mandatory Access Control (MAC)

Why it fails: Mandatory Access Control relies on static, kernel-level security labels that lack the granularity to manage dynamic, identity-based service-to-service communication inherent in microservices. While it provides robust, deterministic isolation for monolithic operating systems by enforcing strict information flow policies, it fails to address the ephemeral, API-driven authorisation requirements of distributed architectures. It remains a powerful mechanism for securing high-assurance, single-host environments where process-level compartmentalisation is the primary objective, but it cannot dynamically evaluate the context-aware claims required for modern service mesh authentication.

Its location in the physical facility

Why it fails: Physical placement within a facility does not determine whether a component is security-critical, as critical processing assets can reside in standard office areas while peripheral or non-essential hardware sits inside a secure server room. Administrators often conflate asset visibility with logical criticality because physical security zones help protect hardware from unauthorised access and environmental threats. Assessing physical location would be a valid evaluation factor when designing environmental controls, perimeter defence topologies, or physical access policies, but it fails to evaluate the internal data-processing functions and trust boundaries that define security-criticality.

Its cost of procurement

Why it fails: Financial expense relates purely to budgetary planning and asset procurement rather than architectural vulnerability or trustworthiness. Administrators evaluating a component's security criticality must examine systemic risk factors, such as privilege elevation potential and processing boundaries, rather than capital outlay. Nevertheless, pricing metrics appear relevant when performing a standard cost-benefit analysis for hardware acquisition, making financial metrics a natural distraction during general risk management reviews where stakeholders conflate expensive enterprise hardware with inherent security robustness.