Use Case: Insider Threat & Third Party
Third-party credential misuse
Your managed services vendor's account authenticated from a new country at 3 AM and accessed systems outside their normal support scope. ManySignal flagged the behavioral deviation before any data was accessed.
The breach that started with a vendor
The Target breach (2013), the SolarWinds breach (2020), and the Kaseya VSA attack (2021) share a common theme: the initial access vector was a trusted third-party vendor with legitimate access to the target's environment. Vendors are often granted broad access during implementation and then forgotten — their accounts persist, accumulate permissions, and are monitored less rigorously than internal accounts.
When a vendor's credentials are compromised — whether through their own security failure, a phishing attack, or a breach of their systems — the attacker inherits the vendor's trusted access to your environment. Without behavioral baselines for vendor accounts, these logins are indistinguishable from legitimate vendor activity.
rule: vendor_credential_misuse
type: behavioral_baseline + scope_check
sources:
- okta / entra_id (external_user_auth)
- aws_cloudtrail (vendor_role_assumption)
- app_audit_logs
trigger:
- condition: |
account.type == "external_vendor"
AND (
auth_ip.asn NOT IN vendor.known_asns
OR auth_time NOT IN vendor.typical_access_hours
OR resource_accessed NOT IN vendor.approved_scope
)
enrichments:
- vendor_baseline: 90d_access_pattern
- vendor_contract: approved_systems, access_expiry
- ip_geolocation: country_vs_vendor_location
- scope_comparison: accessed_vs_permitted_resources
mitre: T1199 (Trusted Relationship), T1078 (Valid Accounts)MITRE ATT&CK mapping
Vendor credential misuse FAQ
How does ManySignal establish a behavioral baseline for vendor accounts?
Vendor accounts are cataloged as external identities in the entity graph. ManySignal builds a baseline from their authentication history: which IP ranges they authenticate from, what times of day they access the environment, which specific resources they access, and what API calls they make. Any deviation from this baseline triggers a risk signal.
What's the highest risk indicator for vendor credential compromise?
Authentication from a new IP outside the vendor's known IP ranges is the primary signal. This indicates either the credential is being used by an unauthorized party, or the vendor's systems have been compromised. Combined with access to resources outside the vendor's normal scope, this combination is near-certain evidence of misuse.
How does ManySignal handle vendors with dynamic IP addresses?
Vendors using dynamic IPs are characterized by their ASN (internet service provider) rather than specific IPs. Changes in ASN — the vendor suddenly authenticating from a different ISP or country — are flagged as anomalous even if the specific IP is new. Vendors with VPN solutions can register their VPN exit IPs as trusted ranges.
Does ManySignal help with third-party access reviews for SOC 2 and ISO 27001?
Yes. ManySignal generates a vendor access report showing all third-party accounts, their last activity date, the specific resources they've accessed, and any anomalous events. This report can be exported as evidence for access certification reviews required by SOC 2 CC6.6 and ISO 27001 A.15.1.
Monitor third-party access with the same rigor as internal accounts
Vendor behavioral baselines with scope enforcement and access review automation.