The Fourteen-Week Deadline With No Threat Model
Fintrail must replace its card authorisation switch to meet a regulatory deadline in fourteen weeks. The build is now forecast to finish in week eleven, two weeks later than planned. The pen test supplier is booked for week twelve and cannot move. The business owner proposes dropping threat modelling entirely and relying on the pen test as 'the security check', arguing that the new switch reuses an authentication module that was verified two years ago in the customer portal and that the terminal estate is certified by the acquirer. The security team has no agreed entry criteria for the test, and the previous release went live with six unresolved medium findings that nobody tracked afterwards. The application owner has signed nothing and believes the security sign-off is the implementer's job.
1. Assess the proposal to drop threat modelling and rely on the penetration test alone.
Read the worked answer
Answer: reject it, because the pen test cannot substitute for the activity that tells you what to test.
Reasoning:
- Different outputs. Threat modelling identifies attack paths against the design and directs effort - which ASCs are needed, where to focus code review and which abuse cases the testers should attempt. A penetration test finds exploitable instances within whatever it happens to reach in the time booked. Substitute one for the other and the test becomes an unstructured crawl over a payment switch.
- The reuse claim is untested. An authentication module verified two years ago in a different application and a different threat environment has different trust boundaries here. Reuse can legitimately reduce verification scope, but only after a documented delta analysis: same version, same configuration, same integration points, no new exposure. Absent that, reuse is an assumption, not evidence.
- The acquirer's terminal certification is about the terminal estate, not Fintrail's switch. Inherited controls must be mapped to the specific ASCs they satisfy and the scope of the attestation recorded.
- Cost of the alternative is small. A focused two-day threat modelling workshop in week one, with the architects and the test lead, produces the abuse cases and the test charter. It is the cheapest way to make the week-twelve test count, and it is the input the ASC selection needs anyway.
2. How should the implementation phase be re-planned so the fourteen-week deadline is met without an unverified release?
Read the worked answer
Answer: protect the verification window and move scope, not sequence.
Plan elements:
- Fix the critical path backwards from the deadline. Independent testing in week twelve, remediation and re-test weeks thirteen to fourteen. That leaves no slack; therefore the build scope must flex. Split the release: full authorisation processing in scope, with lower-risk reporting and settlement interfaces deferred, if the business owner agrees the reduced scope still satisfies the regulatory obligation.
- Set entry criteria before week twelve and make them explicit. A defined build, test data, credentials, an agreed test charter derived from the threat model, and the ASC list with implementation status. Without entry criteria the test starts late or tests the wrong target, and the deadline is lost anyway.
- Run targeted verification earlier. For high-risk ASCs - key management, PIN handling, message authentication, access control on the admin interface - do code review in weeks four to six so defects are fixed while the team is still building, not in the two weeks afterwards.
- Align the risk reuse analysis with the pen test scope. Have the supplier confirm version, patch level and configuration of the reused authentication module; if any differ, treat the module as new.
- Define exit criteria and the residual-findings process now. Not every finding must be closed, but every open finding needs a named owner, a compensating control, a target date and an acceptance signed by the application owner. The previous release's six untracked mediums are the evidence for why this exists.
- Get the application owner to sign the plan and the criteria in week one. Security sign-off is not the implementer's risk to carry; the implementer supplies evidence and recommendation.
3. The business owner insists on go-live even if medium findings remain open. What should the implementer produce?
Read the worked answer
Answer: a decision record with evidence, not a veto and not a silent approval.
The implementer's deliverable at that point is a verification report that the accountable owner can accept against:
- Finding inventory: each open finding described by ASC, affected component, exploitability given the actual exposure, and business impact - not just a severity label. A medium finding in an admin-only function behind strong authentication is a different proposition from a medium finding on the internet-facing authorisation endpoint.
- Compensating controls: what is actually in place, who operates it, how it is monitored and how effective it is expected to be. 'WAF will block it' is not a compensating control unless a rule exists, is tested and is alerting.
- Time-bound plan: remediation date, owner and the verification method for each finding, with the re-test booked rather than promised.
- Explicit residual-risk statement: the risk the owner is accepting, quantified as far as possible, with an expiry date and a trigger for escalation if remediation slips.
- Signature block for the application owner, not the implementer. The implementer attests to the verification performed and the evidence quality; the owner accepts the business risk.
This structure does two things. It moves the decision to the person with authority over the business impact, and it creates an artifact the auditor can follow. A verbal 'we accepted it' with no record is the pattern that produced the previous release's untracked findings, and repeating it converts a technical decision into an unmanaged one. If the owner declines to sign, the correct escalation is upward through governance, not sideways into the delivery team.