Post-Acquisition Attack Surface: Attributing 190,000 Unknown Assets and Enforcing a 30-Day SLA

Why attribution is the critical path: an unowned finding cannot be remediated, cannot be risk-accepted, and cannot be escalated to anyone. Every other process downstream - SLA, routing, reporting - is blocked on a name. 55% coverage means nearly half of the 220 critical findings have no accountable party.

Build the attribution layer

1. Authoritative sources first. Ingest CMDB records, cloud account inventories, and DNS ownership. For cloud egress ranges that rotate, attribution must follow the account and workload, not the IP - tag-based mapping is the durable link; IP-based rules will decay weekly.
2. Corroborating evidence second. Organization names in TLS certificate subjects, WHOIS registrant data, reverse DNS patterns, and page content fingerprints. These are probabilistic; treat them as evidence, not proof.
3. Human confirmation third. A short, structured survey per business unit: known ranges, cloud accounts, acquired entities, third-party hosting. The subsidiary's VPN claim needs to be tested against discovery data directly - show them the specific IPs and services, and ask which of their systems respond there.
4. Confidence tiers. Attributed-high (CMDB or cloud tag match), attributed-medium (inferred from cert/DNS), unknown. Publish coverage by tier so progress is measurable.

Handling the residue

• Assign a default owner for unowned assets - typically the cloud platform or network engineering team - with a formal claim window (for example five business days) during which a business unit can take ownership.
• After the window, the default owner is accountable for remediation or risk acceptance. Never let "unowned" function as "unactionable."
• Surface a weekly unowned-asset count to the executives who own the business units. Attribution improves when it is visible, not when security chases it.

Why severity alone fails: all 220 findings are "critical" by label, so the label provides no ordering. Triage by severity means the queue is effectively random, and with five engineers and a 30-day SLA, ordering is the whole game.

Factors that actually move risk

1. Exploitability and prerequisites. An unauthenticated Elasticsearch instance is a data-exfiltration path available to anyone with a browser. Exposed RDP may require credentials and may or may not have network-level authentication - check. 61 RDP endpoints are not one finding; they are a distribution.
2. Data sensitivity and regulatory scope. Payment-flow certificates sit in PCI scope. An expired certificate on a payment endpoint is an availability and trust incident, not a hygiene task. Weight by what the system touches, not where it sits.
3. Compensating controls. Behind a VPN with MFA and no split tunneling is materially different from directly reachable. Verify the control rather than accepting the claim - the subsidiary's assertion is already contradicted by discovery.
4. Evidence of active exploitation or scanning. Check exposure duration and any observed interaction. A service exposed for two years with scanning traffic against it outranks one that appeared yesterday.
5. Blast radius and dependency. A shared load balancer fronting 40 services outranks a standalone host.

Practical output: a composite score with the factors visible, so an engineer can see why an item is at the top. Sort into four tiers rather than a strict ranking - tier 1 is "exploitable now, sensitive data, no effective control" and gets worked this week.

Deliberate exclusion: do not let asset count or business-unit seniority drive the order. The temptation with 12 business units is to spread work evenly for political reasons; that trades real risk reduction for appearance.

Diagnosis: a 30-day SLA against a three-week queue means the SLA is already unachievable before any engineering happens, and the security team has no authority to fix it. Routing into the general queue is a decision to fail slowly.

Routing design

1. A dedicated incident type and queue for external exposure findings, separate from the general service desk. Exposure findings are not user tickets; mixing them guarantees deprioritization behind password resets.
2. Auto-assignment by attribution tag, so the ticket lands with the business unit that owns the asset rather than in a triage pool. Where attribution is medium-confidence, route to the default owner with the claiming business unit copied - this creates social pressure to claim accurately.
3. SLA clock starts at discovery, not at ticket acceptance. Otherwise the clock restarts every time a ticket is bounced, and the metric measures queue behavior instead of exposure.
4. Automated evidence attached to the ticket: the service, banner, screenshot-equivalent metadata, first-seen date, and a one-line remediation action. Engineers who have to rediscover the finding will not act on it.
5. Verification by rescan before closure. A ticket closed without a confirming rescan is not remediation; it is a claim. Automate the rescan and reopen on failure.
6. Escalation ladder tied to days remaining - at 20 days the business-unit security lead is notified, at 10 the BU owner, at 5 it goes to the executive risk forum with the specific asset and exposure. Escalation must be automatic, because a five-person team cannot chase 220 findings by hand.

For findings no one will fix: formal risk acceptance with a named acceptor, an expiry date, and compensating controls recorded. Acceptance must be signed above the level that benefits from the delay.

One more thing: where the exposed service is clearly malicious or the host is confirmed compromised, remediation via takedown or isolation should bypass the ticket queue entirely - the SLA process is for exposure reduction, not incident response.