Application Fundamentals Capstone
Convert penetration-test evidence into business-ranked risks, testable controls, accountable deadlines and verified remediation.
Brief
Halcyon Clinics receives a penetration-test report for its appointment API: a patient can retrieve another patient's record, a public dependency has a known vulnerability, and a response reveals a framework version. The release manager sorts by scanner score and marks the record-access defect fixed after hiding its button. Your job is to turn those observations into a defensible remediation programme, not a prettier report.
Carry each finding from reproducible request to asset and data impact, then to priority, control objective, accountable owner, deadline and independent retest. You will author the highest-risk work package and review a proposed closure ledger. Preserve report identifiers throughout so an auditor can trace any closed risk back to its original evidence and forward to the deployed safeguard.
A technical score describes a vulnerability; a remediation decision also needs exposure, consequence, accountability and proof.
Rank attack paths, not report headings
Start by validating scope and prerequisites: endpoint, HTTP method, build identifier, authenticated role, object ownership and data returned. A successful request using another patient's object identifier demonstrates broken object-level authorisation; knowing an identifier should never grant access. Distinguish that from authentication, which establishes who made the request. A token can be valid while the requested operation is forbidden.
Keep the reported CVSS score unchanged and record a separate business priority. Under this room's policy, confirmed cross-patient disclosure in production is critical, a reachable vulnerable parser without demonstrated sensitive-data access is high, and a version banner alone is low. A score of 9.8 on an unreachable test component does not automatically outrank demonstrated production disclosure. Record uncertainty and commission validation rather than inventing exploitation evidence.
The risk statement joins cause, event and consequence: missing ownership enforcement permits an authenticated patient to retrieve another patient's medical record, causing confidentiality loss. For vulnerability-management assurance, retain the tested scope, prerequisites, observed response and priority rationale. The audit question is why this item entered the urgent queue while another did not; a sorted score column cannot answer it.
Map the failed decision to a testable control
For object-level access, the control objective is server-side authorisation on every record operation. Derive the caller identity from a validated session, load the resource's trusted tenant and owner attributes, then evaluate policy before returning or mutating data. Do not trust an owner identifier supplied by the caller. Parameterised queries prevent injection, but do not decide whether this caller may read this row; encryption in transit protects the connection, not the access decision.
Write acceptance tests for both negative and positive paths: patient A cannot read or update patient B's record; patient A can still read their own record; a deliberately authorised clinical role follows its documented policy. Check response bodies as well as status codes so an error cannot leak medical fields. Apply the policy to collection, export and alternate API routes, not just the route named in the report.
Map the implementation to a stable local control identifier, such as APP-AC-01, and optionally cross-reference NIST AC-3 or an appropriate OWASP verification requirement. A crosswalk is a catalogue link, not evidence of operation. A reviewer needs the policy change, route coverage and reproducible test results for the deployed build; simply attaching a framework reference proves none of those.
Give the clock and the decision an owner
This exercise uses elapsed calendar hours from validation: critical findings require verified remediation within 24 hours, high within 168 hours, medium within 720 hours and low within 2160 hours. Validation at 09:00 UTC on 10 June makes a critical item due at 09:00 UTC on 11 June. Assignment, deployment and temporary containment do not restart the clock. Store the validation timestamp, due timestamp and severity history to make ageing reproducible.
Assign one accountable service owner who can fund and schedule the fix, a delivery team that implements it, and an independent verifier who confirms closure. The security tester should not become the default accountable owner merely because they discovered the issue. If a critical fix will miss its deadline, escalate before expiry; an approved, time-bounded exception must name the risk authority, rationale, compensating safeguard, expiry and review date.
Risk acceptance is not technical remediation. Preserve the original due time and show the exception separately so overdue items cannot disappear through reassignment or severity edits. For the remediation-governance control, evidence includes assignment acknowledgement, escalation history and signed exception decisions. An auditor may ask who had authority to accept continuing patient-data exposure, not just who updated the ticket.
Close with deployed evidence and retain the denominator
Use explicit states: validated, assigned, in progress, deployed pending retest, and verified closed. A successful build proves an artefact was produced, not that every production instance runs it. Link the change identifier to deployment inventory and retest the original attack with equivalent roles and object relationships. Add regression tests and confirm legitimate access still works. A failed retest returns the item to active work without resetting its age.
Keep evidence references rather than patient records in the ledger: report finding, redacted request and response, change, deployment build, test run, verifier and timestamp. Protect the evidence store with access control and retention rules. When the tester closes a finding, residual risk may still require monitoring; a temporary route block should remain a mitigation until the underlying policy and alternate routes are verified.
Compute SLA compliance over a declared cohort. If ten findings were due this month and seven were verified before their deadlines, compliance is 70%, even if two others received approved exceptions and one is awaiting retest. Report exception counts and overdue age separately; do not remove difficult cases from the denominator. This makes operating-effectiveness evidence reproducible and lets an auditor sample a closed record back to the exact production test.
This room is the track's final project. Every lab below is one step of a single deliverable - clear them all and the Application Fundamentals track is complete.
Next on your path · GRC Fundamentals
Risk, Control, Compliance
Three words practitioners use interchangeably and shouldn't. Learn to separate the threat, the safeguard, and the obligation.
Community
Discussion & writeups
Share how you approached the room or ask where you got stuck. Never paste task answers or full lab solutions: write the reasoning, not the key.
Loading discussion…