CSY399 Week 10 - Week Content

Mental Model

"A penetration test is only as valuable as its report. The most thorough assessment means nothing if stakeholders can't understand, act on, and verify your findings." — Security Consulting Principle

The technical report is your primary deliverable—the document that justifies the engagement, communicates findings, and drives remediation. It must serve multiple audiences: executives who need the bottom line, security teams who need technical details, and developers who need to implement fixes.

Learning Outcomes

By the end of this week, you will be able to:

LO1: Structure a professional security assessment report for multiple audiences
LO2: Write clear, actionable vulnerability descriptions with appropriate technical depth
LO3: Document evidence and proof-of-concept demonstrations professionally
LO4: Create effective executive summaries that communicate business risk
LO5: Apply professional writing standards including clarity, accuracy, and appropriate tone

Introduction: The Deliverable That Matters

You've spent weeks assessing NovaTech's security posture. You've found vulnerabilities, exploited them to prove impact, analyzed risk, planned remediation, and designed architectural improvements. Now it all needs to come together in a document that:

Demonstrates the value of the assessment
Clearly communicates what was found
Provides actionable guidance for remediation
Serves as a record for compliance and audit purposes
Can be understood by both technical and non-technical readers

Why Report Quality Matters

┌─────────────────────────────────────────────────────────────────┐
│              REPORT QUALITY IMPACT                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  POOR REPORT                       EXCELLENT REPORT             │
│  ───────────                       ────────────────             │
│  • Findings misunderstood          • Clear understanding        │
│  • Remediation delayed             • Immediate action           │
│  • Value questioned                • ROI demonstrated           │
│  • Repeat assessments              • Trust established          │
│  • Professional reputation         • Future engagements         │
│    damaged                           earned                     │
│                                                                 │
│  The report IS the deliverable. A great assessment with a       │
│  poor report is a failed engagement.                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

1. Report Structure and Components

A professional security assessment report follows a standard structure that serves different audiences at different points in the document.

Standard Report Structure

┌─────────────────────────────────────────────────────────────────┐
│              SECURITY ASSESSMENT REPORT STRUCTURE               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. COVER PAGE                                                  │
│     └── Client, engagement, date, confidentiality              │
│                                                                 │
│  2. TABLE OF CONTENTS                                           │
│     └── Navigation for all sections                            │
│                                                                 │
│  3. EXECUTIVE SUMMARY (1-2 pages)          ◄── Executives      │
│     ├── Overall risk posture                                   │
│     ├── Key findings summary                                   │
│     ├── Business impact                                        │
│     └── Priority recommendations                               │
│                                                                 │
│  4. ENGAGEMENT OVERVIEW (1-2 pages)        ◄── All audiences   │
│     ├── Scope and objectives                                   │
│     ├── Methodology                                            │
│     ├── Timeline                                               │
│     └── Limitations                                            │
│                                                                 │
│  5. FINDINGS SUMMARY (2-3 pages)           ◄── Security team   │
│     ├── Findings by severity                                   │
│     ├── Findings by category                                   │
│     └── Risk matrix visualization                              │
│                                                                 │
│  6. DETAILED FINDINGS (bulk of report)     ◄── Technical team  │
│     └── Individual finding write-ups                           │
│                                                                 │
│  7. STRATEGIC RECOMMENDATIONS              ◄── Leadership      │
│     └── Architecture improvements                              │
│                                                                 │
│  8. APPENDICES                             ◄── Reference       │
│     ├── Methodology details                                    │
│     ├── Tool outputs                                           │
│     ├── Evidence files                                         │
│     └── Glossary                                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Audience Mapping

Section	Primary Audience	What They Need
Executive Summary	C-Suite, Board	Business risk, bottom line, decisions needed
Engagement Overview	All stakeholders	Context, scope, what was done
Findings Summary	CISO, Security Team	Prioritization, resource planning
Detailed Findings	Developers, IT Ops	Technical details, reproduction steps, fixes
Strategic Recommendations	CISO, CTO, Leadership	Long-term improvements, investment areas
Appendices	Technical teams, Auditors	Evidence, methodology, raw data

2. Writing the Executive Summary

The executive summary is often the only section leadership reads. It must communicate the essential message in 1-2 pages without requiring technical knowledge.

Executive Summary Components

1. Overall Assessment

One paragraph stating the overall security posture:

"SecureFirst Consulting conducted a comprehensive security assessment of NovaTech Solutions' infrastructure, web applications, and cloud environment between January 6-24, 2025. The assessment identified 3 critical, 5 high, 8 medium, and 12 low severity findings. The overall security posture is assessed as HIGH RISK, primarily due to vulnerabilities that could allow unauthorized access to customer data."

2. Key Business Risks

Translate technical findings into business language:

Key Business Risks Identified:

Customer Data Breach: Critical vulnerabilities in the WorkflowPro application could allow attackers to access the entire customer database, potentially affecting 50,000+ users and triggering GDPR breach notification requirements.

Supply Chain Compromise: Vulnerabilities in the CI/CD pipeline could allow attackers to inject malicious code into software deployed to enterprise customers.

Regulatory Non-Compliance: Multiple findings represent control deficiencies that may impact the upcoming SOC 2 Type II audit.

3. Critical Findings Highlight

Brief description of the most serious issues:

Critical Findings Requiring Immediate Attention:

Remote Code Execution on CI/CD Server: The Jenkins server is vulnerable to Log4Shell (CVE-2021-44228), allowing attackers to execute arbitrary code and access AWS credentials.

SQL Injection in Customer API: The customer search API is vulnerable to SQL injection, enabling complete database extraction.

Publicly Accessible Customer Data: An S3 bucket containing customer uploads is publicly accessible without authentication.

4. Recommended Actions

Clear guidance on what to do:

Recommended Actions:

Immediate (24-48 hours): Patch Log4j vulnerability, remediate public S3 bucket, rotate potentially compromised credentials.

Urgent (1-2 weeks): Fix SQL injection and XSS vulnerabilities in WorkflowPro application.

Short-term (30 days): Implement network segmentation, deploy secrets management, enable comprehensive security monitoring.

Strategic: Implement security architecture improvements detailed in Section 7 to prevent recurrence of similar issues.

Estimated Remediation Investment: 3-4 engineering sprints for immediate/urgent items; 2-3 months for architectural improvements.

Executive Summary Writing Tips

Lead with Impact, Not Technique

❌ Poor: "We found CVE-2021-44228 (Log4Shell) affecting the Log4j library version 2.14.1 on the Jenkins server."

✓ Good: "Attackers could take complete control of the CI/CD server, potentially compromising all software deployments to customers."

Quantify Where Possible

❌ Poor: "Customer data could be exposed."

✓ Good: "50,000+ customer records including names, emails, and workflow data could be exposed, potentially triggering GDPR fines of up to €10M or 2% of annual revenue."

Be Direct About Severity

❌ Poor: "Some issues were identified that should be addressed when convenient."

✓ Good: "Three critical vulnerabilities require immediate remediation within 48 hours to prevent potential data breach."

3. Writing Detailed Findings

Each finding requires a complete write-up that enables the reader to understand, verify, and remediate the issue.

Finding Write-up Template

┌─────────────────────────────────────────────────────────────────┐
│                 FINDING WRITE-UP STRUCTURE                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  HEADER                                                         │
│  ├── Finding ID (e.g., NOVA-2025-001)                          │
│  ├── Title (descriptive, specific)                             │
│  ├── Severity (Critical/High/Medium/Low)                       │
│  ├── CVSS Score (if applicable)                                │
│  └── CWE Reference (if applicable)                             │
│                                                                 │
│  AFFECTED RESOURCES                                             │
│  ├── System/Application name                                   │
│  ├── URL/IP address                                            │
│  ├── Component/Endpoint                                        │
│  └── Version (if relevant)                                     │
│                                                                 │
│  DESCRIPTION                                                    │
│  ├── What the vulnerability is                                 │
│  ├── Why it exists                                             │
│  └── Technical context                                         │
│                                                                 │
│  IMPACT                                                         │
│  ├── What an attacker could achieve                            │
│  ├── Business consequences                                     │
│  └── Data/systems at risk                                      │
│                                                                 │
│  PROOF OF CONCEPT                                               │
│  ├── Step-by-step reproduction                                 │
│  ├── HTTP requests/responses                                   │
│  ├── Commands executed                                         │
│  └── Screenshots/evidence                                      │
│                                                                 │
│  REMEDIATION                                                    │
│  ├── Recommended fix                                           │
│  ├── Implementation guidance                                   │
│  ├── Verification steps                                        │
│  └── References                                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Sample Finding Write-up

NOVA-2025-002 Critical CVSS 9.8

SQL Injection in Customer Search API

CWE-89: SQL Injection OWASP A03:2021 - Injection

Affected Resources

Application:	WorkflowPro API
Endpoint:	`POST /api/v1/customers/search`
Parameter:	`query`
Environment:	Production (api.workflowpro.io)

Description

The customer search API endpoint is vulnerable to SQL injection due to insufficient input validation and the use of string concatenation in database queries. User-supplied input in the query parameter is directly incorporated into SQL statements without sanitization or parameterization.

This vulnerability allows an authenticated attacker to execute arbitrary SQL commands against the backend PostgreSQL database, potentially extracting, modifying, or deleting data across all database tables.

Impact

Successful exploitation of this vulnerability could result in:

Complete Data Breach: Extraction of the entire customer database including names, email addresses, hashed passwords, and workflow data (~50,000 records)
Authentication Bypass: Extraction and cracking of password hashes could enable account takeover
Data Manipulation: Modification or deletion of customer data, affecting data integrity
Privilege Escalation: Potential modification of user roles to escalate privileges
Regulatory Impact: GDPR breach notification requirements; potential SOC 2 audit finding

Proof of Concept

The following steps demonstrate the vulnerability:

Step 1: Authenticate to the application and capture a valid session token.

Step 2: Send the following request to the search endpoint:

POST /api/v1/customers/search HTTP/1.1
Host: api.workflowpro.io
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json

{
  "query": "test' UNION SELECT username,password,email,NULL,NULL FROM users--"
}

Step 3: Observe the response containing user credentials:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "results": [
    {
      "name": "admin",
      "id": "$2b$10$X9G8KqZ...[password hash]",
      "email": "admin@novatech-solutions.com"
    },
    ...
  ]
}

Step 4: Automated exploitation using SQLMap confirmed full database access:

$ sqlmap -u "https://api.workflowpro.io/api/v1/customers/search" \
  --method POST --data '{"query":"test"}' \
  --headers="Authorization: Bearer [token]" \
  --dbms=postgresql --dump --batch

[INFO] the back-end DBMS is PostgreSQL
[INFO] fetching tables for database: 'workflowpro'
[INFO] found: users, customers, workflows, audit_logs, sessions

Evidence: Screenshots and full SQLMap output available in Appendix B.1.

Remediation

Recommended Fix:

Replace dynamic SQL construction with parameterized queries (prepared statements):

// VULNERABLE CODE (current):
const query = `SELECT * FROM customers WHERE name ILIKE '%${searchQuery}%'`;
const result = await db.query(query);

// SECURE CODE (recommended):
const query = 'SELECT * FROM customers WHERE name ILIKE $1';
const result = await db.query(query, [`%${searchQuery}%`]);

Additional Recommendations:

Implement input validation to reject special characters not needed for search functionality
Use an ORM with built-in query parameterization
Apply least-privilege database permissions for the application database user
Deploy WAF rules to detect and block SQL injection attempts

Verification:

Re-test the endpoint with the original payload; should return error or empty results
Run SQLMap against the endpoint; should report no injection found
Verify normal search functionality still works correctly

References:

Finding Severity Guidelines

Severity	Criteria	Examples
Critical	Remote code execution, complete data breach, authentication bypass affecting all users, actively exploited vulnerabilities	RCE, SQLi on production, public S3 with PII
High	Significant data exposure, privilege escalation, stored XSS affecting other users, missing critical security controls	Stored XSS, IDOR, missing MFA on admin
Medium	Limited data exposure, self-XSS, information disclosure, missing security headers, configuration weaknesses	Reflected XSS, missing headers, verbose errors
Low	Information disclosure with minimal impact, best practice deviations, theoretical vulnerabilities	Version disclosure, cookie without Secure flag

4. Documenting Evidence Professionally

Evidence transforms claims into facts. Professional evidence documentation allows readers to verify findings and provides audit trail for compliance.

Types of Evidence

Screenshots

Capture the moment of successful exploitation
Include relevant context (URL bar, timestamps)
Annotate to highlight key elements
Redact sensitive data (PII, actual credentials)

HTTP Requests/Responses

Full request including headers
Response showing vulnerability evidence
Format for readability (pretty-print JSON)
Truncate extremely long responses

Command Output

Show command and output together
Include timestamps where relevant
Truncate excessive output with notation
Highlight key information

Tool Reports

Scanner outputs (Nessus, Burp, Prowler)
Reference by finding ID
Include in appendix, reference in findings
Export in multiple formats (PDF, HTML, JSON)

Evidence Best Practices

Always Redact Sensitive Data

# WRONG - Exposing actual credentials
"password": "SuperSecret123!"
"api_key": "sk-live-aBcDeFgHiJkLmNoPqRsTuVwXyZ"

# CORRECT - Redacted
"password": "[REDACTED]"
"api_key": "sk-live-[REDACTED]"

# For partial demonstration
"password_hash": "$2b$10$X9G8K...[truncated]"

Annotate Screenshots

Use arrows, boxes, and callouts to direct attention to the relevant evidence. Don't make readers search for what you're trying to show.

Maintain Evidence Chain

Reference evidence files consistently:

Evidence: 
- Screenshot: evidence/NOVA-2025-002/sqli-response.png
- Burp Request: evidence/NOVA-2025-002/sqli-request.xml
- SQLMap Output: evidence/NOVA-2025-002/sqlmap-output.txt

Time-Stamp Everything

Include timestamps in filenames and evidence to establish when testing occurred:

evidence/
├── NOVA-2025-002/
│   ├── 2025-01-15_1423_sqli-initial.png
│   ├── 2025-01-15_1425_sqli-response.png
│   └── 2025-01-15_1430_sqlmap-output.txt

5. Professional Writing Standards

Technical accuracy matters, but so does how you communicate. Professional writing builds credibility and ensures your message is received clearly.

Tone and Voice

Be Objective, Not Judgmental

❌ Poor: "The developers clearly didn't know what they were doing when they wrote this code."

✓ Good: "The code uses string concatenation for SQL queries, which introduces injection vulnerabilities."

Be Precise, Not Vague

❌ Poor: "Several security issues were found in the application."

✓ Good: "Three SQL injection vulnerabilities and two stored XSS vulnerabilities were identified in the customer-facing API endpoints."

Be Direct, Not Hedging

❌ Poor: "There might possibly be some risk that could potentially lead to data exposure in certain circumstances."

✓ Good: "This vulnerability allows attackers to extract the complete customer database."

Be Helpful, Not Alarmist

❌ Poor: "YOUR ENTIRE SYSTEM IS COMPLETELY COMPROMISED AND HACKERS COULD DESTROY EVERYTHING!!!"

✓ Good: "Critical vulnerabilities were identified that require immediate attention. With the recommended remediations, these risks can be effectively mitigated."

Common Writing Mistakes

Passive Voice Overuse

❌ Passive: "The vulnerability was exploited and data was extracted."

✓ Active: "We exploited the vulnerability and extracted sample data."

Unexplained Jargon

❌ Jargon: "The endpoint is vulnerable to SSRF via the url parameter, enabling IMDS access."

✓ Explained: "The endpoint is vulnerable to Server-Side Request Forgery (SSRF), which allows attackers to make the server request internal resources, including AWS metadata containing credentials."

Missing Context

❌ No Context: "Port 22 is open."

✓ Contextual: "SSH (port 22) is accessible from the internet on the bastion server. While SSH access is necessary for administration, restricting source IPs would reduce the attack surface."

Report Quality Checklist

Before Submission

☐ Spell-check completed
☐ Grammar review completed
☐ All findings have complete write-ups
☐ Evidence properly referenced and included
☐ Sensitive data redacted
☐ Screenshots annotated and clear
☐ Table of contents accurate
☐ Page numbers correct
☐ Consistent formatting throughout
☐ Executive summary stands alone
☐ Technical details accurate
☐ Remediation guidance actionable
☐ Severity ratings justified
☐ Client name and dates correct
☐ Confidentiality markings present

6. Report Formatting and Presentation

Visual presentation affects how your report is received. Professional formatting demonstrates attention to detail and makes the report easier to navigate.

Formatting Guidelines

Cover Page

Client name and logo (if permitted)
Report title
Engagement dates
Report date
Consultant/firm name
Version number
Confidentiality statement

Headers and Footers

Header: Client name, report title
Footer: Page number, confidentiality marking
Consistent throughout document

Severity Color Coding

Critical: Dark Red
High: Red
Medium: Orange
Low: Green
Informational: Blue

Code Blocks

Monospace font (Consolas, Courier)
Light background for contrast
Syntax highlighting if possible
Line numbers for reference

Findings Summary Visualizations

Severity Distribution Chart

┌─────────────────────────────────────────────────────────────────┐
│              FINDINGS BY SEVERITY                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Critical ████████                                    3 (11%)  │
│  High     █████████████                               5 (18%)  │
│  Medium   █████████████████████                       8 (29%)  │
│  Low      ████████████████████████████████           12 (42%)  │
│                                                                 │
│           0        5        10       15       20               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Findings by Category

┌─────────────────────────────────────────────────────────────────┐
│              FINDINGS BY CATEGORY                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Category              Critical  High  Medium  Low   Total     │
│  ──────────────────────────────────────────────────────────    │
│  Injection                 1       1      0      0      2      │
│  Authentication            0       2      1      2      5      │
│  Access Control            1       1      2      1      5      │
│  Cloud Misconfiguration    1       1      3      4      9      │
│  Cryptography              0       0      2      3      5      │
│  Information Disclosure    0       0      0      2      2      │
│  ──────────────────────────────────────────────────────────    │
│  TOTAL                     3       5      8     12     28      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

7. NovaTech Report Outline

Here's the complete outline for the NovaTech security assessment report you'll create in this week's lab:

NovaTech Solutions Security Assessment Report

Front Matter

Cover Page
Document Control (version, authors, reviewers)
Confidentiality Statement
Table of Contents

1. Executive Summary (1-2 pages)

1.1 Assessment Overview
1.2 Overall Risk Posture
1.3 Key Business Risks
1.4 Critical Findings Summary
1.5 Recommended Actions

2. Engagement Overview (1-2 pages)

2.1 Scope and Objectives
2.2 Assessment Methodology
2.3 Testing Timeline
2.4 Tools Utilized
2.5 Limitations and Constraints

3. Findings Summary (2-3 pages)

3.1 Findings by Severity
3.2 Findings by Category
3.3 Risk Matrix
3.4 Findings Quick Reference Table

4. Detailed Findings

4.1 Critical Findings
- NOVA-2025-001: Log4Shell RCE on Jenkins
- NOVA-2025-002: SQL Injection in Customer Search API
- NOVA-2025-003: Public S3 Bucket Exposure
4.2 High Findings
- NOVA-2025-004: IAM Users Without MFA
- NOVA-2025-005: Stored XSS in Workflow Names
- NOVA-2025-006: SSH Open to Internet
- [Additional high findings...]
4.3 Medium Findings
4.4 Low Findings

5. Remediation Roadmap (2-3 pages)

5.1 Prioritized Remediation Timeline
5.2 Resource Requirements
5.3 Quick Wins
5.4 Compensating Controls

6. Strategic Recommendations (3-5 pages)

6.1 Network Segmentation
6.2 Identity and Access Management
6.3 Secrets Management
6.4 Security Monitoring
6.5 Secure Development Lifecycle

Appendices

Appendix A: Methodology Details
Appendix B: Evidence Files
- B.1 SQL Injection Evidence
- B.2 Log4Shell Exploitation
- [etc.]
Appendix C: Tool Outputs
- C.1 Nessus Scan Results
- C.2 Prowler Cloud Audit
- C.3 Burp Suite Project
Appendix D: Glossary of Terms
Appendix E: References

Self-Check Questions

Test your understanding of technical report writing:

Question 1

You've found a critical SQL injection vulnerability. Write an executive summary paragraph that a non-technical CEO would understand.

Reveal Answer

Sample executive summary paragraph:

"A critical vulnerability was identified in the customer search feature of WorkflowPro that could allow attackers to access the entire customer database. If exploited, this vulnerability could result in the exposure of approximately 50,000 customer records including names, email addresses, and workflow data. This would trigger mandatory GDPR breach notification requirements within 72 hours and could result in regulatory fines of up to 4% of annual revenue. Additionally, the resulting reputational damage could impact enterprise customer trust and pending deals. We recommend immediate remediation within 48 hours, with a code fix and temporary protective measures available."

Key elements: Business impact (customer data, regulatory, reputation), quantified risk, clear recommendation, no technical jargon.

Question 2

What's wrong with this finding description, and how would you improve it?

"XSS found. Bad input validation. Fix it."

Reveal Answer

Problems:

No specific location (which endpoint? which parameter?)
No severity assessment
No impact description
No proof of concept
No actionable remediation guidance
Unprofessional tone

Improved version:

NOVA-2025-005: Stored Cross-Site Scripting in Workflow Names

Severity: High | CVSS: 7.1

Affected Endpoint: POST /api/workflows (name parameter)

Description: The workflow creation endpoint does not properly sanitize user input in the workflow name field. Malicious JavaScript can be stored and executed when other users view the workflow list.

Impact: Attackers could steal session tokens, perform actions as other users, or redirect users to malicious sites.

Proof of Concept: [HTTP request/response showing payload and execution]

Remediation: Implement output encoding using a library like DOMPurify for all user-supplied content displayed in the UI. Additionally, implement Content-Security-Policy headers to mitigate impact of any bypasses.

Question 3

You have a finding that's technically low severity (CVSS 3.1) but affects a critical business system. How do you handle this in the report?

Reveal Answer

Approach:

Report the CVSS score accurately - Don't inflate technical severity
Add contextual risk rating - Include business context that elevates importance
Explain the discrepancy - Help readers understand why it matters despite low CVSS

Example documentation:

Technical Severity: Low (CVSS 3.1)

Contextual Risk: Medium

Note: While the technical severity of this information disclosure vulnerability is low, it affects the payment processing system. The disclosed information (software version) could be used by attackers to identify and exploit known vulnerabilities in that version. Given the criticality of the payment system, we recommend addressing this finding with higher priority than the CVSS score alone would suggest.

Question 4

You need to include a screenshot showing successful database access via SQL injection. The query returned actual customer data. How do you handle this evidence?

Reveal Answer

Evidence handling for sensitive data:

Redact PII before including - Replace actual names, emails, etc. with [REDACTED] or example.com placeholders
Show structure, not content - Demonstrate that data IS accessible without exposing actual data
Limit rows shown - Show 1-2 redacted rows, not full dump
Note what you didn't do - "Data extraction was limited to proof-of-concept; full database was not downloaded"

Example:

# Evidence showing database access (actual data redacted)
{
  "results": [
    {
      "id": 12345,
      "name": "[REDACTED]",
      "email": "[REDACTED]@example.com",
      "created_at": "2024-03-15"
    },
    ...
    // 50,247 total records accessible
  ]
}

Note: Only row count verified; actual data not extracted or stored.

Question 5

The NovaTech CISO asks you to remove a finding from the report because "we're already planning to decommission that system." How do you respond?

Reveal Answer

Professional response:

Don't remove findings - Report must accurately reflect what was found during the assessment
Document the context - Add a note about the planned decommissioning
Adjust risk if appropriate - If decommission is imminent and confirmed, this context affects practical risk
Maintain integrity - Report serves audit/compliance purposes and must be complete

Suggested response:

"I understand the system is planned for decommissioning. However, the report needs to accurately document what was found during the assessment for compliance and audit purposes. What I can do is add a note to the finding indicating that the system is scheduled for decommissioning on [date], which provides important context for remediation prioritization. If the system is decommissioned before the report is finalized, I can note its status as 'Remediated - System Decommissioned' in the final version."

Question 6

How would you organize and present 28 findings in a way that doesn't overwhelm readers but still provides complete information?

Reveal Answer

Organizational strategy:

Executive Summary: Mention only the 3 critical + top 2 high findings by name; reference total counts
Findings Summary section:
- Visual: Severity distribution chart
- Table: All 28 findings in quick-reference format (ID, title, severity, status - one line each)
- Category breakdown
Detailed Findings:
- Group by severity (Critical, High, Medium, Low)
- Full write-up for Critical and High (8 findings)
- Abbreviated write-up for Medium (8 findings)
- Brief description for Low (12 findings) or table format
Appendices: Full technical details, evidence, tool outputs for those who need deep detail

Key principle: Progressive disclosure - summary for everyone, details for those who need them, full evidence in appendices.

Lab: NovaTech Technical Assessment Report

Objective

Create the complete technical security assessment report for NovaTech Solutions, integrating all findings, analysis, and recommendations from the engagement.

Deliverables

Complete Technical Report: Full security assessment report (PDF)
Evidence Package: Organized evidence files referenced in report
Report Appendices: Tool outputs, methodology, glossary

Time Estimate

6-8 hours

Lab Tasks

Part 1: Document Setup

Create report template with proper formatting
Set up cover page with all required elements
Configure headers, footers, and page numbers
Create table of contents structure
Set up severity color coding and styles

Part 2: Executive Summary (LO4)

Write overall assessment paragraph
Summarize key business risks (3-5 bullets)
Highlight critical findings
Provide clear recommended actions
Keep to 1-2 pages maximum

Part 3: Engagement Overview

Document scope and objectives
Describe methodology (reference PTES, OWASP)
List tools utilized
Note any limitations or constraints
Include testing timeline

Part 4: Findings Summary

Create severity distribution visualization
Create findings by category breakdown
Build quick-reference findings table
Include risk matrix visualization

Part 5: Detailed Findings (LO2, LO3)

Write complete write-ups for all Critical findings
Write complete write-ups for all High findings
Write abbreviated descriptions for Medium findings
List Low findings with brief descriptions
Ensure each finding has:
- Clear description
- Impact statement
- Proof of concept with evidence
- Actionable remediation

Part 6: Remediation and Recommendations

Include remediation roadmap from Week 8
Include strategic recommendations from Week 9
Ensure alignment with detailed findings

Part 7: Appendices

Compile all evidence files with proper naming
Include relevant tool outputs
Create glossary of technical terms
Add methodology reference details

Part 8: Quality Review (LO5)

Complete spell-check and grammar review
Verify all evidence is properly referenced
Confirm sensitive data is redacted
Check formatting consistency
Validate table of contents
Review against quality checklist

Self-Assessment Checklist

Executive Summary

☐ Stands alone without requiring technical knowledge
☐ Clearly states overall risk posture
☐ Highlights business impact
☐ Provides actionable recommendations
☐ Appropriate length (1-2 pages)

Finding Write-ups

☐ All findings have complete documentation
☐ Evidence properly referenced
☐ Remediation guidance is specific and actionable
☐ Severity ratings justified
☐ Technical accuracy maintained

Evidence Quality

☐ All evidence files organized and named consistently
☐ Screenshots annotated where helpful
☐ Sensitive data redacted
☐ HTTP requests/responses properly formatted

Professional Quality

☐ No spelling or grammar errors
☐ Consistent formatting throughout
☐ Table of contents accurate
☐ Page numbers correct
☐ Professional tone maintained
☐ Appropriate for client delivery

Portfolio Integration

Save your technical report deliverables:

10-technical-report/
- NovaTech-Security-Assessment-Report-v1.0.pdf
- evidence/ — All evidence files organized by finding
- appendices/ — Tool outputs, methodology docs
- source/ — Editable source document

This report is the primary technical deliverable of your capstone engagement and will be a key portfolio piece.

📚 Building on Prior Knowledge

Reporting is where prior coursework becomes client-ready evidence:

CSY303 (Metrics & GRC): Translate findings into executive-ready metrics.
CSY104 Week 11 (CVSS): Use consistent severity scoring in report tables.
CSY203 (Web Security): Apply clear remediation guidance and PoC structure.
CSY301 (Threat Intel): Include actor context and threat-informed risk framing.

🎯 Hands-On Capstone Activities

Week 10 capstone activities - Technical Report Writing

🎯 Technical Report Writing Lab

Deliverable: Professional capstone component ready for portfolio
Time estimate: 4-8 hours

💡 Capstone Strategy: This work becomes your portfolio—make it job-interview ready.

Resources

Required

PTES Reporting Guidelines

Penetration Testing Execution Standard guidelines for creating professional security assessment reports.

PTES Reporting 45 minutes

Required

Sample Professional Pentest Reports

Collection of real-world penetration testing reports (sanitized) demonstrating professional formatting and content.

Public Pentesting Reports (GitHub) 60 minutes (review 2-3 reports)

Optional

Technical Writing Guide

Google's technical writing courses covering clarity, audience awareness, and documentation best practices.

Google Technical Writing 2 hours (if new to technical writing)

Weekly Reflection

Prompt

Reflect on the challenge of writing for multiple audiences in a single document. How did you approach balancing technical depth for developers with accessibility for executives? What strategies did you use to ensure your findings were both accurate and actionable?

Consider the relationship between assessment quality and report quality. How does a well-written report enhance (or fail to capture) the value of thorough technical testing? What did you learn about professional communication that you'll apply in future security work?

Target length: 250-350 words