Remediation and Fix Selection

Step 1: Prioritize findings with CVSS and environmental context

Review the findings from Unit 4. Each finding has a CVSS base score. List them. The natural instinct -- and AI's default -- is to rank by score and fix from highest to lowest.

That ranking is wrong for this environment.

A CVSS 9.8 on the internal database port, reachable only through the VPN, matters less than a CVSS 6.5 on the internet-facing EHR login page where patient records are directly exposed. The CVSS score tells you the severity of the vulnerability in abstract. The environmental context tells you the severity for this system: who can reach it, what data it protects, and what happens if it is compromised.

Direct Claude to produce two prioritized lists: one ranked by CVSS score alone, and one ranked by your environmental assessment. Compare them. They should not be the same. If they are, you are not applying environmental reasoning.

The patient data elevates every finding. A vulnerability that exposes names and email addresses is one thing. A vulnerability that exposes HIV diagnoses, mental health records, and pregnancy status in a community where 350,000 people depend on these clinics is another.

Step 2: Fix the SSH credential weakness

Start with the SSH finding. You brute-forced these credentials with Hydra in Unit 4. You know exactly how fast they fell.

Direct Claude to remediate the weakness. AI will commonly default to password complexity rules -- requiring longer passwords, special characters, rotation. That raises the bar. It does not remove the attack.

You have another option: key-only authentication. Disable password-based SSH entirely. If the only way to authenticate is with a cryptographic key, brute-forcing is impossible. Not harder. Impossible.

The fix selection is a judgment call. Both approaches are legitimate. Password complexity and key-only auth solve the same problem differently. Your experience with Hydra -- watching it crack the credentials in minutes -- gives you information AI does not have about which approach is more appropriate for this system.

Step 3: Verify the fix and the service

Re-run Hydra against SSH. If key-only authentication is correctly implemented, the result should show zero valid passwords found.

Then verify the service still works. Can Frantz SSH into the server using a key? Is the service accessible and functional?

AI sometimes "fixes" a vulnerability by breaking the service it runs on. Disabling SSH entirely when the task was key-only authentication is secure in a narrow sense -- the vulnerability is gone because the service is gone. But Marie-Claire's IT person needs SSH to manage six clinics. A fix that eliminates the service is not a fix.

Both tests must pass: the exploit fails, and the service works.

Step 4: Remediate remaining findings

Work through the remaining findings in your environmentally-adjusted priority order. For each finding:

1. Choose the remediation approach. Consider the alternatives. Document why you chose this one.
2. Implement the fix.
3. Re-run the original exploit. It should fail.
4. Verify the service still functions normally.

Direct Claude to implement each fix, but make the approach decision yourself. AI defaults to common remediation patterns regardless of system context. The fix that is right for a clinic network serving 200 patients a day may differ from the generic recommendation.

Review the materials/ttp-selection-guide.md for context on what each testing category was designed to find, and ensure your fixes address the root vulnerability, not just the symptom.

Step 5: Continue container hardening

The Docker containers need the same attention as P3. Non-root USER in the Dockerfile. Read-only filesystem where feasible. These are carry-forward practices.

Direct Claude to harden the containers. Verify each change: the container still runs, the application still serves requests, and the security improvement is measurable (the container runs as a non-root user, the filesystem is read-only where appropriate).

Step 6: Document remediation decisions

For each finding, document: what was changed, why this approach was chosen over alternatives, what attack it addresses, and the verification result (exploit fails, service works).

This documentation feeds directly into the report. The fix selection rationale is a key section in the report template -- the donor wants to see not just that problems were found and fixed, but that the fixes were chosen with judgment, not applied blindly.