Secure Software Concepts practice questions

The write is permitted.

Why it fails: Writing to a higher level is a 'write-up' which is allowed by the simple security property but restricted by the *-property in specific implementations.

The write is denied due to the no-write-down rule.

Why it fails: The user is writing up, not down.

The system allows the write only if encryption is used.

Why it fails: Bell-LaPadula is a formal model not dependent on specific encryption implementations.

Read-up

Why it fails: Read-up is permitted in Biba as it pulls high-integrity data into a lower-integrity level.

Write-up

Why it fails: Write-up is prohibited in Biba to prevent corruption of high-integrity objects.

Execute-down

Why it fails: Execution is not the primary focus of the Biba read/write constraints.

Append-down

Why it fails: Append-down is generally allowed in Biba.

Role-Based Access Control (RBAC)

Why it fails: RBAC is a general model, not specific to Clark-Wilson's integrity enforcement.

Attribute-Based Access Control (ABAC)

Why it fails: ABAC uses attributes, which is a different access model.

Discretionary Access Control (DAC)

Why it fails: Clark-Wilson is more rigid than DAC.

Security Labels

Why it fails: Labels are used in Bell-LaPadula.

Granting the application access to all system environment variables.

Why it fails: Environment variables routinely hold database credentials, API keys and connection strings, so blanket access hands the application far more secrets than its function requires. Least privilege means exposing only the variables the process needs. Full environment inheritance suits simple scripts where no sensitive values exist.

Enabling 'Everyone' write access to application configuration files.

Why it fails: Write access for Everyone lets any local or network user alter configuration files, enabling tampering with connection strings or injected code. Least privilege restricts writes to the service account and administrators. Broad write permissions suit shared scratch directories holding no executable or security-relevant content.

Running the application process as 'root' or 'administrator'.

Why it fails: Running as root or administrator grants the process unrestricted access to every file, device and system call, so a compromise yields full host control. Least privilege requires a dedicated low-privilege service account. Root execution suits only trusted administrative tasks that genuinely need system-wide changes.

Availability

Why it fails: Availability concerns uptime and access to resources, whereas embedded keys expose secrets to anyone with repository access, breaching confidentiality. Availability would be the correct lens if the scenario described denial of service, resource exhaustion or failover gaps rather than secret exposure.

Non-repudiation

Why it fails: Non-repudiation concerns proving that a party performed an action, typically via digital signatures, not protecting key secrecy. Hardcoded keys violate confidentiality, because repository readers gain the key and can decrypt the protected data without authorisation.

Integrity

Why it fails: Integrity concerns unauthorised modification of data, not key secrecy; hardcoded keys violate confidentiality, since anyone with repository access obtains the key and can decrypt protected data. Integrity would be the concept at issue if tampering detection, such as hashing or signatures, were the concern.

Accounting

Why it fails: Accounting concerns logging and attributing user actions for audit trails, not key storage. Hardcoded keys violate confidentiality by exposing secrets in the repository. Accounting would be the right focus when the requirement is non-repudiation or tracing which principal performed an action.

Availability

Why it fails: Availability concerns uptime and reachability of services, not protection of a credential during exchange. Requiring client_secret authenticates the client to the token endpoint, which is confidentiality and authentication of the client, not availability. Availability would be the focus when designing redundancy or DDoS resilience for the authorisation server.

Non-repudiation

Why it fails: Non-repudiation proves an action occurred and cannot be denied, typically via digital signatures or audit logs. The client_secret instead authenticates the client during token exchange, preventing an intercepted code from being redeemed by an unauthorised party. Non-repudiation would apply when proving a client genuinely submitted a specific request.

Confidentiality

Why it fails: The client_secret authenticates the client during token exchange, confirming the code reaches its intended recipient; confidentiality is a property, not the mechanism being applied. It is tempting because intercepted codes are concealed, but the correct concept is authentication of the client.

Integrity

Why it fails: Integrity protects data from unauthorised modification, whereas the client_secret proves the exchanging client's identity rather than detecting tampering. It is tempting because the code must not be altered, but the correct concept is client authentication during the token exchange.

Software integrity

Why it fails: STRIDE's 'S' denotes Spoofing, an authentication threat where an actor impersonates another identity. Software integrity is tempting because it sounds security-related, but integrity maps to Tampering, so software integrity would be the right association only if the letter in question were 'T' rather than 'S'.

Service availability

Why it fails: STRIDE's 'S' denotes Spoofing, an authentication threat. Service availability maps to Denial of Service, the 'D' category, so it names the wrong letter entirely. It is tempting because availability is a genuine STRIDE concern, but it belongs under Denial of Service, not the 'S' position.

System hardening

Why it fails: System hardening is a defensive practice, not a STRIDE threat category; the 'S' denotes Spoofing, which concerns impersonating a legitimate identity. It is tempting because hardening reduces attack surface, so it would be relevant if the question asked about mitigations rather than the threat classification itself.

Secure architecture

Why it fails: STRIDE's 'S' denotes Spoofing, an authentication threat. Secure architecture is a design goal, not a threat category, so it cannot be the letter's meaning. It is tempting because security architects do use STRIDE outputs to harden designs, but that is a downstream activity, not the acronym's definition.

Authorization

Why it fails: Authorization governs what an authenticated principal may do after identity is established; a signature proves who sent the message, which is authentication. It is tempting because both concern identity and access, but authorization requires a policy decision, which signing alone does not perform.

Encryption

Why it fails: Signing uses the sender's private key to produce a verifiable signature; it does not transform the message into ciphertext. Encryption is tempting because both rely on key pairs, yet encryption for confidentiality uses the recipient's public key, a different mechanism and goal.

Availability

Why it fails: Availability concerns uptime and reachability of systems, which a signature does nothing to provide. It is tempting because signatures protect integrity of the message, and integrity is loosely associated with trustworthiness, but availability is an operational property, not a cryptographic one.

Confidentiality

Why it fails: Digital signatures verify origin and integrity, not secrecy; the message remains readable unless separately encrypted. Confidentiality is tempting because cryptographic operations are involved, yet it is achieved by encryption of the payload, not by signing, which leaves content exposed.

Non-repudiation

Why it fails: Non-repudiation proves a specific party performed an action, typically via digital signatures and audit trails binding identity to a transaction. Synchronous replication provides no such proof; it only duplicates data to a secondary node. Non-repudiation would be correct if the requirement were disputing denial of a signed transaction or message.

Integrity

Why it fails: Synchronous replication maintains identical copies of data across nodes, which is a consistency and correctness property, not integrity in the CIA sense of detecting unauthorised modification. Integrity controls are hashing, checksums and digital signatures. It would be the answer if the stem asked about preventing undetected alteration of stored records.

Confidentiality

Why it fails: Replication addresses availability by keeping a standby copy, not confidentiality, which concerns restricting data access to authorised parties through encryption and access control. Confidentiality would be correct if the scenario required protecting data at rest or in transit from disclosure, rather than surviving a database server failure.

Disabling all firewall rules for testing purposes.

Why it fails: Disabling firewall rules removes a control layer rather than stacking independent ones, directly contradicting defence-in-depth's requirement for overlapping safeguards. It is tempting because temporary rule suspension is a legitimate troubleshooting technique when diagnosing connectivity faults during controlled testing windows, but that operational practise weakens the architecture instead of demonstrating layered protection across network, host, and application tiers.

Storing all application data in a single encrypted volume.

Why it fails: Storing data in one encrypted volume protects only data-at-rest confidentiality; it adds no independent control at other layers, so a single failure exposes everything. Encryption at rest is the right answer when the requirement is regulatory protection of stored data, such as database volume encryption, not layered defence across network, host, application and data tiers.

Removing all logs to prevent unauthorized access to audit trails.

Why it fails: Deleting audit logs eliminates the detective control layer that defence-in-depth depends on, so a breach would leave no evidence for detection or forensics. It is tempting because log access genuinely is a risk, but that is addressed through access controls, encryption and retention policies—not by destroying the records themselves.

Using a single strong password for all database accounts.

Why it fails: Reusing one strong password across database accounts collapses authentication into a single shared secret, so one credential compromise exposes every account — no independent layer exists. It is tempting because strong passwords are a genuine control, and password managers or vaults make unique per-account credentials manageable, but that addresses credential strength, not layered defence.

To simplify administrative tasks by giving everyone full access.

Why it fails: Full access for everyone eliminates the restriction that least privilege demands, maximising exposure instead of limiting it. It is tempting because centralised full access removes per-user permission troubleshooting, and that approach would be correct only in a fully trusted, non-sensitive environment.

To ensure that security controls are invisible to users.

Why it fails: Invisibility of controls addresses user experience, not the scope of granted rights, so it does nothing to limit privileges. It is tempting because seamless security reduces friction and support tickets, and invisible controls would be correct where enforcement must not disrupt legitimate workflows.

To provide all users with the same set of permissions.

Why it fails: Uniform permissions across all users directly contradict least privilege, which grants each identity only the access its role requires. It is tempting because standardised permission sets reduce administrative overhead, and such uniformity would be correct where every user genuinely needs identical, minimal rights.

To automatically grant permissions based on time of day.

Why it fails: Time-based granting ties permissions to a schedule rather than to job requirements, so excessive rights persist outside those windows. It is tempting because temporal restrictions suit shift-based or temporary access, and time-of-day granting would be correct for scheduled, time-bounded privileged sessions.

If the authentication service is down, allow access to all users.

Why it fails: Granting everyone access when authentication is unavailable converts an outage into an open door, abandoning the deny-by-default posture. It is tempting because it preserves availability during identity-provider downtime, but fail-safe defaults demand that unverified principals be refused.

If the firewall fails, allow all traffic to pass through.

Why it fails: Permitting all traffic when the firewall fails grants access by default, the opposite of denying unless explicitly authorised. It is tempting because availability-focused designs keep services reachable during outages, but fail-safe defaults prioritise confidentiality and integrity over uninterrupted connectivity.

Default all new user accounts to 'Administrator' role.

Why it fails: Defaulting new accounts to Administrator violates least privilege, granting maximum rights before any authorisation check occurs. Fail-safe defaults instead deny access unless explicitly permitted. The tempting rationale is administrative convenience, but privileged-by-default provisioning is the opposite posture; it suits no compliant scenario, since role assignment should follow approval.

If the load balancer times out, bypass the application logic.

Why it fails: Skipping application logic on timeout removes the checks that enforce authorisation, so requests proceed without validation. It is tempting because graceful degradation maintains responsiveness under load, yet fail-safe defaults require the system to deny or halt rather than bypass security controls.

The same developer writes, reviews, and deploys the code.

Why it fails: One developer writing, reviewing, and deploying removes independent verification, so no second party checks the change before release. It is tempting because small teams value speed, but separation of duties requires distinct individuals for authoring, review, and deployment to prevent unreviewed code reaching production.

The QA team is allowed to modify production database records.

Why it fails: Allowing QA to modify production database records merges testing authority with production data control, so one team both validates and alters live data. It is tempting because QA needs realistic data, but separation of duties requires testers to verify without holding write access to production systems.

The build server automatically deploys code without human verification.

Why it fails: Automatic deployment without human verification removes the approval gate, so code reaches production with no independent authorisation. It is tempting because CI/CD automation is standard practise, but separation of duties requires a distinct approver before release, not just automated build and deploy steps.

All developers have access to the production environment credentials.

Why it fails: Granting every developer production credentials collapses the separation between code authorship and production deployment, letting one person write and release changes. It is tempting because shared credentials simplify releases, but separation of duties requires distinct individuals or roles for development and production access.

To lower the cost of hardware infrastructure.

Why it fails: Economy of Mechanism concerns keeping security functions small and simple so they can be verified, not reducing infrastructure spend. Hardware cost is irrelevant to the design principle. It is tempting because "economy" implies financial saving, and cost optimisation would be the right focus in a budgeting or capacity-planning scenario.

To increase the lines of code for better functionality.

Why it fails: Adding lines of code enlarges the attack surface and increases the chance of exploitable flaws, directly contradicting Economy of Mechanism. It is tempting because more code can appear to deliver more functionality, yet the principle exists precisely to discourage unnecessary complexity in security-relevant components.

To ensure that the software is faster at runtime.

Why it fails: Runtime speed is a performance concern unrelated to Economy of Mechanism, which limits the number of security-relevant components so each can be verified and understood. It is tempting because leaner code often runs faster, but performance is a side effect, not the principle's security purpose.

To enable easier debugging for developers.

Why it fails: Economy of Mechanism concerns minimising complexity to reduce the attack surface and the chance of exploitable flaws, not developer debugging convenience. Debugging is served by logging, tracing and diagnostic tooling, which can themselves widen exposure. This option would fit a question about developer productivity or troubleshooting workflows, not a security design principle.

Non-repudiation

Why it fails: Non-repudiation provides proof of origin or delivery so a party cannot deny an action; it does not keep services reachable under heavy load or attack. It is tempting because it also concerns trust between parties, and non-repudiation would be correct if the scenario required irrefutable evidence that a transaction occurred.

Integrity

Why it fails: Integrity ensures data remains accurate and unaltered; it does not guarantee that services stay reachable when demand spikes or traffic is flooded. It is tempting because tampering is a security concern, and integrity would be correct if the scenario required detecting unauthorised modification of stored or transmitted records.

Authentication

Why it fails: Authentication verifies a principal's claimed identity at login; it neither sustains throughput under load nor resists flooding, so it cannot describe continued service during a denial-of-service attack. It is tempting because authorised users must first authenticate, and authentication would be correct if the question asked how those users prove who they are.

Confidentiality

Why it fails: Confidentiality restricts disclosure of data to authorised parties; it says nothing about maintaining service availability when resources are exhausted or flooded. It is tempting because both are CIA triad goals, and confidentiality would be correct if the scenario concerned preventing unauthorised reading or exposure of information.

Granting permanent access to all authenticated users.

Why it fails: Complete Mediation requires every access request to be checked against policy at the moment of use, so blanket permanent grants bypass that check entirely. It is tempting because simplifying authentication by trusting all verified users reduces overhead, and that approach fits low-sensitivity environments where authorisation granularity is not required.

Checking authorization only at login.

Why it fails: Checking authorisation only at login leaves every subsequent request unmediated, so a revoked or changed permission is never re-evaluated. It is tempting because authentication at login is a genuine control point, and would be the right design where session-level identity is the only decision required, such as a single-purpose kiosk.

Relying on the user to request access when needed.

Why it fails: Complete mediation requires the system to check every access against policy, not to depend on the subject asking; user-initiated requests bypass enforcement for any access not explicitly requested. It is tempting because prompting users appears to reduce overhead, and would suit discretionary sharing models rather than mandatory access control.

Caching permissions to reduce latency.

Why it fails: Caching permissions means later requests are served from stored decisions rather than re-checked against current policy, so revocation and policy changes are not honoured. It is tempting because caching cuts per-request latency, and would be the correct approach for high-throughput read paths where authorisation state is static.

Providing zero feedback to users during the login process.

Why it fails: Zero feedback leaves users unable to tell whether authentication succeeded, failed, or stalled, which destroys psychological acceptability. Silent processing belongs in anti-enumeration designs for login error messages, but here users need clear prompts and status indicators to complete multi-factor authentication confidently.

Requiring a 64-character password changed every 24 hours.

Why it fails: A 64-character password rotated daily imposes enormous memory and administrative burden, directly undermining psychological acceptability. Long passphrases with infrequent rotation suit high-assurance environments, but daily changes guarantee users write credentials down or reuse patterns, defeating the security aim.

Disabling the ability for users to reset their own passwords.

Why it fails: Removing self-service reset forces every forgotten password through the help desk, adding delay and friction that psychological acceptability specifically seeks to avoid. Self-service reset is the right control for reducing support load; disabling it suits only environments where identity proofing must be tightly controlled.

Forcing users to solve a complex CAPTCHA at every login attempt.

Why it fails: A complex CAPTCHA at every login adds repeated cognitive friction unrelated to authentication strength, contradicting psychological acceptability. CAPTCHAs belong at registration or suspected-bot endpoints; requiring them universally punishes legitimate users and slows routine access without improving the multi-factor assurance.

Trust but verify

Why it fails: 'Trust but verify' assumes an initial trust decision before checks occur, which contradicts Zero Trust's premise that no actor or device is trusted by default regardless of network location. It is tempting because it sounds security-conscious, but it belongs to perimeter-based models; Zero Trust requires explicit verification of every request before access is granted.

Trust all internal network traffic

Why it fails: Trusting all internal network traffic treats the corporate network as an implicit trust boundary, which is exactly the assumption Zero Trust rejects. It is tempting because internal traffic was historically considered safe behind the firewall, but Zero Trust requires every request to be authenticated and authorised regardless of origin, internal or external.

Encrypting data at rest using AES.

Why it fails: AES encryption at rest provides confidentiality by rendering data unreadable without the key; it does not detect or prevent unauthorised alteration, which is integrity's concern. It is tempting because encryption is a common security control, and it would be correct where the requirement is protecting stored data from disclosure.

Ensuring the server is always online.

Why it fails: Availability, not integrity, is what keeping a server online preserves; integrity concerns unauthorised modification of data or code. It is tempting because uptime genuinely matters in resilience planning, and an always-online server would be the right answer to an availability question.

Forcing users to change passwords regularly.

Why it fails: Forcing password changes supports confidentiality and authentication by limiting credential exposure, not integrity, which concerns preventing unauthorised modification of data or code. It is tempting as a general security control, but integrity is maintained through hashing, checksums, digital signatures and access controls.

Non-repudiation

Why it fails: Non-repudiation prevents a party denying an action, typically through digital signatures or audit trails, and is a separate security service rather than a CIA component. It is the correct choice when a question asks which property provides proof of origin or delivery.

Accounting

Why it fails: Accounting concerns logging and auditing of activity, which supports investigations but is not one of the three CIA triad components. It belongs to related frameworks such as the Parkerian hexad or assurance models, where accountability is treated as a separate attribute from confidentiality, integrity and availability.

Authentication

Why it fails: Authentication verifies a claimed identity before access is granted, supporting confidentiality indirectly but sitting outside the triad itself. It is a security service commonly paired with authorisation and accounting, and would be the right answer to a question asking which mechanisms enforce identity verification.