CISSP Security Assessment and Testing: 41 practice questions

12 of the 41 Security Assessment and Testing questions in the Certsqill CISSP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISSP? Take the free 5-min readiness check →

1. Black box testing: Which testing approach is being used?

1. Gray box testing

   Gray box testing provides partial knowledge — typically user-level credentials or some network information — simulating an insider with limited access. The scenario provides no prior knowledge, which is black box.
2. Black box testing ✓

   Black box testing simulates an external attacker with no prior knowledge of the target systems. Testers start with only publicly available information (in this case, the domain name) and must discover everything themselves — mimicking how a real external attacker would begin.
3. White box testing

   White box testing provides testers with full knowledge: network diagrams, source code, system configurations, and credentials. It is the most thorough approach but does not simulate an uninformed external attacker.
4. Vulnerability assessment

   A vulnerability assessment identifies and reports vulnerabilities without attempting to exploit them. A penetration test actively attempts to exploit discovered vulnerabilities to demonstrate real-world impact. The scenario describes an active simulation of an attacker.

Black box = no prior knowledge (external attacker simulation); white box = full knowledge; gray box = partial knowledge (insider simulation).

2. SAST for source code analysis and DAST for testing: Which combination of tools addresses both requirements?

1. IAST (Interactive Application Security Testing) alone, since its runtime agent inspects the application source statically and also exploits the running app dynamically within one tool

   IAST instruments a running application to observe behavior from the inside during testing, giving more accurate results than DAST. However, IAST still requires a running application and does not perform standalone source code analysis like SAST — it cannot replace SAST's pre-execution code review.
2. Fuzzing for the source code analysis and manual code review for the running application, since these two techniques are direct equivalents of SAST and DAST respectively

   Fuzzing sends malformed inputs to a running application (dynamic), so it cannot analyze static source code, and manual code review examines code rather than a running system. The two are not equivalents of SAST and DAST, and the pairing is reversed.
3. SAST (Static Application Security Testing) for source code analysis and DAST (Dynamic Application Security Testing) for testing the running application ✓

   SAST analyzes source code, bytecode, or binaries without executing the application — it can find vulnerabilities at the code level early in the SDLC. DAST tests the running application by sending malicious inputs and observing responses — it finds vulnerabilities that only manifest during execution, like actual SQL injection exploitability.
4. DAST (Dynamic Application Security Testing) for source code analysis and SAST (Static Application Security Testing) for testing the running application during integration

   This reverses the definitions. DAST requires a running application — it cannot analyze source code. SAST analyzes static code artifacts — it does not exercise a running application.

SAST analyzes source code without execution (early SDLC); DAST tests the running application by sending malicious inputs — both are needed for comprehensive coverage.

3. External security audit conducted by an independent: Which type of assessment best satisfies this requirement?

1. Internal security audit conducted by the company's own internal audit department

   Internal audits are valuable for management but lack the independence required for external stakeholder reporting. An internal audit team is employed by the same organization being assessed — shareholders and regulators require independent third-party validation.
2. Vulnerability assessment performed with automated network scanning tools

   An automated vulnerability scan identifies technical vulnerabilities in systems. It does not provide the comprehensive assessment of security control framework effectiveness required for regulatory compliance or shareholder reporting.
3. Penetration test conducted by an external offensive security firm

   A penetration test identifies exploitable vulnerabilities — it tests whether controls can be bypassed. It does not assess the effectiveness of the overall security control framework for compliance and reporting. Audits evaluate control design and operating effectiveness; pen tests evaluate exploitability.
4. External security audit conducted by an independent third-party auditor ✓

   For shareholder reporting and regulatory compliance (SOX, etc.), an independent third-party audit is required to provide objective assurance. External auditors have no organizational conflict of interest and provide credibility to the findings. Internal audit teams cannot provide the independence required for external stakeholder reporting.

External audits by independent third parties provide the objectivity and independence required for shareholder reporting and regulatory compliance — internal audits lack the required independence.

4. Fuzz testing: Which testing technique is being used?

1. Fuzz testing (fuzzing) ✓

   Fuzzing automatically generates large volumes of malformed, random, or semi-random inputs and feeds them to the target, monitoring for crashes, hangs, memory corruption, or exception errors. It is particularly effective at finding buffer overflows, format string vulnerabilities, and input parsing errors that are difficult to find through manual testing.
2. DAST (Dynamic Application Security Testing)

   DAST is a broader category of dynamic testing that includes structured vulnerability tests (e.g., SQL injection, XSS probes). Fuzzing is a specific technique within dynamic testing focused on random/malformed input generation. While fuzzing is a form of dynamic testing, the scenario specifically describes fuzzing's characteristics.
3. Regression testing

   Regression testing verifies that previously working functionality still works after code changes. It uses existing test cases, not randomly generated malformed inputs. The scenario describes generating novel, malformed inputs — this is fuzzing.
4. Mutation testing

   Mutation testing evaluates the quality of test cases by introducing small changes (mutations) to source code and checking whether existing tests detect the changes. It tests the test suite's effectiveness, not the application's response to malformed inputs.

Fuzzing automatically generates malformed/random inputs to find crashes and memory errors — particularly effective for finding input parsing vulnerabilities like buffer overflows.

5. Penetration test: Which assessment type is most appropriate?

1. Vulnerability assessment

   A vulnerability assessment scans for and reports known vulnerabilities but does not attempt to exploit them or demonstrate how vulnerabilities could be combined for attack chains. It answers 'what vulnerabilities exist?' not 'can an attacker use them to achieve a specific goal?'
2. Penetration test ✓

   A penetration test actively attempts to exploit vulnerabilities, including chaining multiple issues to achieve a specific objective (e.g., data access). This directly answers 'can an attacker actually succeed?' A vulnerability assessment would identify each vulnerability separately but would not demonstrate how they could be combined for a real attack.
3. Code review

   A code review examines source code for security flaws. It cannot assess runtime behavior, chained exploitation across system boundaries, or whether vulnerabilities are actually exploitable in the deployed environment.
4. Security audit

   A security audit evaluates whether controls are designed and operating effectively against a standard or policy. It does not perform active exploitation or attack simulation. Audits answer 'are controls in place and working as designed?' not 'can an attacker succeed?'

Penetration tests actively exploit and chain vulnerabilities to achieve attack objectives — a vulnerability assessment only identifies issues without demonstrating exploitability or attack chains.

6. Key Performance Indicators and Key Risk Indicators: What are these metric types called, respectively?

1. Key Risk Indicators (KRIs) and then Key Performance Indicators (KPIs)

   KPIs measure program performance effectiveness (current state); KRIs measure potential future risk exposure. Patch coverage and training completion are KPIs; unpatched critical vulnerabilities and risky vendors are KRIs. This option reverses the order the question asks for.
2. Lagging indicators for programs and leading indicators for risk

   While KPIs and KRIs loosely correlate with lagging/leading concepts, the established security governance terms are KPI (performance) and KRI (risk). Using generic business analytics terminology is imprecise for a CISSP context and is not what the question is testing.
3. Key Performance Indicators (KPIs) and Key Risk Indicators (KRIs) ✓

   KPIs measure the effectiveness of current security activities — they are backward-looking or present-state measures of how well programs are working. KRIs measure potential future risk exposure — they are forward-looking indicators that signal increasing risk before an incident occurs. Both are essential for board-level security reporting.
4. Service Level Objectives and Service Level Agreements (SLOs/SLAs)

   SLOs and SLAs define service delivery targets and contractual commitments — they are operational availability and performance measures, not indicators of security program effectiveness or forward-looking risk exposure.

KPIs measure current security program effectiveness; KRIs measure potential future risk exposure — both are needed for comprehensive board-level security reporting.

7. Insecure Direct Object Reference / Broken Access Control: Which OWASP vulnerability category does this represe

1. SQL Injection via manipulation of the account_id query parameter

   SQL injection inserts SQL syntax into input to manipulate database queries. Simply changing a numeric ID to reach another user's record (with no SQL syntax) is IDOR. Inserting something like ' OR '1'='1 to alter the query would be SQL injection.
2. Cross-Site Scripting (XSS) delivered through the account_id value

   XSS injects client-side scripts (JavaScript) into pages viewed by other users. Changing a URL parameter to read another user's account data is an authorization control failure (IDOR), not a script injection attack.
3. Security Misconfiguration exposing the account_id parameter

   Security misconfiguration refers to improper settings (default credentials, exposed admin interfaces, verbose errors). IDOR is a flaw in authorization logic — the application returns records without checking ownership, which is a coding/design defect rather than a misconfiguration.
4. Insecure Direct Object Reference (IDOR) / Broken Access Control ✓

   IDOR occurs when an application uses user-supplied input to directly access objects (database records, files) without verifying the authenticated user has permission to access that specific object. Changing account_id 1001 to 1002 to access another user's data is the classic IDOR example — the application fails to enforce authorization at the object level.

IDOR (Insecure Direct Object Reference) / Broken Access Control: the application fails to verify that the authenticated user has permission to access the specific object referenced by the user-supplied parameter.

8. The finding represents a significant security risk: Which characteristic of this finding justifies the high-se

1. The finding represents a significant security risk with active exploitation potential — terminated employees with live credentials can access systems without authorization, constituting an immediate insider threat exposure ✓

   High-severity findings combine significant likelihood and impact. Terminated employees with active accounts present: high likelihood of exploitation (credentials exist and may be known to former employees), high impact (unauthorized data access, sabotage), and regulatory exposure (many frameworks require timely deprovisioning). The 15% rate indicates a systemic control failure, not an isolated incident.
2. The finding documents a written policy violation, and the organization's classification scheme automatically rates every confirmed policy violation as high severity regardless of the underlying likelihood or business impact

   Policy violations vary in severity. Not all are high severity — a minor documentation formatting lapse might be low severity. Severity is based on the risk presented, not on the mere existence of a policy violation.
3. The finding surfaced during an external audit rather than an internal review, and findings raised by outside auditors are automatically escalated to high severity because of their heightened regulatory visibility

   Finding severity is based on risk (likelihood × impact), not on who discovered it. An external auditor's finding does not automatically outrank the same finding from an internal review — the source of discovery does not change the inherent risk.
4. The finding affects 15% of all user accounts, and because that proportion exceeds the audit program's predefined sampling threshold, the methodology requires that the result be recorded as a high-severity exception

   Severity is determined by risk, not by percentage of affected accounts versus a sampling threshold. Even one active account for a terminated employee with privileged access could be high severity, while many slightly over-provisioned low-privilege accounts might be only medium.

High-severity findings are justified by significant risk (likelihood × impact) — active credentials for terminated employees represent immediate unauthorized access potential and systemic control failure.

9. Administrative controls evidence: Which type of evidence is being collected?

1. Technical controls evidence (system configuration and scan testing)

   Technical controls include firewalls, encryption, access control systems, IDS/IPS, and authentication mechanisms. Testing them involves configuration reviews, vulnerability scans, and penetration testing — not reviewing paper procedures, request forms, and review records.
2. Administrative controls evidence (procedural/documentary evidence) ✓

   Administrative controls are the policies, procedures, standards, and guidelines that govern security activities. Testing administrative controls requires reviewing documentation: are procedures written and followed? Are access requests properly approved? Are periodic reviews conducted and documented? This is procedural/documentary evidence collection.
3. Physical controls evidence (facility and access inspections)

   Physical controls include locks, cameras, guards, and physical access systems. Testing them involves inspecting facilities, reviewing camera footage, and exercising physical access mechanisms — not reviewing IAM procedures and forms.
4. Detective controls evidence (monitoring and log analysis records)

   Detective controls detect and record security events (IDS alerts, audit logs, SIEM). That is a functional category (prevent/detect/correct), not an evidence type. The scenario describes administrative/procedural evidence regardless of the controls' functional category.

Administrative controls evidence includes policies, procedures, forms, and documentation showing that security processes are designed and followed — distinct from technical (systems) or physical (facilities) evidence.

10. Rules of Engagement: What is this document called, and why is it essential?

1. Statement of Work (SoW); it enumerates the engagement's deliverables, milestones, and commercial terms, and this contract is what legally authorizes the testers and defines which systems and hours are in scope

   A Statement of Work defines deliverables, timelines, and commercial terms; it does not itself authorize the testing boundaries. The Rules of Engagement specifically address authorization, scope, and technical constraints for the testing activities.
2. Non-Disclosure Agreement (NDA); it binds the testing firm to keep all discovered findings confidential and is therefore the controlling document that authorizes the scope, timing, and boundaries of the test

   An NDA protects confidential information shared during the engagement — it addresses confidentiality, not testing authorization. It is a separate document from the Rules of Engagement, which govern scope and constraints.
3. Rules of Engagement (RoE); it defines the legal authorization, scope boundaries, and constraints that protect both parties and ensure the test provides value without causing unintended damage ✓

   Rules of Engagement define: scope (what's in/out), timing constraints (testing windows), excluded systems, escalation procedures, emergency stop conditions, and data handling requirements. Without a signed RoE, the penetration test is unauthorized computer access — legally the same as criminal hacking. It protects the testing firm from prosecution and ensures client systems are not inadvertently damaged.
4. Penetration Testing Report; it records the discovered findings and remediation guidance, and this deliverable is what grants the testers legal authorization and defines the in-scope systems and testing hours

   A penetration testing report is produced after the test, documenting findings and recommendations — it does not grant authorization. Rules of Engagement are established before testing begins to define authorization and constraints.

Rules of Engagement define the legal authorization, scope, constraints, and escalation procedures for a penetration test — without a signed RoE, the test constitutes unauthorized computer access.

11. PCI DSS: Which assessment framework is being applied?

1. ISO 27001 (Information Security Management System standard)

   ISO 27001 is an international standard for information security management systems, providing a risk-based framework with 93 Annex A controls. It applies broadly but is not mandated by the card brands and lacks the specific 12-requirement structure described.
2. HIPAA Security Rule (healthcare ePHI protection rule)

   The HIPAA Security Rule protects Electronic Protected Health Information for healthcare organizations. It has no applicability to payment card processing — PCI DSS is the relevant standard for cardholder data protection.
3. SOC 2 Type II (Service Organization Control audit report)

   SOC 2 assesses trust service criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) for service organizations. Although it covers similar security areas, it is not organized around 12 requirements and is not specific to payment card processing.
4. PCI DSS (Payment Card Industry Data Security Standard) ✓

   PCI DSS is the security standard for organizations handling cardholder data. It specifies 12 high-level requirements (and hundreds of sub-requirements) covering network security, access control, encryption, vulnerability management, monitoring, and more. Compliance is validated by a QSA (Qualified Security Assessor) for large merchants or through self-assessment questionnaires for smaller ones.

PCI DSS specifies 12 requirements for organizations handling payment card data; compliance is validated by a QSA (Qualified Security Assessor) for applicable merchant levels.

12. Conduct a targeted assessment focused on the specific: Which approach maximizes the assessment's relevance to

1. Conduct a targeted assessment focused on the specific attack vectors (web framework patches, phishing resilience) used by the APT groups identified in threat intelligence ✓

   Threat intelligence-driven assessments prioritize testing against known, current adversary TTPs (tactics, techniques, procedures). Testing the specific web frameworks used in the environment against known CVEs and simulating spear-phishing against finance staff directly measures the organization's exposure to identified threats — more valuable than generic annual assessments.
2. Conduct a comprehensive vulnerability scan of every system in the environment to enumerate all present weaknesses, providing broad coverage that is independent of the current threat intelligence reporting

   A comprehensive scan provides broad coverage but does not prioritize against current threat intelligence. Running a full scan when specific attack vectors are known produces noise rather than focus — the team should prioritize the identified attack surfaces over a generic sweep.
3. Delay the assessment until the active APT campaign has fully concluded so that testing activity does not overwrite or interfere with any forensic evidence left behind by the ongoing intrusion attempts

   Intelligence about ongoing campaigns targeting the sector is precisely the time to assess urgently, not to wait. Delaying lets the threat potentially succeed, and forensic-evidence concerns arise after a confirmed compromise, not during a proactive assessment.
4. Conduct a tabletop exercise that walks the response team through a generic ransomware outbreak, exercising communication and decision-making rather than the specific technical attack vectors reported

   A tabletop exercise tests incident response processes through discussion, not technical controls. A generic ransomware tabletop does not address the specific APT vectors identified (web framework exploitation and finance spear-phishing).

Threat intelligence-driven assessments test the specific TTPs used by identified adversaries — far more relevant than generic scans when specific attack vectors and threat actors are known.

Other CISSP domains

• Security and Risk Management — 89 questions →
• Security Architecture and Engineering — 87 questions →
• Communication and Network Security — 63 questions →
• Identity and Access Management (IAM) — 63 questions →
• Software Development Security — 59 questions →
• All 497 CISSP questions →