Remediation and Fix Selection

Step 1: Inventory the Findings

Before remediating anything, organize what you found. You have evidence of multiple vulnerabilities across different service types:

• FTP anonymous access exposing patient data CSVs
• SSH weak credentials (brute-forced with Hydra)
• EHR web application SQL injection in /search
• EHR web application stored XSS in /records clinical notes

Each finding has a different severity, different impact, and different remediation options. The first task is to see them as a set, not as individual items.

Step 2: CVSS Scoring with Environmental Context

Open materials/report-template.md and read the CVSS Score Guide section. CVSS gives you a standardized way to score vulnerability severity, but the base score alone does not tell the full story.

Direct Claude to score each finding:

Score each of our findings using CVSS. Include the base score and explain what environmental adjustments apply given that this is a healthcare system with patient health records.

AI assigns base scores without environmental adjustment. It reports a CVSS 9.8 for SQL injection and a CVSS 7.5 for weak SSH credentials as raw numbers. But context changes the picture. SQL injection in this system exposes patient HIV diagnoses, pregnancy records, and prescriptions -- that raises the effective confidentiality impact. FTP anonymous access to patient summary CSVs is not just a file disclosure; it is a health data breach.

A vulnerability on a service nobody uses is less urgent than a vulnerability on the primary patient-facing application, regardless of what the base score says. The numbers are inputs to judgment, not substitutes for it.

Step 3: Prioritize by Environmental Context

Decide what to fix first. The priority order should reflect what the system is, who it serves, and what data is at stake -- not just the raw CVSS numbers.

Consider: SQL injection that exposes every patient record in the database, or SSH weak credentials that give terminal access to the server? Both are serious. The SQL injection is directly exploitable through the web interface. The SSH access requires credential guessing. But SSH access to the server could lead to everything the SQL injection exposes and more.

Make the call and document your reasoning. There is no single right answer here -- what matters is that the reasoning is explicit and grounded in the system's context.

Step 4: Remediate SSH Credentials

This is the key fix selection moment. AI defaults to one approach -- usually password complexity rules. But you just brute-forced these credentials with Hydra. You know exactly what the attack looks like.

Three viable approaches:

Password complexity rules: Require longer, more complex passwords. This raises the bar for brute-forcing but does not eliminate the vector. Hydra with a larger dictionary still works.

Key-only authentication: Disable password authentication entirely. Require SSH key pairs. This eliminates the brute-force vector completely. Frantz would need to generate a key pair and install it.

Fail2ban or rate limiting: Block IPs after a threshold of failed attempts. This mitigates brute-forcing but does not fix the underlying weak credential. A slow, distributed attack could still succeed.

Each addresses a different aspect of the problem at different implementation costs. The choice depends on operational context: Frantz is a solo IT administrator managing six clinics. He connects via SSH from the Cap-Haitien office. Key-only authentication is stronger, but password access may be needed when Frantz is at a remote clinic without his key file.

Make the decision. Direct Claude to implement it:

Implement key-only SSH authentication. Disable password authentication in the SSH server configuration.

Step 5: Remediate FTP Anonymous Access

Disable anonymous FTP access. Patient data should never be accessible without authentication.

Disable anonymous FTP access on the FTP server. Only authenticated users should be able to connect.

Step 6: Remediate Web Application Vulnerabilities

Direct Claude to fix the SQL injection in the /search endpoint and the stored XSS in the clinical notes display.

Fix the SQL injection vulnerability in the EHR application's /search endpoint. Use parameterized queries, not string escaping.

AI commonly generates fixes that use escape functions instead of prepared statements, or that disable the feature entirely. A fix that eliminates the search feature to prevent SQL injection is not a fix -- it is a denial of service committed by the defender. Verify that the search still works after the fix is applied.

For the XSS vulnerability, the fix involves removing the | safe filter from the template rendering of clinical notes, or sanitizing the input before storage.

Step 7: Verify Every Fix

Re-run each exploit after remediation.

Test the SSH brute-force with Hydra again after the remediation. Then test FTP anonymous access. Then test the SQL injection and XSS payloads.

Hydra should fail against SSH. FTP anonymous connections should be denied. SQL injection payloads should return no results. XSS payloads should render as text, not execute as JavaScript.

Step 8: Verify Service Functionality

After all fixes, verify that every service still works for its intended purpose.

Can Frantz still SSH in with the new authentication method? Can authorized users access FTP? Does the EHR search return patient records for legitimate queries? Does the clinical notes feature still display notes?

AI may "fix" SSH by disabling the service entirely, or set file permissions so restrictive the application cannot read its own database. Check that the system still serves its intended purpose.