TTP-Scoped Active Scanning

Step 1: Select TTPs from the threat model

Open the threat model you built in Unit 2. The STRIDE categories contain cooperative-specific threats -- spoofing on the export tracker, tampering with fermentation readings, information disclosure through the shipping API, and more.

Each threat implies specific techniques an attacker would use. SQL injection against the export tracker's search endpoint. Unauthenticated API access to the fermentation sensor data. Credential reuse from stale member portal accounts. These are the TTPs your active scanning should target.

The shift here is fundamental. In previous projects, scanning meant running tools against everything and reviewing what came back. TTP-scoped reconnaissance means scanning what the threat model says matters. The threat model drives the tools, not the other way around.

Based on the STRIDE threat model, identify the top 3-5 attack techniques to test. For each, specify which tool (Nmap, ZAP, or Nuclei) is best suited and which target service to scan. Don't run comprehensive scans -- scope each scan to the specific TTP.

AI will default to comprehensive scanning if you let it. A prompt like "scan the cooperative's infrastructure" produces a broad sweep of everything. You want targeted scans against specific services for specific vulnerabilities. Redirect if AI expands beyond the threat model's priorities.

Step 2: Run Nmap service enumeration

Run Nmap against the in-scope services to map service versions, open ports, and running software. The goal is specific identification -- not just "port 3000 is open" but "port 3000 is running Node.js/Express with a specific version."

nmap -sV -sC -p 3000,5000,8080,4000,6000 localhost

The service version data becomes the baseline for cross-tool correlation. When Nuclei later matches a CVE template, you need to check whether the actual service version is affected. When ZAP reports a web vulnerability, the service version tells you which technology stack to investigate.

Document the Nmap results. Note which services expose what. The fermentation API on port 8080, the member portal on port 5000, the export tracker on port 3000 -- each has a different technology stack and a different risk profile.

Step 3: Run ZAP targeted web scanning

Configure ZAP to scan the web-facing applications -- the export tracker and the member portal -- scoped to the threat model's priorities.

This is not a full active scan of everything ZAP can test. If the threat model prioritizes information disclosure and SQL injection against the export tracker, configure ZAP to focus on those attack vectors. If it prioritizes authentication weaknesses on the member portal, target the login and session management.

Configure ZAP to scan the export tracker (port 3000) for SQL injection and information disclosure vulnerabilities. Then scan the member portal (port 5000) for authentication and session management issues. Scope the scans to the threat model priorities -- don't run a full active scan.

ZAP will produce findings with confidence levels and risk ratings. These are hypotheses, not confirmations. A "High" confidence SQL injection finding still needs verification -- ZAP may have triggered a generic error page that looks like injection but is not.

Step 4: Run Nuclei template scanning

Nuclei uses templates -- predefined checks for known vulnerabilities and misconfigurations. Run it against the cooperative's services.

Run Nuclei against the cooperative's services using relevant templates. Focus on web application vulnerabilities, misconfigurations, and known CVEs that match the service versions Nmap identified.

A Nuclei template match means "this pattern is present." It does not mean "this vulnerability is confirmed and exploitable." A template designed to detect a specific CVE checks for response patterns. If the response pattern matches but the actual service version is not affected, you have a false positive.

Cross-reference every Nuclei finding against the Nmap service versions. If Nuclei reports a CVE that affects Express 4.17.1 but Nmap shows Express 4.18.2, verify whether the version is actually vulnerable before recording it as a confirmed finding.

AI commonly accepts all Nuclei findings without cross-tool verification. When you ask AI to summarize the scan results, it may present every template match as a confirmed vulnerability. The professional discipline is treating each match as a hypothesis that needs verification.

Step 5: Correlate and document findings

You now have results from three tools targeting the same infrastructure. Nmap shows service versions. ZAP shows web application vulnerabilities. Nuclei shows template matches. Bring them together.

For each finding, ask: do multiple tools describe the same vulnerability? If Nmap shows the export tracker running Express with SQLite, ZAP reports SQL injection on the search endpoint, and Nuclei matches a SQLite injection template -- those three findings describe the same attack path. That is a strong, correlated finding.

If Nuclei matches a template but ZAP did not find the same issue and Nmap shows a service version that should not be affected, that is likely a false positive. Document it as such. One verified, correlated finding is worth more than five unverified template matches.

Create a correlation table for all findings. For each finding, show: which tools reported it, the service and port, what each tool found, and the verification status (confirmed, likely false positive, needs manual verification). Reference the threat model STRIDE category the finding relates to.

Document at least one false positive explicitly. Explain why it is a false positive -- which tools disagree and what the evidence shows. This is not just good practice for the assessment report; it is evidence for the Portland buyer that the cooperative's assessment was thorough, not just a tool dump.

Update materials/threat-model-template.md with findings linked to the relevant STRIDE categories. The threat model is a living document -- it now includes evidence from active scanning.