Third-party Risk Assessment — Flashcards

Vulnerability scan: automated tool-based assessment that identifies and categorizes potential weaknesses in systems. Passive — does not attempt to exploit vulnerabilities. Output: list of potential weaknesses with severity ratings. Fast, cheap, can run frequently. Answer it provides: "What vulnerabilities might exist?" Penetration test: simulated attack by a skilled human tester who actively attempts to exploit identified vulnerabilities. Active — actually exploits weaknesses to gain unauthorized access, escalate privileges, or exfiltrate data. Output: confirmed exploitable vulnerabilities + evidence of what an attacker could achieve. More expensive, labor-intensive, typically done annually or for major changes. Answer it provides: "Can an attacker actually get in, and what could they do?" Key exam distinction: pen test = active exploitation. Vuln scan = passive identification. Both are valuable; pen tests go further by proving exploitability. Third-party context: requiring vendors to provide recent pen test reports is standard due diligence. A vendor with no pen test history has a security assurance gap.

Rules of engagement (ROE): a formal document agreed upon by both the testing organization and the target organization before a penetration test begins. Defines the boundaries and parameters of the engagement. Required elements: (1) Scope: which IP ranges, domains, systems, applications are in-scope and which are explicitly out-of-scope. Out-of-scope systems must not be touched even if accessible. (2) Schedule: when testing may occur (business hours, after hours, specific days). (3) Authorized techniques: what attack types are permitted (social engineering, physical, DoS, etc.) and which are prohibited. (4) Emergency contacts: who to call if production is accidentally taken down or if a critical vulnerability with active exploitation risk is found. (5) Data handling: how sensitive data discovered during testing must be handled and reported. Why ROE matters: protects tester from legal liability (authorized testing vs. unauthorized attack). Protects organization from unexpected production damage. Exam note: rules of engagement must be agreed BEFORE testing begins, never after.

Right-to-audit clause: a contractual provision granting the customer organization the right to directly audit the vendor's security controls, processes, and compliance status. Typically includes how much advance notice is required (e.g., 30 days written notice) and what the audit may cover. Why it matters: without a right-to-audit clause, the organization can only rely on vendor self-reporting and external certifications (SOC 2, ISO 27001). These are valuable but not as direct as the ability to audit personally. With the clause, the organization can send auditors to verify that the vendor is actually implementing the security controls they claim. Negotiation significance: vendors who refuse to include right-to-audit clauses during contract negotiation raise a significant red flag. A vendor comfortable with transparency has nothing to hide; refusal suggests something to hide. What audits cover: access management, data handling, incident response capabilities, patch management, physical security, compliance status, and contractual security obligations. Relationship to data risk: right-to-audit is most critical for vendors who handle sensitive customer data.

Independent assessment: security evaluation conducted by an outside firm that has no business relationship with either the customer organization or the vendor being assessed. The key value is objectivity. Why independence matters: vendors conducting self-assessments have an inherent conflict of interest. They are unlikely to report findings that damage their commercial reputation or revenue. Internal assessors may miss gaps due to familiarity bias. An independent firm with no stake in the outcome reports what it finds without commercial pressure. SOC 2 Type II reports: the most common form of independent assessment requested during vendor due diligence. Produced by an independent CPA firm. Covers five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type II specifically covers controls over a defined period (6-12 months), not just a point-in-time snapshot. Broad industry experience: independent assessors have benchmarked many organizations. They know what "good" security looks like across the industry and can identify gaps that a vendor's own team would normalize. Requesting SOC 2: standard practice during vendor due diligence for cloud and SaaS vendors.

What happened: between March and June 2020, attackers (attributed to Russian state-sponsored group Cozy Bear / APT29) inserted malicious code into the build pipeline of SolarWinds' Orion network monitoring software. Attack mechanism: the malicious code was compiled into legitimate Orion software updates. The updates were digitally signed with SolarWinds' valid code-signing certificate, making them appear completely authentic. Customers who applied the update (standard patch management) unknowingly installed a backdoor. Scale: approximately 18,000 of SolarWinds' 300,000+ customers installed the compromised update. Victims included US government agencies (Treasury, Homeland Security, Commerce) and major private sector organizations. Discovery: FireEye discovered the backdoor in December 2020 while investigating their own breach. SolarWinds publicly disclosed in December 2020. Why it matters: demonstrates that supply chain attacks bypass many standard controls. Even legitimate software from a trusted vendor, signed with valid certificates, can carry malware. Traditional perimeter and endpoint controls cannot detect this attack type. Exam point: SolarWinds = canonical supply chain attack example.

Supply chain attack: an attack that targets a trusted supplier, software vendor, or technology partner rather than the victim organization directly. Malicious code or access travels through legitimate delivery mechanisms (software updates, hardware components, managed services) into victim environments. Why supply chain attacks are effective: they exploit trust. Organizations allow software from known vendors. They update approved software automatically. They trust hardware from established suppliers. Supply chain attacks abuse these legitimate trust relationships. Reducing supply chain risk: (1) Software Bill of Materials (SBOM): complete inventory of all software components, libraries, and dependencies. (2) Software composition analysis: automated scanning of third-party code for known vulnerabilities. (3) Vendor security questionnaires covering sub-supplier relationships. (4) Code signing verification with certificate pinning. (5) Behavioral monitoring of software after installation (detect anomalous behavior even from "trusted" software). (6) Contractual requirements that vendors maintain security standards for their own suppliers. Limitation: supply chain risk is difficult to fully eliminate because organizations must trust some external code and components to function.

Vendor due diligence is performed before entering a vendor relationship to verify the vendor meets security and operational requirements. Due diligence components: (1) Financial verification: confirm financial stability (credit ratings, financial statements, banking references). A financially unstable vendor creates continuity and data recovery risk. (2) Background checks: verify the vendor organization and key personnel do not have histories of security incidents, regulatory violations, or legal judgments. (3) Security questionnaires: formal assessment of the vendor's security policies, controls, incident response, data handling, and compliance (SIG questionnaire is a common standardized format). (4) Reference checks: speak with current customers specifically about incident handling and security responsiveness. (5) Certifications and audit reports: request SOC 2 Type II, ISO 27001 certification, or relevant compliance certifications. (6) Conflict of interest detection: verify no undisclosed relationships that could compromise vendor objectivity or loyalty. Purpose: reduce the risk of engaging a vendor who cannot meet security, financial, or operational requirements before the relationship begins.

Vendor monitoring is continuous because vendors change after initial selection. Financial conditions, security posture, staffing, and regulatory status all evolve. Ongoing monitoring components: (1) Periodic security reviews: annual (or more frequent) re-assessment using updated security questionnaires and review of new audit reports. (2) Financial health monitoring: subscription services that alert on vendor bankruptcy filings, adverse credit ratings, and major financial events affecting service continuity. (3) News and social media monitoring: track reports of vendor data breaches, regulatory actions, executive misconduct, or reputational events that indicate increased risk. (4) Vendor owner assignment: each significant vendor has an internal owner responsible for maintaining the relationship, tracking questionnaire status, escalating concerns, and ensuring contractual security obligations are met. Why ongoing monitoring matters: a vendor that passed initial due diligence two years ago may have had a data breach, lost key security staff, changed sub-suppliers, or entered financial difficulty since then. Initial vetting provides a point-in-time snapshot; ongoing monitoring maintains current awareness. Triggers for immediate review: vendor announces a breach, regulatory action, major leadership change, acquisition, or bankruptcy filing.

Conflict of interest: a situation where the vendor's interests are not fully aligned with the customer organization's interests, or where a person making vendor decisions has a personal interest that could bias that decision. Examples: (1) A partner company also serves direct competitors — vendor could share competitive intelligence. (2) A procurement executive's family member is employed by the vendor — creates obligation that distorts objective evaluation. (3) Vendor offers gifts, entertainment, or travel to procurement staff — creates social obligation that can compromise evaluations. (4) A vendor's security assessor also provides security consulting to the same organization — independence is compromised. (5) Vendor relationship where volume discounts create pressure to expand scope beyond what security requires. Detection mechanisms: vendor disclosure requirements in contracts (vendors must report conflicts), background checks on key vendor personnel, gifts and entertainment policies requiring disclosure to compliance, rotation of vendor relationship ownership to prevent "relationship capture" (where a relationship manager becomes too aligned with the vendor's interests). Response to detected conflicts: disclosure to ethics/compliance, recusal of the affected individual from vendor decisions, increased audit scrutiny of the vendor relationship.

Black-box testing: tester has no prior knowledge of the target environment. Simulates an external attacker who has no insider information. Must enumerate and discover the attack surface independently. Most realistic simulation of an opportunistic external attack. Most time-consuming because enumeration is required. White-box testing: tester has full knowledge of the target: network diagrams, source code, credentials, architecture documentation. Simulates an insider threat or a knowledgeable attacker who has obtained detailed information. Most thorough — tester can focus on testing rather than discovery. Used for comprehensive security reviews and code audits. Gray-box testing: tester has partial knowledge (some network information, some credentials, some architecture documentation). Simulates an attacker who has done some reconnaissance or obtained some insider information. Most common in vendor assessments — balances realism with efficiency. Exam selection: which to use depends on the threat model. External attacker simulation = black-box. Insider threat simulation = white-box. Efficient comprehensive review = white-box. Typical third-party vendor assessment = gray-box.

During selection — red flags: Refuses to provide security questionnaire responses. Cannot produce a SOC 2 report or equivalent independent assessment. Refuses right-to-audit clause in contract. Has a recent data breach history with inadequate remediation. Financial instability (low credit rating, recent bankruptcy protection). Key security personnel have recently departed. Sub-suppliers have known security issues. During monitoring — escalation triggers: Vendor publicly announces a data breach affecting customer data. Regulatory action filed against the vendor (fines, consent decrees). Media reports of internal security failures. Failure to provide annual questionnaire or updated audit report on schedule. Key contractual security obligations (patch timelines, access controls) are confirmed not being met. Financial deterioration (credit downgrade, acquisition by a financially troubled entity). Response options: (1) Issue formal cure notice requiring remediation within a defined period. (2) Increase audit frequency and scrutiny. (3) Require additional contractual security commitments. (4) Begin contingency planning for vendor replacement. (5) Terminate contract if contractual security obligations are materially breached.