Security Control Testing Methods

From Strategy to Execution

Module 38 covered how to design an assessment program. This module covers the specific methods you deploy within that program. The distinction matters for the exam: strategy questions ask you to choose what kind of assessment to run; methods questions ask you to choose how to execute it.

A vulnerability scan tells you the door might be unlocked. A penetration test opens it and walks through. Code review examines whether the lock was installed correctly in the first place.

This module covers CISSP exam objective 6.2: conduct security control testing. The focus is on understanding when each method is appropriate, what it can and cannot tell you, and how different methods complement each other in a layered testing strategy.

Vulnerability Scanning

Vulnerability scanning is the broadest and most frequent form of security testing. Scanners compare system configurations, software versions, and exposed services against databases of known vulnerabilities.

Authenticated vs. Unauthenticated Scans

• Unauthenticated scans — The scanner has no credentials and sees only what an external attacker would see. These scans identify externally visible vulnerabilities but miss anything behind a login or firewall. They produce more false negatives because they cannot inspect installed software or configuration files.
• Authenticated scans — The scanner logs into systems using provided credentials and examines installed software, patch levels, configuration settings, and file permissions from the inside. Authenticated scans are significantly more accurate and produce far fewer false negatives. They should be the standard for internal scanning.

Agent-Based vs. Network-Based Scans

• Network-based scans — A central scanner probes targets across the network. Simple to deploy, but can only see systems on reachable network segments. Laptops that are off-network (remote workers, travel) are invisible to network-based scanners.
• Agent-based scans — A lightweight agent installed on each system performs local vulnerability checks and reports results to a central console. Agents work regardless of network location, catching vulnerabilities on remote and mobile devices. The tradeoff is deployment and maintenance overhead for the agents themselves.

The exam tests your ability to select the right scanning approach. Remote workforce with laptops off the corporate network? Agent-based. Quick external perimeter check? Unauthenticated network scan. Internal compliance validation? Authenticated network scan.

Penetration Testing Methodologies

Penetration testing goes beyond scanning by attempting actual exploitation. The methodology defines how the testers approach the target.

Knowledge-Level Approaches

• Black box (zero knowledge) — Testers receive no information about the target environment. They simulate an external attacker who must discover everything independently. This tests detection capabilities and external defenses, but it is time-intensive and may miss internal vulnerabilities.
• White box (full knowledge) — Testers receive complete documentation: architecture diagrams, source code, credentials, network maps. This is the most thorough approach because testers spend time finding vulnerabilities instead of discovering infrastructure. White box tests are most efficient for maximizing coverage within a fixed timeline.
• Gray box (partial knowledge) — Testers receive some information, typically network ranges and user-level credentials. This simulates an insider threat or a compromised user account. Gray box testing balances realism with efficiency.

Penetration Testing Frameworks

• PTES (Penetration Testing Execution Standard) — Defines seven phases: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. PTES provides a structured methodology for general penetration testing engagements.
• OWASP Testing Guide — Focused specifically on web application security testing. It defines test categories aligned with the OWASP Top 10 and provides detailed procedures for testing each category. When the scenario involves web application testing, OWASP is the expected framework reference.

Code Review and Application Security Testing

Code-level testing catches vulnerabilities before they reach production. Three approaches operate at different stages of the development lifecycle.

• SAST (Static Application Security Testing) — Analyzes source code, bytecode, or binaries without executing the application. SAST finds vulnerabilities in the code itself: injection flaws, buffer overflows, hardcoded credentials, insecure cryptographic implementations. It runs early in the development pipeline, often integrated into the IDE or CI/CD process. Limitation: SAST produces high false positive rates because it cannot understand runtime context.
• DAST (Dynamic Application Security Testing) — Tests the running application from the outside, sending crafted inputs and analyzing responses. DAST finds runtime vulnerabilities: authentication flaws, session management issues, server misconfigurations. It does not require source code access. Limitation: DAST cannot pinpoint the exact line of code causing the vulnerability.
• IAST (Interactive Application Security Testing) — Combines elements of both by placing agents or sensors within the running application. IAST monitors code execution in real time, correlating external inputs with internal code paths. It reduces false positives compared to SAST and identifies exact code locations better than DAST. Limitation: requires a running application with instrumentation, adding complexity to the test environment.

The exam expects you to match the testing method to the scenario. Early in development with access to source code? SAST. Running application without source code? DAST. Need the accuracy benefits of both? IAST.

Interface Testing

Systems communicate through interfaces, and each interface is a potential attack surface that needs testing.

• API testing — Tests the security of application programming interfaces: authentication, authorization, input validation, rate limiting, error handling, and data exposure. APIs are a frequent attack vector because they often expose more functionality than the user interface. Test for broken object-level authorization, excessive data exposure, and missing rate limits.
• UI testing — Validates that the user interface enforces security controls correctly. Are sensitive fields masked? Do client-side controls match server-side enforcement? Can UI elements be manipulated to bypass access controls? UI testing ensures that what the user sees reflects the actual security state.
• Physical interface testing — Evaluates physical ports, console access, and hardware interfaces. USB ports, serial connections, and maintenance interfaces can provide unauthorized access if not properly secured. Physical interface testing is particularly relevant for IoT devices, industrial control systems, and kiosk deployments.

Misuse Case Testing

Standard testing validates that the system works correctly when used as intended. Misuse case testing validates that the system fails safely when someone deliberately tries to abuse it.

A misuse case describes:

• An actor with malicious intent (insider, external attacker, compromised account)
• An action that abuses the system’s intended functionality
• The expected defensive response

For example: “A user with standard privileges attempts to modify another user’s account settings by changing the user ID parameter in the URL.” The expected response is that the application rejects the request and logs the attempt. Misuse case testing verifies this actually happens.

This testing approach is especially valuable because it forces the development team to think from the attacker’s perspective during the design phase, not just after deployment.

Additional Testing Methods

Test Coverage Analysis

Test coverage measures how much of the codebase or environment has been tested. High coverage does not guarantee security, but low coverage guarantees blind spots. Coverage metrics include code path coverage, feature coverage, and attack surface coverage. The goal is not 100% coverage — it is informed decisions about what remains untested and whether the residual risk is acceptable.

Regression Testing

When a vulnerability is remediated, regression testing verifies that the fix works and that it did not introduce new vulnerabilities or break existing functionality. Regression testing is also essential after any system change to confirm that previously validated security controls still operate correctly.

Synthetic Transactions

Synthetic transactions are scripted, automated interactions that simulate real user behavior against production systems. They continuously verify that authentication works, authorization rules are enforced, and expected responses are returned. When a synthetic transaction fails, it indicates a control may have degraded or a system may have changed. This serves as a form of continuous security monitoring.

Breach Attack Simulation (BAS)

BAS platforms automate the simulation of known attack techniques across the kill chain — from initial access through lateral movement to data exfiltration. Unlike periodic penetration tests, BAS runs continuously and tests whether detective and preventive controls respond correctly to specific attack patterns. It validates that your SIEM rules fire, your endpoint detection catches payloads, and your network controls block lateral movement as expected.

Pattern Recognition

Control testing questions on the CISSP follow these structures:

• Method selection — A scenario describes a testing need, and you choose the appropriate method. Match the testing phase (pre-deployment vs. production), the available information (source code vs. running application), and the testing objective (breadth vs. depth).
• Complementary methods — The question asks which method would address a gap left by another. SAST finds code issues but misses runtime problems — add DAST. Network scans miss remote laptops — add agent-based scanning.
• Scan type selection — The scenario describes an environment (internal, external, remote) and you choose the right scanning approach.
• Testing box color — The question describes what information testers have and you identify whether the approach is black, white, or gray box.

Trap Patterns

Watch for these wrong answers:

• “SAST replaces the need for DAST” — They test different things. SAST examines code structure; DAST examines runtime behavior. Neither replaces the other.
• “Vulnerability scanning is the same as penetration testing” — Scanning identifies potential vulnerabilities. Penetration testing attempts exploitation. They are different activities with different scopes and risk profiles.
• “Black box testing is always more valuable because it simulates a real attacker” — Black box is realistic but inefficient. White box testing finds more vulnerabilities in less time because testers are not spending time on reconnaissance.
• “Unauthenticated scans provide complete visibility” — Unauthenticated scans see only what is externally visible. They miss vulnerabilities that require login or local access to detect.

Scenario Practice

Question 1

A development team is building a new web application. The security team wants to identify coding flaws such as SQL injection and cross-site scripting vulnerabilities as early as possible in the development lifecycle, before the application is deployed to a test environment.

Which testing method is MOST appropriate?

A. DAST
B. SAST
C. Penetration testing
D. IAST

Question 2

An organization has 2,000 employees, 40% of whom work remotely full-time and rarely connect to the corporate VPN. Quarterly vulnerability scans using a network-based scanner consistently show only 1,200 systems. Security leadership suspects the remote devices have significant unpatched vulnerabilities.

What is the BEST approach to close this visibility gap?

A. Require remote employees to connect to VPN during scan windows
B. Deploy agent-based vulnerability scanning to all endpoints
C. Increase the frequency of network-based scans to weekly
D. Accept the risk of unscanned remote devices

Question 3

A security team recently patched a critical authentication bypass vulnerability in the organization’s customer portal. The patch was applied to production on Friday and verified working on Monday. By Wednesday, the portal team deployed a new feature release that inadvertently reintroduced the same authentication flaw.

What testing practice would have prevented this?

A. More frequent penetration testing
B. Regression testing as part of the deployment pipeline
C. Switching from DAST to IAST
D. Implementing breach attack simulation

Key Takeaway