CSY399 Week 10 Capstone

Week Content

Cybersecurity Capstone

Track your progress through this week's 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:

  1. 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.
  2. Supply Chain Compromise: Vulnerabilities in the CI/CD pipeline could allow attackers to inject malicious code into software deployed to enterprise customers.
  3. 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:

  1. Immediate (24-48 hours): Patch Log4j vulnerability, remediate public S3 bucket, rotate potentially compromised credentials.
  2. Urgent (1-2 weeks): Fix SQL injection and XSS vulnerabilities in WorkflowPro application.
  3. Short-term (30 days): Implement network segmentation, deploy secrets management, enable comprehensive security monitoring.
  4. 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:

  1. Re-test the endpoint with the original payload; should return error or empty results
  2. Run SQLMap against the endpoint; should report no injection found
  3. 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

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:

  1. Report the CVSS score accurately - Don't inflate technical severity
  2. Add contextual risk rating - Include business context that elevates importance
  3. 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:

  1. Redact PII before including - Replace actual names, emails, etc. with [REDACTED] or example.com placeholders
  2. Show structure, not content - Demonstrate that data IS accessible without exposing actual data
  3. Limit rows shown - Show 1-2 redacted rows, not full dump
  4. 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:

  1. Don't remove findings - Report must accurately reflect what was found during the assessment
  2. Document the context - Add a note about the planned decommissioning
  3. Adjust risk if appropriate - If decommission is imminent and confirmed, this context affects practical risk
  4. 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:

  1. Executive Summary: Mention only the 3 critical + top 2 high findings by name; reference total counts
  2. Findings Summary section:
    • Visual: Severity distribution chart
    • Table: All 28 findings in quick-reference format (ID, title, severity, status - one line each)
    • Category breakdown
  3. 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
  4. 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

Time Estimate

6-8 hours

Lab Tasks

Part 1: Document Setup

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

Part 2: Executive Summary (LO4)

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

Part 3: Engagement Overview

  1. Document scope and objectives
  2. Describe methodology (reference PTES, OWASP)
  3. List tools utilized
  4. Note any limitations or constraints
  5. Include testing timeline

Part 4: Findings Summary

  1. Create severity distribution visualization
  2. Create findings by category breakdown
  3. Build quick-reference findings table
  4. Include risk matrix visualization

Part 5: Detailed Findings (LO2, LO3)

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

Part 6: Remediation and Recommendations

  1. Include remediation roadmap from Week 8
  2. Include strategic recommendations from Week 9
  3. Ensure alignment with detailed findings

Part 7: Appendices

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

Part 8: Quality Review (LO5)

  1. Complete spell-check and grammar review
  2. Verify all evidence is properly referenced
  3. Confirm sensitive data is redacted
  4. Check formatting consistency
  5. Validate table of contents
  6. 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:

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:

🎯 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

Week 10 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz