Vendor Compromise Indicators

A healthcare analytics vendor's incident response identified the initial compromise indicator , a compromised service account credential , through analysis of authentication logs that showed the account authenticating from an IP address outside its historical range on day three of what turned out to be a twenty-two-day breach. The discovery on day twenty-two came through an unrelated DLP alert on an unusually large data staging operation. The retrospective investigation confirmed the service account compromise on day three, identified seven additional authentication events over the following nineteen days, and established that the service account had permissions to three distinct data environments holding different customers' analytics data. The investigation could not confirm, from available logs, which specific data resources the service account had accessed through its authentication sessions , the service account's authentication token was logged, but the specific API calls and data queries executed during each session were not captured in the authentication log. The vendor's API platform logged query executions separately, and those logs had a thirty-day retention period. Days three through one of the compromise were within the retention window; the query execution logs for days three through eight had been deleted. The compromise indicators told investigators the service account was used. The deleted query logs left the specific data access path unknown for the first eight days. Customer notification stated that data may have been accessed , not that it was confirmed to have been accessed , for six of the three customers whose environments the service account could reach.

What are Vendor Compromise Indicators, Really?

Vendor compromise indicators are the technical evidence , authentication events, network connections, file system changes, registry modifications, and process executions , that demonstrate an attacker's presence in a vendor's environment. Compromise indicators confirm that access occurred. They do not always confirm what that access was used for , specifically what data was accessed, what commands were executed, and what changes were made during the period of unauthorized access. The distinction between knowing a compromise occurred and knowing what the compromise accomplished is the gap between indicator confirmation and consequence understanding.

The indicator-versus-consequence gap is the fundamental challenge of vendor breach investigation. A compromised service account credential is a clear compromise indicator , it demonstrates unauthorized use of a legitimate credential. The consequence of that use , what the attacker accessed, what they queried, what they exfiltrated , requires a different category of evidence: API call logs, query execution logs, database access logs, and network traffic captures. These consequence-level logs may have different retention periods, different capture configurations, and different access requirements than the authentication logs that surface the indicator.

The log completeness problem creates the specific investigation limitation. Investigations that can confirm indicators but cannot confirm consequences , because consequence-level logs were not retained, not captured, or not accessible , leave customers and investigators in the position of knowing access occurred without knowing what was accessed. This produces the worst possible notification outcome: must-notify because access cannot be ruled out, combined with inability to scope the notification to confirmed exposed records. The uncertainty drives conservative notification decisions that may overstate exposure to comply with the regulatory requirement to notify when unable to rule out access.

• Indicator confirmation without consequence confirmation , access occurred, consequences unknown
• Query execution logs not retained or shorter retention than authentication logs
• API call logs separate from authentication logs with different retention
• Service account permission scope exceeding actual data access requirements
• Notification forced by uncertainty , unable to rule out access driving conservative notification

Why this matters

Vendor compromise indicators matter for TPRM because the customer's breach risk assessment , and their regulatory notification decision , depends on understanding not just that a vendor was compromised but what the compromise accomplished for the data the customer shares with that vendor. A vendor whose compromise indicators are clear but whose consequence logs are absent or incomplete leaves the customer unable to scope their exposure with the specificity that HIPAA, GDPR, and PCI-DSS require for notification decisions.

Where most teams get this wrong

The most consistent failure is not distinguishing between indicator evidence and consequence evidence in vendor breach assessments. Confirming that a compromise indicator was identified does not confirm that the investigation can determine what the attacker accomplished with the access the indicator represents.

• Indicator confirmation equated with consequence confirmation
• Consequence log retention not assessed , query logs, API logs separate from authentication
• Service account permission scope not assessed relative to customer data access
• Notification scope uncertainty not addressed contractually
• Post-breach consequence logging not enhanced to prevent future uncertainty

What good looks like

Mature compromise indicator programmes maintain aligned retention across indicator and consequence log categories, implement service account permission scoping that limits the data the account can reach, and contractualise consequence log access rights that enable customers to independently scope their exposure.

• Aligned log retention , authentication and consequence logs retained for same period
• Service account minimum necessary permissions , limiting blast radius of credential compromise
• Consequence log access rights , customer access to query and API logs for breach scoping
• Enhanced logging post-breach , consequence logging increased following discovery
• Notification scope confirmation SLA , timeline for confirming or ruling out data access

Tooling

API and Query Logging , AWS CloudTrail data events, database audit logs, API Gateway logs

Consequence-level logging for API calls and database queries requires explicit enablement , cloud providers do not always enable data-event logging by default due to the cost and volume implications. For TPRM practitioners, asking whether the vendor has data-level API logging enabled , capturing what was accessed, not just that authentication occurred , provides a specific consequence logging question.

Governance challenges

The governance challenge with consequence logging is the cost and volume of data-level API and query logging. Logging every API call and database query generates significantly higher log volumes than authentication logging alone. The governance resolution is selective data-level logging for high-sensitivity environments , specifically the environments holding regulated or high-value data.

• Ask whether data-level API logging is enabled for customer data environments
• Ask about consequence log retention , query and API logs vs authentication logs
• Ask about service account permission scoping , minimum necessary access
• Contractualise consequence log access for breach scoping
• Require consequence log enhancement following any breach as part of remediation

If you are a small team

For your highest-risk vendor, ask two questions about their logging architecture: first, when a service account authenticates to the environment holding your data, are the specific API calls and data queries executed during that session logged and retained , and for how long? Second, if that service account were compromised, would the investigation be able to confirm specifically what data was accessed during the compromise period, or would it only be able to confirm that the account authenticated? Those two questions reveal whether the vendor can confirm consequences or only indicators.

• Ask whether API calls and data queries executed during sessions are logged
• Ask how long query execution and API call logs are retained
• Ask whether a service account compromise investigation could confirm data accessed
• Ask about service account permission scoping

What to require

Ask directly:

"If a service account with access to our data were compromised , would your investigation be able to confirm specifically what data that account accessed during the compromise period, or would you only be able to confirm that the account was used? And how long are your API call and query execution logs retained?"

Expect as evidence

• Data-level API and query log confirmation
• Consequence log retention period
• Service account permission scoping
• Investigation capability to confirm data access consequences

A vendor who confirms compromise detection capability should be asked whether their logging enables consequence confirmation , not just indicator detection. The indicator tells investigators that access occurred. The consequence log tells them what the access was used for.

How to evidence it

• Consequence log retention documentation
• Data-level API logging confirmation
• Service account permission scoping records
• Consequence log access rights documentation

Key Takeaway

Service account compromised day three. Detected day twenty-two. Nineteen days of authentication sessions to three customer data environments. Query execution logs for days three through eight: deleted. Data accessed during those eight days: unknown. Notification required because access cannot be ruled out. Notification scope: uncertain. The compromise indicator is clear. The consequence is unconfirmable for eight of the nineteen days. Data-level logging , API calls and query executions captured alongside authentication , would have resolved the uncertainty. Consequence log retention aligned with authentication log retention would have prevented the deletion. The indicator tells you the door was opened. The consequence log tells you what was taken from the room.

More on Security

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