Geek-Guy.com

Domain 6: Security Assessment and Testing

Exam Weight: 12%

Domain 6 is about verifying the truth. While other domains focus on building and operating security, this domain focuses on proving that those controls actually work. It bridges the gap between technical testing and management-level auditing.


1. Security Assessment vs. Auditing

You must distinguish between these three terms, as the exam often uses them interchangeably in ways that require a nuanced understanding:

  • Assessment: A broad review of a system’s security posture. It identifies vulnerabilities but doesn’t necessarily exploit them.
  • Testing: The actual technical execution of a check (e.g., a port scan or a vulnerability scan).
  • Auditing: A formal, independent review against a specific standard (e.g., SOC 2, PCI-DSS). The goal is to provide reasonable assurance to stakeholders.
    • Internal Audit: Performed by the organization (Self-assessment).
    • External Audit: Performed by a third party (Increased objectivity).

2. Vulnerability Assessment and Penetration Testing (VAPT)

  • Vulnerability Assessment: A search for known weaknesses using automated tools (e.g., Nessus, OpenVAS). It results in a list of vulnerabilities and their severity.
  • Penetration Testing (Ethical Hacking): A step further—attempting to exploit vulnerabilities to see how far an attacker could get.
    • Phase 1: Planning/Reconnaissance (Passive vs. Active).
    • Phase 2: Scanning/Enumeration (Finding entry points).
    • Phase 3: Gaining Access (Exploitation).
    • Phase 4: Maintaining Access (Persistence).
    • Phase 5: Analysis/Reporting (The most important step for a CISSP).

Test Types:

  • Black Box: No prior knowledge of the system. (Simulates an external attacker).
  • White Box: Full knowledge of the system (Source code, architecture).
  • Gray Box: Partial knowledge (Simulates an insider or partner).

3. Software Security Testing

Since you have a professional interest in secure coding and DSPM, this section is vital:

  • Static Analysis (SAST): Testing the source code while it is not running. It finds bugs early in the SDLC.
  • Dynamic Analysis (DAST): Testing the application while it is running. It finds vulnerabilities like memory leaks and configuration issues.
  • Fuzzing: Sending random, malformed data to an application to see if it crashes or reveals a vulnerability.
  • Unit Testing: Testing individual components or modules.
  • Regression Testing: Testing after a change to ensure that new code hasn’t broken existing security features.

4. Security Control Testing

  • Log Reviews: Ensuring that systems are actually recording the events they are supposed to.
  • Synthetic Transactions: Simulating user behavior to test if an application is performing correctly and securely.
  • Misuse Case Testing: Specifically testing what a system is not supposed to do (e.g., Can a user bypass the paywall?).
  • Code Review/Peer Review: Having another human look at the code to find logic errors that automated tools might miss.

5. Reporting and Remediation

A test is useless if it doesn’t lead to change.

  • Key Performance Indicators (KPIs): Metrics that show how well the security program is working over time.
  • Vulnerability Remediation: Prioritizing fixes based on risk (Asset Value × Vulnerability Severity).
  • Management Reporting: Summarizing technical findings into business risk so executives can allocate budget for fixes.