Vendor SOC Integration

A pharmaceuticals company and their clinical research data vendor both had mature, well-staffed security operations centres. The vendor's SOC had twenty-four-seven coverage with experienced analysts and a well-tuned detection infrastructure. The pharmaceuticals company's SOC had equivalent capability. When a sophisticated threat actor initiated a supply chain attack , compromising the vendor's environment to reach the pharmaceutical company's clinical trial data , the attack generated detectable signals in both environments, though at different times and with different indicators. The vendor's SOC detected anomalous authentication on a service account at 2:17am and began investigation. The pharmaceutical company's SOC detected anomalous network traffic from the vendor's IP range at 5:34am , three hours and seventeen minutes later , and began their own independent investigation. Neither SOC knew the other had an active investigation. The vendor's investigation classified the authentication anomaly as potentially related to a known configuration issue and had not escalated to the pharmaceutical company. The pharmaceutical company's investigation had not yet determined whether the vendor's IP traffic was attack-related or operational. The threat actor, operating in both environments simultaneously, used the three-hour investigative gap , the period when both SOCs were investigating independently without coordination , to stage clinical trial data in the vendor's environment for exfiltration. The data was exfiltrated before either SOC escalated the incident to the other party.

What is the Vendor SOC Integration Problem, Really?

Vendor SOC integration is the operational coordination between a vendor's and a customer's security operations teams , specifically the mechanisms for real-time communication during shared incidents, for escalating detections relevant to the other party's environment, and for correlating events across both environments to identify attacks that span the vendor-customer relationship. In the absence of SOC integration, two mature security operations teams can be investigating the same attack from different sides simultaneously without either knowing the other has detected related activity.

The investigative silos problem is the core integration failure. Independent SOC investigations of the same attack produce duplicated effort, delayed escalation, and missed correlation opportunities. Indicators in the vendor's environment that would contextualise and accelerate the customer's investigation are not shared in real time because no real-time sharing mechanism exists between the two SOC teams. Similarly, the customer's detection of related activity would have immediately elevated the vendor's investigation priority if the vendor's SOC had known about it. The three-hour gap between vendor and customer detection exists in part because neither SOC was informed of the other's investigation.

The cross-boundary attack correlation problem is the specific gap that SOC integration addresses. Supply chain attacks by definition span organisational boundaries , the attacker operates in the vendor's environment to reach the customer's environment. The indicators of the attack are distributed across both environments. Correlating indicators from both environments requires either log sharing that enables joint analysis, or real-time escalation between SOC teams when cross-environment attack patterns are detected. Without cross-boundary correlation capability, each SOC sees only its own side of the attack.

• Independent SOC investigations running simultaneously without coordination
• No real-time escalation mechanism between vendor and customer SOC teams
• Cross-boundary attack correlation absent , indicators in separate environments not correlated
• No joint incident response trigger , when does a vendor detection escalate to customer SOC
• Investigative gap exploitation by attackers who understand SOC coordination limitations

Why this matters

Vendor SOC integration matters for TPRM because sophisticated supply chain attackers understand and exploit the investigative gaps between independent security operations teams. An attacker who knows that the vendor's SOC will investigate their environment independently and the customer's SOC will investigate their environment independently can operate in the coordination gap , the window between when each SOC detects activity and when they escalate to the other , to complete their objectives. SOC integration closes this gap by establishing cross-boundary escalation before the attack.

Where most teams get this wrong

The most consistent failure is assessing each SOC's independent maturity without assessing the integration between them. Vendor SOC maturity and customer SOC maturity are each assessed in isolation. The coordination gap between them , the joint investigative capability , is not assessed because it is not a property of either individual SOC.

• SOC integration gap not assessed , only individual SOC maturity
• No joint escalation trigger , when vendor detection should escalate to customer SOC
• No cross-boundary log correlation established
• Real-time escalation channel not established before incident
• Joint IR table-top not including cross-boundary scenarios

What good looks like

Mature SOC integration programmes establish specific escalation triggers , the conditions under which the vendor's SOC will immediately notify the customer's SOC , and direct communication channels between the two teams that enable real-time coordination during shared investigations.

• Escalation triggers defined , conditions under which vendor detection escalates immediately to customer SOC
• SOC-to-SOC emergency channel , direct communication between operations teams
• Cross-boundary log correlation for highest-risk relationships , shared log forwarding or joint SIEM view
• Joint incident response scenarios in annual tabletop
• Shared threat intelligence , vendor IOCs forwarded to customer SOC in real time

Tooling

SOC Communication , secure messaging, PagerDuty escalation paths

Direct SOC-to-SOC communication channels , established emergency contacts, shared incident management platforms, and secure messaging for sensitive IOC sharing , enable the real-time coordination that separate communication structures delay. For TPRM practitioners, establishing direct SOC team contacts with critical vendors and including them in joint incident scenarios provides the foundation for SOC integration.

Governance challenges

The governance challenge with SOC integration is the privacy and operational complexity of cross-boundary coordination. Vendor SOCs cannot generally provide customer SOCs with direct access to their investigation systems without exposing other customers' data and investigation activities. The governance resolution is defined escalation triggers and direct communication channels , not full system access, but a pre-defined call that goes to a named analyst when specific cross-boundary indicators are detected.

• Establish direct SOC-to-SOC emergency contacts with critical vendors
• Define escalation triggers , what vendor detections warrant immediate customer SOC notification
• Include joint scenarios in annual tabletop exercises
• Establish shared threat intelligence channel for real-time IOC sharing
• Test cross-boundary escalation before an incident requires it

If you are a small team

For your highest-risk vendor, establish the SOC-to-SOC contact , the specific analyst or SOC lead at the vendor who would receive a call from your SOC during a shared incident. Exchange contact details. Test the contact with an introductory call. Agree on one escalation trigger: if your vendor's SOC detects anomalous activity involving the systems or IP ranges directly associated with your organisation's connection to their environment, they will call your SOC directly before completing their internal triage. That single bilateral trigger closes the three-hour investigative gap that the sophisticated attacker exploited.

• Establish SOC-to-SOC emergency contact at highest-risk vendor
• Test the contact with an introductory call
• Agree on one bilateral escalation trigger
• Include joint scenario in next tabletop exercise

What to require

Ask directly:

"If your SOC detects anomalous activity involving the systems or connections associated with our organisation, what is the trigger for escalating that detection directly to our SOC rather than completing your internal investigation first , and can we establish a direct SOC-to-SOC contact for exactly that scenario?"

Expect as evidence

• Customer-relevant escalation trigger definition
• SOC-to-SOC direct contact
• Cross-boundary escalation procedure
• Real-time IOC sharing mechanism

A vendor with a mature SOC should be asked what triggers a direct call to the customer's SOC rather than completing an internal investigation first. The SOC maturity is the capability. The escalation trigger and the direct contact are the integration.

How to evidence it

• SOC-to-SOC contact records
• Escalation trigger documentation
• Joint tabletop exercise records
• Cross-boundary escalation test records

Key Takeaway

Two mature SOCs. Three hours of independent parallel investigation. The attacker staged data for exfiltration in the window between the vendor's detection and the customer's detection, before either escalated to the other. Both SOCs were operating correctly within their own scope. The scope gap , the three hours of uncoordinated investigation , was the attack surface. SOC integration is not a property of either individual SOC. It is the coordination arrangement between them. The escalation trigger and the direct contact establish the integration. The joint tabletop tests it. The three-hour gap closes when the first detection triggers the cross-boundary call rather than the internal investigation completion.

More on Security

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