Attack Surface Management
Third-Party Attack Surface Risks: Managing Vendor Security
Third-party attack surface risk arises because your security depends on your vendors' security. A vendor breach exposes your data; a compromised vendor tool provides attackers access to your environment. Management strategies include: vendor security assessments before onboarding, continuous monitoring of vendor security posture, contractual security requirements, data minimization with vendors, network segmentation for vendor access, and incident notification requirements.
Andreas Johansson · Chief Executive Officer
Senior IT management leader with 25 years of experience in Cloud, Security, and Datacenter infrastructure.
Your Attack Surface Extends Beyond Your Assets
Your organization's security doesn't stop at the assets you own and operate. Every vendor, partner, SaaS provider, and supply chain dependency that handles your data or connects to your systems becomes part of your effective attack surface.
When a vendor is breached, your data is compromised. When a vendor's software is compromised, your systems are at risk. When a vendor's security is weak, attackers may target them as a path to reach you.
Third-party risk is not theoretical. In the SolarWinds attack, fewer than 18,000 customers installed a backdoored update from a single software vendor. The MOVEit breach affected 2,500+ organizations through a file transfer tool. The Kaseya attack reached up to 1,500 downstream businesses through a remote management platform.
Categories of Third-Party Risk
SaaS and Cloud Service Providers
Every SaaS application your organization uses stores, processes, or transmits your data. A breach of that SaaS provider is a breach of your data.
- Risk factors:
- Data stored in vendor's infrastructure (you don't control security)
- Authentication integration (SSO/OAuth connections)
- API access to your data (over-permissioned integrations)
- Data residency and sovereignty (where does the vendor store data?)
- Vendor's own security practices and certifications
Software Supply Chain
Software your organization uses — operating systems, frameworks, libraries, and commercial applications — is part of your attack surface.
- Risk factors:
- Vulnerabilities in software dependencies
- Compromised software updates (SolarWinds, 3CX)
- Malicious packages in open-source repositories
- Build system compromises injecting malicious code
Managed Service Providers (MSPs)
IT service providers with administrative access to your systems represent high-privilege third-party risk.
- Risk factors:
- Privileged access to your infrastructure
- Shared tools across multiple customers (one compromise, many victims)
- Variable security practices across MSP staff
- Remote access pathways into your network
Business Partners and Integrations
Partners with system-to-system integrations, shared data, or network connectivity extend your attack surface.
- Risk factors:
- Network-to-network connections (VPN, dedicated links)
- Data sharing agreements with varying security standards
- Integration endpoints that bypass perimeter controls
- Partner credential management practices
Assessment and Management
Pre-Onboarding Assessment
Before engaging a new vendor:
- Security questionnaire. Standardized questionnaires (SIG, CAIQ, or custom) assess vendor security controls. Focus on: data protection, access management, incident response, compliance certifications, and vulnerability management.
- Compliance verification. Verify claimed certifications — SOC 2 Type II reports, ISO 27001 certificates, and relevant industry certifications. Request audit reports, not just claims.
- Technical assessment. For high-risk vendors: external attack surface assessment of the vendor's infrastructure, review of their security architecture, and penetration test results.
- Risk classification. Categorize vendors by risk level based on data access, system connectivity, business criticality, and security maturity. High-risk vendors require deeper assessment and ongoing monitoring.
Contractual Requirements
Security expectations should be contractually defined:
- Data protection requirements. Encryption, access controls, data residency, and retention/deletion obligations
- Security controls. Minimum security standards the vendor must maintain
- Incident notification. Obligation to notify you of security incidents within a defined timeframe (24-72 hours)
- Audit rights. Right to audit or assess the vendor's security controls
- Subprocessor management. Requirements for the vendor's own third parties
- Termination data handling. Data return and deletion obligations upon contract termination
Continuous Monitoring
One-time assessment is insufficient. Vendor security posture changes over time:
- External monitoring. Use ASM tools to monitor vendors' external security posture — exposed services, misconfigured assets, certificate issues, and data exposures.
- Security ratings. Services like SecurityScorecard, BitSight, and UpGuard provide continuous security ratings for organizations, enabling ongoing monitoring of vendor posture.
- Compliance monitoring. Track vendor compliance certifications — SOC 2 reports are annual. Ensure reports remain current and address identified issues.
- Threat intelligence. Monitor for breach reports, vulnerability disclosures, and threat intelligence involving your vendors.
Incident Response Integration
Plan for third-party incidents:
- Notification procedures. How will you learn about vendor incidents? Contractual notification plus monitoring.
- Impact assessment. Pre-documented process for assessing impact of vendor incidents on your data and operations.
- Containment options. Can you isolate vendor connections? Revoke API access? Switch to alternative services?
- Communication plan. How will you communicate with your customers if a vendor incident affects their data?
Reducing Third-Party Risk
- Minimize data sharing. Give vendors only the data they need. Less data shared means less data exposed in a breach.
- Segment vendor access. Network segmentation and zero-trust access controls limit what vendors can reach. Vendor VPN connections should only access the systems they need.
- Use least-privilege API access. API integrations should have minimum necessary permissions. Read-only where possible. Scope access to specific data sets.
- Diversify critical dependencies. Avoid single points of failure. If a critical vendor is compromised, can you continue operations?
- Regular access review. Quarterly review of vendor access — remove access for terminated vendor relationships, reduce permissions where they've expanded beyond necessity.
How SeqOps fits
SeqOps covers the cloud and server part of your attack surface: it inventories resources in your connected cloud accounts and flags exposed services and misconfigurations. It doesn't scan the internet for assets you haven't connected.
Sources
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices (2022)
- SolarWinds Corp., Form 8-K filed with the SEC (14 Dec 2020) (2020)
- Emsisoft, Unpacking the MOVEit Breach: Statistics and Analysis (2,773 organisations as of 28 June 2024) (2024)
- Kaseya press release, Kaseya Responds Swiftly to Sophisticated Cyberattack (5 July 2021) (2021)
- CISA Advisory AA23-158A, CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability (2023)