CISSP practice questions with answers

Answer: A) COBIT

• ACOBIT provides a framework for governing and managing enterprise IT.
• BSTRIDE is a threat modeling method.
• CThe OWASP Top 10 lists web application risks.
• DBell-LaPadula is a confidentiality security model.

Answer: A) Determine how disruption of each critical process would harm the organization over time, to set recovery priorities

A BIA identifies critical processes and measures how their disruption would affect the business over time, which sets recovery priorities and objectives. Estimating likelihood, choosing a strategy and testing are separate steps in continuity planning.

• AA BIA measures the business impact of a disruption, including impact that changes over time, and identifies critical processes and their dependencies. Its results set recovery priorities and objectives such as maximum tolerable downtime, RTO and RPO.
• BEstimating how likely a disruption is describes risk assessment, which feeds continuity planning alongside the BIA. The BIA focuses on the consequences of a disruption, not how likely it is.
• CChoosing a recovery strategy comes after the BIA. It uses the recovery objectives and priorities that the BIA produces, weighed against cost.
• DExercises and tests check a plan that already exists. They confirm whether recovery targets can be met but do not set those targets or priorities.

Answer: A) Vulnerabilities found after the end-of-support date will not receive vendor security fixes

End of support means the vendor stops releasing security patches, so new vulnerabilities stay open. Running the product past that date needs a migration plan or compensating controls such as paid extended security updates or isolation.

• ACorrect. After end of support the vendor stops releasing security updates, so newly discovered flaws stay exploitable. The organization must plan migration or add compensating controls, and vendor guidance says third-party controls are not a substitute for product security fixes.
• BIncorrect. End of support ends servicing. It does not revoke the licence to keep running the product, and Microsoft's ESU program exists for customers who keep running products past end of support.
• CIncorrect. Existing features keep working after end of support. The risk is that flaws in them, or anywhere else in the product, will no longer be patched.
• DIncorrect as the MOST significant concern. Losing technical support is an operational inconvenience. Unpatched vulnerabilities in a system holding customer records are the bigger security risk.

Answer: A) Degaussing will not sanitize flash storage; use a purge method such as cryptographic erase on the self-encrypting drives, or physically destroy them

Degaussing works only on magnetic media, so it does not sanitize SSDs. For confidential data leaving the organization's control, use a purge method such as cryptographic erase, or physically destroy the drives.

• ACorrect. SSDs store data in flash memory cells, not on magnetic media, so a degausser cannot sanitize them. Suitable options are cryptographic erase, which destroys the media encryption key on drives that have always encrypted their data, or physical destruction such as shredding, disintegration, or punching, chosen according to how sensitive the data is.
• BIncorrect. A stronger degausser does not help. Flash storage does not record data magnetically, so no field strength sanitizes it. Degaussing applies to magnetic media only.
• CIncorrect. Because of wear leveling and over-provisioning, SSDs keep data in physical locations that the host cannot address. Overwriting logical blocks can leave remnant copies, and reading back logical blocks cannot prove those hidden areas are clean.
• DIncorrect. Formatting and reimaging overwrite only some logical areas. This is not a purge-level technique, and recoverable data can remain on the flash media.

Answer: A) Graham-Denning

• AGraham-Denning specifies protection rights for creating, deleting and transferring access rights.
• BBell-LaPadula focuses on confidentiality through read and write rules.
• CBiba focuses on integrity through read and write rules.
• DBrewer-Nash prevents conflicts of interest.

Answer: A) Integrity; most relevant where trustworthiness of data matters more than secrecy, such as financial transaction processing

Biba is an integrity model: 'no write up' and 'no read down' stop low-integrity data from corrupting high-integrity data. It is the integrity counterpart to the confidentiality-focused Bell-LaPadula model.

• ACorrect. Biba stops subjects from writing to higher integrity levels or reading from lower ones, so less trustworthy data can't contaminate more trustworthy data.
• BThis describes Bell-LaPadula ('no read up', 'no write down'). Biba is the integrity counterpart and reverses those rules.
• CBiba is an access-control model for information flow. It doesn't address uptime or fault tolerance.
• DNon-repudiation comes from mechanisms such as digital signatures and audit logging, not from Biba's integrity-level rules.

Answer: A) Micro-segmentation

• AFirewall policy at each workload, enforced by distributed firewalls, limits lateral movement between systems.
• BA perimeter firewall doesn't control traffic between internal workloads.
• CA flat network has no internal segmentation.
• DA broadcast domain describes Layer 2 reach.

Answer: A) Encapsulating Security Payload (ESP) provides encryption; tunnel mode encrypts the whole original packet inside a new IP header

• AESP offers confidentiality plus optional integrity/authentication; AH provides integrity/authentication only. Tunnel mode protects the entire inner packet (gateway-to-gateway), while transport mode protects just the payload between endpoints.
• BAH does not encrypt anything, and transport mode does not encapsulate the entire original packet.
• CESP is right for encryption, but full-packet encapsulation in a new header is tunnel mode, not transport.
• DBoth clauses are wrong: AH doesn't encrypt, and tunnel mode is about encapsulation scope, not 'integrity only'.

Answer: A) OAuth 2.0 delegates authorization to resources through access tokens; OIDC adds an authentication layer on top of it by issuing an ID token

OAuth 2.0 handles delegated authorization by issuing access tokens. OIDC is built on OAuth 2.0 and adds authentication through the ID token, which lets an application verify the user's identity.

• ACorrect. OAuth 2.0 is an authorization framework that grants a client access tokens for protected resources. OIDC extends OAuth 2.0 for authentication: it adds the ID token (a signed JWT) that lets the relying party verify who the user is.
• BThis swaps the roles. OIDC is the layer built on OAuth 2.0, and the ID token comes from OIDC, not from base OAuth 2.0.
• CThey complement each other rather than compete. Base OAuth 2.0 doesn't define an ID token, and OIDC exists to add authentication, not to support mobile clients.
• DAn OAuth access token is meant for a resource server and doesn't assert the user's identity to the client. OIDC uses JSON/JWT, not XML. SAML is the XML-based federation standard.

Answer: A) Crossover error rate (CER), the point at which the false acceptance and false rejection rates are equal

FAR (Type II errors) and FRR (Type I errors) move in opposite directions as sensitivity is tuned. The crossover error rate, where they are equal, is the tuning-independent figure used to compare biometric systems, and lower is better.

• ARaising or lowering sensitivity trades FAR against FRR. The CER is the one point where the two rates are equal, so it is a single figure that does not depend on how a customer tunes the device. A lower CER means a more accurate system.
• BFAR is critical for security, but it changes with the sensitivity setting. A vendor can make FAR look excellent by tightening the threshold while FRR climbs, so FAR alone is not a fair comparison.
• CFRR measures usability and also depends on the threshold. A loose setting gives a low FRR at the cost of more false accepts, so FRR alone does not reflect overall accuracy.
• DThroughput is a performance and acceptability factor. It measures speed, not how accurately the reader tells genuine users from impostors.

Answer: A) Misuse case testing

• AMisuse case testing examines how an attacker might abuse functionality.
• BRegression testing confirms that existing features still work after changes.
• CLoad testing measures performance under volume.
• DSynthetic transactions check availability and response times.

Answer: A) Examine (review artifacts), interview (question personnel), and test (exercise the control and observe results)

• AThese are the standard control-assessment methods (as in NIST SP 800-53A): documentation review, discussion with operators, and hands-on testing. Using all three gives stronger assurance than any one alone.
• BThose relate to selecting/adjusting a control baseline and authorizing a system, not assessing a control's effectiveness.
• CThose are media sanitization methods.
• DThose are incident/operational functions, not assessment methods.

Answer: A) The RTO must not exceed the MTD and is normally set below it to leave a margin for recovery problems

The MTD is the business's absolute limit on outage length. The RTO must be no longer than the MTD and is usually set below it so recovery fits comfortably within that limit.

• AThe MTD is the longest outage the business can survive. The RTO is the target for restoring the function, so it must fit within the MTD, and it is usually set lower so delays during recovery do not push the outage past the MTD.
• BThis reverses the relationship. The MTD expresses the business's total tolerance, and the RTO is the recovery target that must fit inside it.
• CThe RPO measures acceptable data loss, not downtime. However little data is lost, an outage longer than the MTD exceeds what the business can survive.
• DThe RTO comes from business impact. Technical capability is then matched to it, and an RTO that ignores the MTD is an arbitrary recovery objective.

Answer: A) Baselining egress flow records such as NetFlow and alerting on deviations in volume or peer

Exfiltration is outbound traffic, so it is detected by monitoring egress flows for unusual volumes or destinations. Inbound deny logs, vulnerability scans, and FIM address other threats.

• ACorrect. Flow records capture who talked to whom, in which direction, and how much data moved. Comparing outbound flows to a baseline exposes unusual transfer volumes or new external peers, which are classic signs of exfiltration.
• BIncorrect. Inbound deny logs show external traffic that the perimeter blocked. Exfiltration is outbound traffic that was allowed out, so it would not show up in these logs.
• CIncorrect. Vulnerability scanning finds weaknesses that could be exploited. It does not watch live traffic, so it cannot detect data that is actively leaving the network.
• DIncorrect. FIM alerts when monitored files are changed. Reading or copying data does not change the files, so exfiltration would go unnoticed.

Answer: A) Add automated SAST, dependency, and secrets scans to each build, with gates that fail builds on critical findings

DevSecOps 'shifts left' by building automated security testing (SAST, SCA, secrets scanning) and policy gates into the CI/CD pipeline, so issues are found and fixed continuously during delivery. Late or infrequent checks alone don't achieve this.

• ACorrect. DevSecOps builds automated security controls into every stage of the delivery pipeline. In the build stage that means SAST, software composition analysis and secrets scanning, with gates that stop risky changes. Developers get fast feedback, and issues are fixed early, when fixes cost less.
• BIncorrect. Penetration testing is valuable and can complement DevSecOps. But a quarterly external test is a late check that happens rarely, and it can't keep up with several deployments a day.
• CIncorrect. A manual approval step at the end still leaves security as a late gate and slows frequent releases. It doesn't build automated security testing into development and build stages.
• DIncorrect. Scanning production finds problems only after deployment, and only every few months. DevSecOps aims to catch flaws in code and dependencies before they reach production.