EDUCATION, SUPPLY CHAIN, TPRM

🔗 Trešo pušu un piegādes ķēžu pārvaldība

Kā pārvaldīt risku, ko ievieš piegādātāji, pakalpojumu sniedzēji un programmatūras atkarības - pēc starptautiskās prakses (ISO 27036, NIST SP 800-161, NIS2, DORA, CRA, SLSA). Piemēri ir izdomāti, paredzēti apmācībām.

Kāpēc tas svarīgi

Paplašinātā uzbrukuma virsma - katra trešā puse ievieš risku

Trešo pušu uzbrukuma virsma Organizācija centrā, ap to seši trešo pušu tipi, kuru piekļuve un datu plūsma paplašina riska perimetru. Paplašinātā uzbrukuma virsma Katra puse ar piekļuvi vai datu plūsmu ir daļa no tava riska perimetra TAVA ORGANIZĀCIJA aktīvi, dati, klienti SaaS / mākoņi M365, CRM, datu glabāšana Atvērtā pirmkoda kods npm, PyPI, atkarības MSP / IT atbalsts attālā privilēģētā piekļuve Aparatūra / firmware ražotāji, iekārtas Maksājumi / API partneru integrācijas Apakšuzņēmēji 4th-party (n-tā puse) piekļuve, dati, uzticība Trešās puses risku pārvalda kā SAVU: NIS2 21. panta 2. punkta d) apakšpunkts prasa piegādes ķēdes drošību. Ievērojami incidenti: SolarWinds (2020), Log4Shell (2021), MOVEit (2023), XZ Utils backdoor (2024)

Kas ir trešās puses risks

Risks, ko organizācijai rada ārējie piegādātāji, pakalpojumu sniedzēji un programmatūras komponentes ar piekļuvi taviem datiem, sistēmām vai procesiem. Tu paliec atbildīgs par sekām pat tad, ja vainīga ir trešā puse.

Saistītie standarti

ISO/IEC 27036 (piegādātāju attiecību drošība), NIST SP 800-161 Rev. 1 (C-SCRM), NIST CSF 2.0 funkcija GOVERN (GV.SC), NIS2 21(2)(d), DORA (finanšu ICT trešās puses), CRA (produktu drošība).

Ceturtās puses risks

Tava piegādātāja piegādātāji (ceturtā un tālākās puses) un koncentrācijas risks (pārāk liela atkarība no viena mākoņa vai pakalpojuma) bieži paliek neredzami, bet var apturēt darbību tāpat kā tiešs incidents.

Trešās puses dzīves cikls

TPRM dzīves cikls ar nepārtrauktu pārvērtēšanu

TPRM dzīves cikls Seši posmi no plānošanas līdz izbeigšanai ar nepārtrauktas pārvērtēšanas cilpu. Trešās puses risku pārvaldības dzīves cikls Shared Assessments / ISO 27036 - riska pārvaldība no iepirkuma līdz izbeigšanai 1. Plānošana vajadzība, scope kritiskuma tiering kādi dati, kāda piekļuve 2. Due diligence pirms parakstīšanas SIG, SOC 2, ISO sert. drošības stāvoklis 3. Līgums DPA (GDPR 28. p.) SLA, right-to-audit incidentu paziņošana 4. Onboarding least privilege piekļuves provizēšana integrācija, MFA 5. Monitorings nepārtraukts security ratings periodiska reassess 6. Izbeigšana piekļuves atsaukšana datu atdošana/dzēšana offboarding periodiska pārvērtēšana (risk-based) Kritiskākos piegādātājus pārvērtē biežāk. Sadarbības beigas ir tikpat svarīgas kā sākums. Atsauce: Shared Assessments TPRM Framework, ISO/IEC 27036, NIST SP 800-161

Due diligence pirms līguma

Pirms sadarbības novērtē piegādātāja drošības stāvokli: standartizētas anketas (Shared Assessments SIG), neatkarīgi atzinumi (SOC 2 Type II, ISO 27001 sertifikāts), ielaušanās testu kopsavilkumi un finanšu stabilitāte.

Līguma drošības klauzulas

Datu apstrādes līgums (DPA, GDPR 28. pants), SLA ar drošības mērķiem, tiesības veikt auditu (right-to-audit), incidentu paziņošanas termiņi, apakšapstrādātāju apstiprināšana un datu atdošana/dzēšana izbeidzot.

Nepārtraukts monitorings

Ar vienu anketu nepietiek - drošības stāvoklis mainās. Seko drošības reitingiem, ievainojamību brīdinājumiem un sertifikātu derīgumam, un pārvērtē piegādātāju regulāri - jo kritiskāks, jo biežāk.

Tiering un due diligence dziļums

Kritiskuma klasifikācija nosaka pārbaudes dziļumu

Riska klasifikācija Trīs kritiskuma līmeņi (Tier 1-3) ar atbilstošu due diligence dziļumu. Piegādātāju kritiskuma klasifikācija (tiering) Datu jutīgums × piekļuves līmenis × biznesa ietekme → tiers → pārbaudes dziļums LĪMENIS KRITĒRIJI DUE DILIGENCE Tier 1, Kritisks augsta atkarība grūti aizvietojams - piekļuve sensitīviem/personas datiem - kritiskas sistēmas vai privilēģēta piekļuve - dīkstāve apdraud pamatdarbību SOC 2 Type II + on-site audits pen-test kopsavilkums, BCP/DR pārvērtēšana ≥ reizi gadā Tier 2, Svarīgs ierobežota piekļuve aizvietojams ar pūlēm - ierobežota vai netieša datu piekļuve - svarīgs, bet ne kritisks pakalpojums - mērena biznesa ietekme SIG Core + ISO 27001 sertifikāts security ratings monitorings pārvērtēšana ik 1-2 gadi Tier 3, Zems nav datu piekļuves viegli aizvietojams - nav piekļuves datiem/sistēmām - standarta, plaši pieejams produkts - minimāla biznesa ietekme SIG Lite / pašnovērtējums pamata līguma klauzulas pārvērtēšana pēc vajadzības

Kāpēc tiering

Visi piegādātāji nav vienlīdz riskanti. Klasifikācija ļauj ierobežotos resursus veltīt kritiskākajiem - dziļa pārbaude tur, kur sekas ir vislielākās, viegla tur, kur risks ir minimāls.

Standartizētas anketas

Shared Assessments SIG (Standardized Information Gathering) - nozares standarta anketa drošības stāvokļa novērtēšanai. SIG Lite zemākam riskam, SIG Core dziļākai pārbaudei. CAIQ (Cloud) mākoņpakalpojumiem.

Neatkarīgi atzinumi

SOC 2 Type II (AICPA) - kontroles efektivitāte laika periodā. ISO/IEC 27001 sertifikāts - ISMS atbilstība. ISAE 3402 starptautiskiem pakalpojumiem. Tie samazina nepieciešamību pēc paša audita.

Software supply chain

Programmatūras piegādes ķēde - uzbrukumi un aizsardzība

Programmatūras piegādes ķēde Izstrādes konveijers ar uzbrukumu punktiem (apakšā) un aizsardzības kontrolēm (augšā). Programmatūras piegādes ķēde Augšā - aizsardzība (SLSA, SBOM). Apakšā - uzbrukumu punkti AIZSARDZĪBA SBOM (SPDX/CycloneDX), SLSA provenance, parakstīšana (Sigstore/cosign), SCA skenēšana, lockfiles, OpenSSF Scorecard Pirmkods git, izstrādātāji Atkarības npm, PyPI, Maven Build CI/CD konveijers Artefakts attēls, pakotne Deploy reģistrs, prod Kompromitēts uzturētājs / commit (XZ Utils 2024) Typosquatting / dependency confusion ļaunprātīga pakotne Build sistēmas kompromitēšana (SolarWinds 2020) Neparakstīts vai viltots artefakts integritātes trūkums Kompromitēts reģistrs / update (3CX 2023) SLSA (Supply-chain Levels for Software Artifacts) definē build integritātes līmeņus. SBOM dod komponentu caurspīdīgumu (ASV EO 14028).

SBOM - komponentu saraksts

Software Bill of Materials - mašīnlasāms visu programmatūras komponentu un atkarību saraksts (formāti SPDX, CycloneDX). Ļauj ātri noteikt, vai tevi skar jauna ievainojamība (piem., Log4Shell).

SLSA un parakstīšana

SLSA (OpenSSF) - build integritātes līmeņi ar provenance (izcelsmes pierādījumu). Artefaktu parakstīšana ar Sigstore/cosign ļauj pārbaudīt, ka pakotne nāk no uzticama būvējuma un nav viltota.

Atkarību higiēna

Fiksētas versijas un lockfile (atkārtojami būvējumi), SCA skenēšana (OWASP Dependency-Check, pip-audit, Trivy), transitīvo atkarību uzraudzība un OpenSSF Scorecard projekta veselības novērtēšanai pirms ieviešanas.

Standarti un regulējums

Piegādes ķēdes drošības standartu ainava

Standartu ainava Pieci standartu un regulējuma bloki piegādes ķēdes drošībai. Standarti un regulējums Izvēlies pēc mērķa - tie bieži pārklājas un papildina cits citu ISO/IEC 27036 piegādātāju attiecību drošība (4 daļas) 28000 piegādes ķēdes drošības pārvaldība 27001 A.5.19-23 piegādātāju attiecību kontroles NIST SP 800-161 C-SCRM prakses organizācijām CSF 2.0 GV.SC supply chain risk (GOVERN funkcija) SP 800-218 SSDF droša izstrāde (software) ES regulējums NIS2 21(2)(d) piegādes ķēdes drošība (obligāti) DORA ICT trešās puses (finanšu sektors) CRA produktu ar digitālo elementu drošība SW integritāte SLSA build līmeņi + provenance (OpenSSF) SBOM SPDX, CycloneDX (NTIA min. elementi) Scorecard OpenSSF projekta veselības vērtējums Novērtēšana SOC 2 / ISAE 3402 neatkarīgs atzinums Shared Assess. SIG standarta anketa CIS Control 15 service provider management NIS2 prasa piegādes ķēdes drošību kā obligātu pasākumu - pārējie standarti dod tehnisko un metodisko ieviešanu.

NIS2 - juridiskā prasība

NIS2 direktīvas (ES 2022/2555) 21. panta 2. punkta d) apakšpunkts nosaka piegādes ķēdes drošību kā obligātu riska pārvaldības pasākumu, ieskaitot drošības aspektus attiecībās ar tiešajiem piegādātājiem un pakalpojumu sniedzējiem.

ISO 27036 un NIST 800-161

ISO/IEC 27036 dod pārvaldības ietvaru piegādātāju attiecību drošībai. NIST SP 800-161 Rev. 1 (C-SCRM) - detalizētas prakses kiberdrošības piegādes ķēdes risku pārvaldībai sistēmu un organizāciju līmenī.

DORA un CRA

DORA (Regula (ES) 2022/2554, piemēro no 2025. gada 17. janvāra) reglamentē finanšu sektora IKT trešo pušu risku un kritisko pakalpojumu sniedzēju uzraudzību. Cyber Resilience Act (Regula (ES) 2024/2847) uzliek drošības prasības produktu ar digitālajiem elementiem ražotājiem visā ES tirgū: ziņošana par aktīvi izmantotām ievainojamībām no 2026. gada 11. septembra, pilnas prasības no 2027. gada 11. decembra.

Praktiskās kontroles

Kontroles trijos slāņos + neredzamie riski

Kontroles slāņi Līgumiskās, tehniskās un organizatoriskās kontroles, kā arī koncentrācijas un ceturtās puses risks. Kontroles un aizsardzība Defense-in-depth: kontroles trijos savstarpēji papildinošos slāņos Līgumiskās pirms un laikā DPA (GDPR 28. p.) SLA + drošības mērķi right-to-audit incidentu paziņošana (termiņi) apakšapstrādātāju apstiprināšana Tehniskās ikdienā least privilege segmentācija MFA + piekļuves žurnāli monitorings SBOM + SCA Zero Trust piekļuvei Organizatoriskās pārvaldība tiering / reģistrs periodiska reassess offboarding process incidentu reaģēšanas plāns 4th-party kartēšana un uzraudzība Neredzamie riski Koncentrācijas risks pārāk liela atkarība no viena mākoņa/pakalpojuma Ceturtās puses risks piegādātāja piegādātāji Gatavība incidentam - piegādātāja incidents = tavs incidents (NIS2 23. p.) - iekļauj piegādātājus IR plānā un mācībās - exit / aizvietošanas plāns Atsauce: CIS Control 15, ISO 27036, NIST SP 800-161, NIS2 21. un 23. pants

Līgums ir pirmā aizsardzības līnija

Drošības prasības jāiestrādā līgumā pirms parakstīšanas - vēlāk tās pievienot ir grūti. Datu apstrādes līgums, SLA ar mērāmiem drošības mērķiem, audita tiesības un skaidri incidentu paziņošanas termiņi.

Tehniskā izolācija

Piešķir piegādātājam tikai nepieciešamo (least privilege), izolē viņa piekļuvi (segmentācija, Zero Trust), pieprasi MFA un žurnalē darbības. Tā ierobežo kaitējumu, ja piegādātājs tiek kompromitēts.

Plāno izeju jau sākumā

Koncentrācijas un ceturtās puses risks prasa plānu, kā piegādātāju aizstāt, un nepārtrauktības pārbaudi. Piegādātāja incidents ir tavs incidents - iekļauj piegādātājus incidentu reaģēšanas plānā un mācībās.

Saīsinājumi

Ceļvedī lietotie saīsinājumi: oriģinālais nosaukums un ko tas nozīmē.

TPRM
Third-Party Risk Management - trešo pušu risku pārvaldība.
C-SCRM
Cyber Supply Chain Risk Management - kiberdrošības piegādes ķēdes risku pārvaldība (NIST SP 800-161).
SBOM
Software Bill of Materials - programmatūras sastāvdaļu un atkarību saraksts.
SPDX / CycloneDX
Divi SBOM formāti.
SLSA
Supply-chain Levels for Software Artifacts - būvēšanas integritātes līmeņi.
SCA
Software Composition Analysis - atkarību pārbaude pret zināmām ievainojamībām.
SSDF
Secure Software Development Framework - NIST drošas izstrādes prakses (SP 800-218).
SIG
Standardized Information Gathering - Shared Assessments piegādātāju drošības anketa.
CAIQ
Consensus Assessments Initiative Questionnaire - mākoņpakalpojumu drošības anketa (CSA).
SOC 2
System and Organization Controls 2 - neatkarīga revidenta atzinums par pakalpojuma sniedzēja kontrolēm.
ISAE 3402
Starptautisks standarts pakalpojumu organizāciju kontroļu atzinumam.
AICPA
American Institute of Certified Public Accountants - ASV revidentu institūts, kas izdod SOC standartus.
DPA
Data Processing Agreement - datu apstrādes līgums (GDPR 28. pants).
SLA
Service Level Agreement - pakalpojuma līmeņa vienošanās - pieejamība, reakcijas laiks.
MSP
Managed Service Provider - uzņēmums, kas pārvalda klienta IT.
DORA
Digital Operational Resilience Act - ES finanšu nozares digitālās noturības regula.
CRA
Cyber Resilience Act - ES regula par produktu ar digitāliem elementiem drošību.
IKT / ICT
Informācijas un komunikācijas tehnoloģijas
BCP / DR
Business Continuity Plan / Disaster Recovery - darbības nepārtrauktības plāns / atkopšana pēc avārijas.
EO 14028
Executive Order 14028 - ASV prezidenta rīkojums par kiberdrošību (2021), prasa SBOM.
OpenSSF
Open Source Security Foundation - organizācija, kas uztur SLSA un Scorecard.
CI/CD
Continuous Integration / Continuous Delivery - automātiska koda būvēšana, testēšana un piegāde.