Twelve thousand external assets, nine analysts and a regulator
A retail bank's security operations team of nine analysts handles roughly 40,000 alerts a month from endpoint, network and cloud sources. Vulnerability management scans the internal estate but has no reliable inventory of what the bank exposes to the internet: a discovery exercise found about 12,000 external-facing assets against 8,900 known, including subsidiary domains, forgotten marketing microsites and three test environments with production data. Three separate penetration-test vendors report quarterly in incompatible formats, and the regulator has asked for evidence that externally exposed weaknesses are identified, prioritised and remediated within stated timescales. Separately, the head of engineering has discovered that developers are pasting production code fragments into public generative AI tools, and wants to know whether that is a security incident or a policy matter.
1. What does an exposure management capability add here that vulnerability management and SIEM alerting do not, and how does threat intelligence change prioritisation?
Read the worked answer
Vulnerability management answers 'what is unpatched on assets we know about'. SIEM alerting answers 'what is happening now'. Neither answers 'what can an attacker see and reach from outside, and does it matter', which is precisely the regulator's question and precisely the gap that produced 3,100 unknown assets.
Exposure management contributes three things. Discovery: continuous enumeration of domains, certificates, IP ranges and cloud endpoints belonging to the bank and its subsidiaries, which is how the forgotten microsites and test environments surface. Context: ownership, data sensitivity, business function and whether an exposed service is actually exploitable, replacing scanner severity with a statement about business risk. Workflow: one prioritised queue with remediation owners, SLAs and an audit trail, into which the three pentest vendors' findings can be normalised instead of living in three PDFs.
Threat intelligence changes the ranking. A medium-severity service that is actively being probed, or that matches a technique currently used against financial institutions, outranks a high-severity finding on an isolated host. Intelligence should also be used in the other direction: to check whether any exposed asset or credential already appears in breach or chatter data, which converts a theoretical exposure into a live incident decision.
2. Design a 90-day plan and the reporting the regulator should see. Be specific about what you would not attempt in the first 90 days.
Read the worked answer
Days 1-30, establish ground truth: scope the bank and its subsidiaries formally, run continuous discovery, and reconcile the 12,000 assets into owned, unowned and unknown. Assign an owner to every externally reachable asset; anything unowned is treated as high risk by default. Do not start remediation of everything, because triage capacity does not yet exist.
Days 31-60, build the queue: import pentest findings from all three vendors into one schema, define five severity bands with remediation timescales agreed by the risk committee, and apply threat intelligence to reorder the top 200 items. Take the three test environments with production data offline immediately; that decision does not need a queue.
Days 61-90, prove the loop: remediate the top tranche, measure actual time-to-remediate against the promised timescales, and publish the first report.
What I would not attempt: a full asset CMDB integration, rescoring the entire internal vulnerability estate, or a tool replacement. Each would consume the 90 days and produce no regulatory evidence.
The regulator's report should show the exposure inventory with ownership coverage, the severity definitions and timescales, remediation performance against them including misses, and the trend in externally reachable services with known critical weaknesses. Misses reported honestly are stronger evidence than a perfect record.
3. Advise the engineering head: is the generative AI usage an incident or a policy matter, and what controls would you put around it?
Read the worked answer
Treat it as a policy and control gap first, and only escalate to an incident if the code or data pasted was client-identifying or regulated. Investigate before deciding: which tools, which repositories, whether any pasted content contained personal data, credentials or source that is itself the bank's product, and whether any tool retains or trains on submitted data. That determines notification obligations.
The underlying issue is that staff found an ungoverned route to a useful capability. Blocking alone will push it underground, as the earlier proxy-extension behaviour shows.
Controls, in order: an acceptable-use policy that names approved tools and states plainly what may never be pasted (customer data, credentials, production source); a sanctioned alternative, whether an enterprise tenant with contractual no-training terms or an internally hosted model, so there is a compliant path; data-loss controls at the egress points that already exist, covering browser uploads and SaaS uploads to unsanctioned AI domains; secret scanning in repositories so credentials never reach a paste buffer; and logging of approved-tool usage sufficient to answer an audit question.
For the regulator, describe this as a data-governance control with evidence of monitoring, not as a technology ban. Also flag that AI-specific guardrail products are a young category; validate current capability and contractual terms before relying on them.