Attack Dwell Time via Vendors

A global insurance company's supply chain compromise began not at their primary vendor but at a software integration company that provided API development services to their claims processing vendor. The attack timeline, reconstructed in post-incident analysis, spanned three organisations and forty-eight days. Day one: the software integration company's GitHub credentials were compromised through credential stuffing against a developer's personal account that reused a password exposed in a prior breach. The attacker used the developer credentials to access the integration company's code repositories, which contained API credentials for the claims processing vendor's development environment. Day twelve: the attacker used the API credentials to access the claims processing vendor's development environment and spent eleven days mapping the environment, establishing persistence, and identifying the pathway to customer data. Day twenty-three: the attacker pivoted from the development environment to the production environment using a misconfigured service account that had unnecessary production access. Days twenty-three through forty-six: the attacker spent twenty-three days in the production environment mapping customer data locations, testing exfiltration paths, and staging data for extraction. Day forty-seven: bulk exfiltration of insurance claims data. Day forty-eight: the insurance company's SOC detected anomalous data transfer from the vendor's IP range. The insurance company assessed the claims processing vendor. The claims processing vendor had assessed the integration company. Both assessments had found satisfactory security postures. Neither had detected or contained the attack that had been traversing their supply chain for forty-eight days.

Why this matters

Attack dwell time via vendors matters for TPRM because the customer's data exposure begins not when the attacker enters the customer's environment but when the attacker gains access to any environment in the supply chain pathway to the customer's data. The forty-eight-day dwell time in the hook scenario represents forty-eight days of attack preparation in the supply chain before the customer experienced any direct impact. Reducing supply chain dwell time requires both improving individual vendor detection capability and establishing the cross-boundary coordination mechanisms that enable faster detection of multi-hop attacks.

The mean time to detect metric at the vendor level is the direct indicator of supply chain dwell time risk. A vendor with a thirty-day mean time to detect provides an attacker with thirty days of average dwell time to use for supply chain traversal preparation. Reducing vendor MTTD reduces the available dwell time for supply chain attack staging. MTTD for each vendor in the supply chain pathway is a cumulative risk indicator , the sum of dwell times across the supply chain path is the total time the attacker has to prepare the final-hop attack on the customer.

Where most teams get this wrong

The most consistent failure is not measuring or requesting vendor MTTD as a supply chain risk metric. Individual vendor assessments confirm detection capabilities. MTTD from actual incidents reveals how long attackers operated before detection , the empirical dwell time rather than the theoretical detection capability.

• Vendor MTTD not requested , detection capability confirmed without empirical dwell time
• Fourth-party entry points not assessed , attack entry two hops up the supply chain
• Cross-boundary dwell time not considered as portfolio risk metric
• Assessment snapshots accepted without considering operational change since assessment
• No continuous monitoring providing inter-assessment dwell time visibility

What good looks like

Mature supply chain dwell time management programmes request actual MTTD from vendor incident records, monitor continuous security ratings for signals of ongoing attacker presence, and consider fourth-party entry points in supply chain risk analysis.

• Request actual MTTD from vendor incident history , empirical, not theoretical
• Continuous security rating monitoring for signs of attacker presence between assessments
• Fourth-party entry point assessment , what can reach the vendor and how
• Cross-boundary threat intelligence sharing to accelerate multi-hop detection
• Supply chain dwell time as portfolio metric , cumulative MTTD across supply chain path

Tooling

Supply Chain Intelligence , Interos, RiskRecon

Supply chain intelligence platforms monitor the extended supply chain including fourth-party relationships , identifying when vendors' vendors experience security events that may indicate compromise that could traverse the supply chain. For TPRM practitioners, monitoring supply chain intelligence for fourth-party events provides the early warning for multi-hop attacks that individual vendor assessments cannot detect.

Governance challenges

The governance challenge with supply chain dwell time is the assessment scope limitation. Fourth-party entry points are two hops removed from the customer , they are vendors' vendors, outside the customer's direct assessment scope and often outside the vendor's formal assessment scope for their own sub-vendors. The governance resolution is combining fourth-party visibility tools with vendor MTTD requests and continuous monitoring that can provide signals of attacker presence without requiring direct fourth-party assessment.

• Request MTTD from actual vendor incidents , empirical dwell time
• Monitor fourth-party supply chain for security events
• Request vendor's sub-vendor assessment practices
• Incorporate fourth-party risk in supply chain security assessment
• Continuous security monitoring for early dwell time signals

If you are a small team

Ask your three highest-risk vendors one question: in your security incidents over the last two years that involved customer data, what was the mean time to detect from initial attacker access to discovery? That empirical MTTD is the most informative single metric for supply chain dwell time risk , more informative than any capability assessment, because it describes how long attackers actually operated before being detected, not how long the detection architecture suggests they should have been able to operate.

• Ask vendors for empirical MTTD from actual incidents involving customer data
• Compare empirical MTTD to capability-assessed theoretical detection time
• Monitor continuous security ratings for dwell time signals
• Assess fourth-party entry points for highest-risk vendor relationships

What to require

Ask directly:

"For security incidents in your environment over the last two years , what was the average or range of mean time to detect from initial access to discovery, and was the detection primarily through your own SOC monitoring or through external notification?"

Expect as evidence

• Empirical MTTD from actual incidents
• Detection source , internal SOC vs external notification
• Longest dwell time from recent incidents
• Dwell time trend , improving or stable

A vendor who confirms mature detection capability should be asked for their empirical MTTD from actual incidents. Theoretical detection time describes the architecture. Empirical MTTD describes how the architecture performed against actual attackers.

How to evidence it

• Vendor empirical MTTD records
• Supply chain fourth-party monitoring
• Continuous security monitoring for dwell time signals
• Supply chain dwell time portfolio metric

Key Takeaway

Forty-eight days across three organisations. The customer detected on day forty-eight. The attack began on day one at a fourth-party software integration company. The supply chain traversal was complete before the customer's SOC generated the first alert. Each organisation's individual security posture was confirmed as satisfactory at assessment time. The dwell time accumulated in the gaps between the assessments, across the organisational boundaries, and in the detection lag of three independent security teams investigating the same attack from different sides. Empirical MTTD from actual incidents is the most honest description of vendor dwell time risk. Request it. The theoretical detection capability describes what should happen. The empirical MTTD describes what actually happened.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations