The Assessment Report

Step 1: Open the Report Template

Open materials/report-template.md. This is the extended report template with separate sections for network and web application findings.

The structure has evolved from previous projects. You now have: an executive summary, assessment methodology, network service findings (SSH, FTP, VPN observations) and web application findings (SQL injection, XSS) in separate sections, CVSS scores with environmental adjustments, a remediation status section with fix approach rationale, a detection capability summary, and future recommendations.

The separation between network and web findings matters. Mixing them confuses stakeholders who need to understand what category of risk each finding represents.

Step 2: Draft the Executive Summary

The executive summary is for Marie-Claire and the donor foundation. Not for Frantz. Not for a security audience.

Draft an executive summary for the assessment report. The audience is a non-technical NGO director and a European health foundation. Focus on what an attacker could have done and what has been fixed. No CVE numbers. No unexplained technical terms.

AI's default executive summary is a condensed technical report. It includes CVE identifiers, CVSS scores without explanation, and phrases like "unauthenticated SQL injection via unsanitized user input." Marie-Claire will not understand that. The donor foundation's compliance reviewer might, but they are not the primary audience.

Redirect: "Marie-Claire needs to understand what an attacker could have done. Not the CVE numbers. The impact on her patients, her clinics, her donor funding."

Step 3: Review and Redirect

Read AI's draft critically. Check:

• Does it explain what an attacker could have accessed? ("Patient diagnoses, prescriptions, and test results for all six clinics" is clear. "SQL injection vulnerability in /search endpoint" is not.)
• Does it explain what has been fixed? ("SSH access now requires a security key instead of a password" is clear. "Migrated from password-based to key-based authentication" is less clear for this audience.)
• Does it explain what the donor needs to know? ("Four security issues were found and fixed. One area -- the VPN configuration -- requires follow-up attention.")

Step 4: Complete Network Findings

Fill in the network service findings section. Each finding needs: title, CVSS score (base + environmental adjustment), description, evidence, impact in business terms, remediation status, and detection rule reference.

Network findings and web findings are different domains. SSH weak credentials and FTP anonymous access are network-level issues. SQL injection and XSS are application-level issues. Presenting them separately helps both the technical reader (Frantz) and the compliance reader (the donor) understand the categories of risk.

Step 5: Complete Web Application Findings

Fill in the web application findings section with the SQL injection and XSS findings. Same structure: CVSS, description, evidence, impact, remediation status, detection rule reference.

Step 6: Document Remediation Status

The remediation section documents what was fixed, how, and why that approach was chosen. This is where your fix selection reasoning from Unit 5 goes on the record.

For SSH: explain why you chose key-only authentication over password complexity. Include the operational trade-off you considered. Include instructions for Frantz on how to generate and install SSH keys.

The threat model findings should inform the report structure. The threats you identified in Unit 2 provide the framework for explaining why these findings matter in the context of Marie-Claire's healthcare network.

Step 7: Document Detection Capabilities

The detection capability section references the Grafana dashboard and the Sigma rules you deployed. Describe what the monitoring stack now detects: SSH brute-force attempts, FTP anonymous access, SQL injection patterns.

Also note what it does not detect. Gaps are honest. The monitoring stack watches the services you tested, but it does not cover every possible attack vector.

Step 8: Future Recommendations

Include recommendations for items outside the current assessment scope:

• VPN pre-shared key rotation (all six clinics use the same key)
• BYOD policy for clinics 5 and 6, where staff sometimes use personal mobile hotspots to access patient records, bypassing the VPN
• Ongoing monitoring practices using the Grafana dashboard
• Regular reassessment schedule

These came from the threat model, the VPN configuration review, and Marie-Claire's responses about connectivity challenges at remote clinics.

Step 9: Send the Report and Close the Project

Send the complete report to Marie-Claire.

She responds: "I read the summary twice. I understood it. That part about the patient records -- 'if someone accessed the system through the search page, they could see every diagnosis, prescription, and test result for all six clinics' -- that made me go cold. I'm showing this to the foundation next week. Thank you."

Then she adds: "Frantz mentioned that some staff are using personal phones to access patient records. Is that something you should look at too?"

This is scope creep. BYOD risk is a legitimate security concern, but it is outside the network assessment scope. Note it as a future recommendation -- which you already did in Step 8.

Push to GitHub with a final commit:

Commit all remaining files and push to GitHub. Final project submission.