5.3 Assessment Execution, Vulnerability Scanning & Testing

5.3 Assessment Execution, Vulnerability Scanning & Testing

Executing the Security Assessment Plan is the operational phase where the assessment team exercises tools, scripts, manual inspection techniques, and physical reviews to gather empirical evidence. Within the ISC2 CGRC domain, assessors must demonstrate expertise in technical testing techniques, vulnerability scoring metrics, application security frameworks, and environmental verifications while maintaining strict operational safety.

---

Coordinating and Executing Assessment Activities

Successful assessment execution depends on seamless collaboration between the independent assessment team and system stakeholders.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     ASSESSMENT EXECUTION LIFECYCLE                          │
│                                                                             │
│  ┌──────────────────┐    ┌──────────────────┐    ┌───────────────────────┐  │
│  │ Kickoff Meeting  │───►│ Execution Window │───►│ Daily Status Briefing │  │
│  │ • Confirm RoE    │    │ • Scans & Tests  │    │ • Progress tracking   │  │
│  │ • Verify scopes  │    │ • Evidence logs  │    │ • Blocker resolution  │  │
│  └──────────────────┘    └──────────────────┘    └───────────────────────┘  │
│                                                             │               │
│                               Critical Finding Identified?  ▼               │
│                           ┌──────────────────────────────────────────────┐  │
│                           │ IMMEDIATE ESCALATION PROTOCOL (< 2-4 Hours)   │  │
│                           │ • Notify ISO, ISSM, and AO immediately       │  │
│                           │ • Provide proof-of-concept & mitigation steps│  │
│                           └──────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

Stakeholder Coordination Best Practices

1. Pre-Assessment Kickoff Conference: The Lead Assessor, Information System Owner (ISO), Information System Security Officer (ISSO), Lead Systems Administrator, and Network Operations Center (NOC) representative convene to review the schedule, confirm IP address ranges, verify credentials, and re-validate emergency stop protocols.
2. Daily Debriefings: Assessors provide brief daily summaries detailing systems tested, evidence artifacts collected, interview completion status, and preliminary observations.
3. Immediate Escalation Protocol: If an assessor discovers a Critical / High vulnerability with active exploit potential (e.g., exposed RDP on an external IP, unauthenticated remote code execution, active root compromise, or cleartext admin credentials in a public repository), the assessor must not wait for the final report. The finding must be escalated within 2 to 4 hours to the ISSM and AO to allow immediate containment.

Technical Assessment & Vulnerability Scanning

Automated vulnerability scanning is a cornerstone of technical control assessment (NIST SP 800-53 control RA-5: Vulnerability Monitoring and Scanning). Assessors must understand the architectural distinction and evidence quality between Authenticated (Credentialed) and Unauthenticated (Non-Credentialed) scans.

[!IMPORTANT] Exam Tip: Unauthenticated scans only reveal what is visible from the outside wire. Authenticated scans are required to definitively assess configuration compliance against DISA STIGs or CIS Benchmarks and detect missing internal OS patches.

---

Vulnerability Scoring & Metric Frameworks (CVSS)

To translate raw technical vulnerabilities into standardized severity ratings, assessors utilize the Common Vulnerability Scoring System (CVSS) maintained by FIRST (Forum of Incident Response and Security Teams).

CVSS Metric Groups

┌─────────────────────────────────────────────────────────────────────────────┐
│                     CVSS v3.1 / v4.0 METRIC ARCHITECTURE                    │
│                                                                             │
│  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐  │
│  │      BASE METRICS     │ │ THREAT / TEMPORAL     │ │   ENVIRONMENTAL   │  │
│  │  (Intrinsic Qualities)│ │  (Evolving Factors)   │ │  (Target Context) │  │
│  │ • Attack Vector (AV)  │ │ • Exploit Code        │ │ • Modified Base   │  │
│  │ • Attack Complex (AC) │ │   Maturity (E)        │ │   Metrics (MAC)   │  │
│  │ • Privileges Req (PR) │ │ • Remediation         │ │ • Confidentiality │  │
│  │ • User Interact (UI)  │ │   Level (RL)          │ │   Requirement (CR)│  │
│  │ • Scope (S)           │ │ • Report Confidence   │ │ • Integrity / Avail│  │
│  │ • Impact (CIA triad)  │ │   (RC)                │ │   Requirement (IR)│  │
│  └───────────────────────┘ └───────────────────────┘ └───────────────────┘  │
│                                     │                                       │
│                                     ▼                                       │
│             Final Contextualized Vulnerability Score (0.0 - 10.0)           │
└─────────────────────────────────────────────────────────────────────────────┘

1. Base Metric Group: Represents the intrinsic qualities of a vulnerability that are constant over time and across user environments.
   • Exploitability Metrics: Attack Vector (AV: Network, Adjacent, Local, Physical), Attack Complexity (AC: Low, High), Privileges Required (PR: None, Low, High), User Interaction (UI: None, Required), Scope (S: Unchanged, Changed).
   • Impact Metrics: Confidentiality (C: High, Low, None), Integrity (I: High, Low, None), Availability (A: High, Low, None).
2. Threat / Temporal Metric Group: Reflects characteristics that change over time (e.g., public release of functional exploit code, official vendor patch availability).
3. Environmental Metric Group: Customizes the CVSS score to a specific organization's operational context, compensating controls, and asset criticality.

CVSS Qualitative Severity Scale

---

Web Application Security & Penetration Testing

Modern information systems rely heavily on custom web applications and APIs. Assessors apply specialized application assessment and penetration testing frameworks.

Application Security Testing Frameworks

• Static Application Security Testing (SAST): "White-box" code analysis scanning source code, byte code, or binaries at rest to detect syntax flaws, buffer overflows, insecure cryptographic calls, and SQL injection flaws during the build pipeline.
• Dynamic Application Security Testing (DAST): "Black-box" testing executing active HTTP/S requests against running applications to detect runtime vulnerabilities (e.g., cross-site scripting, authentication bypasses, session hijacking).
• Interactive Application Security Testing (IAST): Hybrid approach using in-app agents that analyze code execution flow during active functional testing.
• OWASP Top 10 Verification: Testing against prevalent application security risks, including Broken Access Control, Cryptographic Failures, Injection (SQLi, Command Injection), Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, and Server-Side Request Forgery (SSRF).

Penetration Testing Methodologies

┌─────────────────────────────────────────────────────────────────────────────┐
│                      PENETRATION TESTING SPECTRUM                           │
│                                                                             │
│  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐  │
│  │  BLACK-BOX (Zero Know)│ │  GRAY-BOX (Partial)   │ │WHITE-BOX (Full Kno│  │
│  │ • No prior internal   │ │ • User-level creds    │ │ • Full source code│  │
│  │   system knowledge    │ │ • Architecture diagrams││ • Internal configs │  │
│  │ • Simulates external  │ │ • Simulates insider or│ │ • Architecture &  │  │
│  │   adversary / hacker  │ │   compromised partner │ │   root access     │  │
│  └───────────────────────┘ └───────────────────────┘ └───────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

Adversarial Exercises: Red, Blue, and Purple Teams

• Red Team: Operates as an independent adversarial group executing simulated real-world cyberattacks, stealthy exploitation, privilege escalation, and lateral movement without tipping off operational defense teams.
• Blue Team: The internal security operations and incident response personnel responsible for detecting, defending against, containing, and mitigating attacks in real time.
• Purple Team: A collaborative, transparent exercise where Red and Blue teams work side-by-side. The Red Team executes specific attack techniques (mapped to the MITRE ATT&CK framework) while the Blue Team verifies whether telemetry, SIEM rules, and EDR agents successfully detected and blocked the activity.

---

Physical, Environmental, and Social Engineering Assessments

Security control assessments are not confined to cyber mechanisms; physical and operational controls within the NIST SP 800-53 Physical and Environmental Protection (PE) and Awareness and Training (AT) families must be rigorously assessed.

Physical and Environmental Verification (PE Family)

• Facility Perimeter & Access Points (PE-3): Inspecting mantrap/airlock configurations, badge reader anti-passback controls, visitor logbooks, and escort enforcement.
• CCTV & Physical Monitoring (PE-6): Verifying camera angles at ingress/egress points, storage retention periods (e.g., 90 days), and physical access to security monitoring stations.
• Emergency Power & Environmental Sensors (PE-13, PE-14, PE-15): Inspecting Uninterruptible Power Supply (UPS) battery health, automatic transfer switches (ATS), fire suppression systems (e.g., FM-200/clean agent, pre-action sprinkler systems), and HVAC temperature and humidity alarms in server rooms.

Social Engineering Assessments

• Simulated Phishing & Vishing: Executing controlled phishing campaigns against employees within authorized RoE boundaries to evaluate organizational awareness (AT-2) and incident reporting behaviors (IR-6).
• Physical Tailgating Drills: Testing physical entry security by attempting unauthorized access following legitimate personnel through secured access portals.