Pogodbe z dobavitelji po NIS2 z dokazili po ISO 27001

Ponedeljek je, 07:40. Vodja informacijske varnosti (CISO) logistične platforme, ki uporablja storitve v oblaku, odpre e-pošto dobavitelja storitev upravljanega zaznavanja in odzivanja. Sporočilo je kratko, previdno in neprijetno: dobavitelj je zaznal sumljiv dostop do podpornega okolja, ki ga uporablja več strank. Podrobnosti so omejene. Dobavitelj obljublja posodobitev »takoj, ko bo izvedljivo«.

Ob 08:15 vodja skladnosti že sprašuje, ali bi to lahko sprožilo poročanje po NIS2. Ob 08:40 nabava išče pogodbo. Ob 09:10 želi sekretar organa upravljanja kratko poročilo o odgovornosti vodstva. Ob 10:00 pravna služba preverja, ali pogodba vključuje 24-urno obveščanje, pravice do revizije, kontrole podizvajalcev, dostop do dokazil, obveznosti glede neprekinjenega poslovanja, vračilo podatkov in določbe o izbrisu.

Nihče ne želi med aktivnim incidentom ugotoviti, da pogodba s kritičnim dobaviteljem vsebuje samo formulacijo »razumni varnostni ukrepi«.

Tu pogodbene klavzule z dobavitelji po NIS2 prenehajo biti pravna predloga in postanejo operativne kontrole. Za bistvene in pomembne subjekte je upravljanje dobaviteljev zdaj del odgovornosti organa upravljanja, dokazil za nadzorni organ, pripravljenosti na incidente, zagotovil naročnikom, skladnosti na področju zasebnosti in načrtovanja odpornosti. Podpisana pogodba ni dovolj. Organizacija mora dokazati, da so tveganja dobaviteljev identificirana, odobrena, obravnavana, spremljana in podprta z dokazili.

Pristop Clarysec izhaja iz preprostega načela: če klavzule dobavitelja ni mogoče spremljati, dokazati in testirati, ne gre za kontrolo.

Zenith Blueprint: 30-koračni časovni načrt za presojevalce umešča odnose z dobavitelji v fazo Kontrole v praksi, korak 23, kjer se dogovori, spremljanje, uvajanje, ponovna ocena in revizijska dokazila prevedejo v praktično delo ISMS. Zenith Controls: vodnik za medokvirno skladnost nato preslika kontrole za dobavitelje iz ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST, COBIT 2019, podporne standarde ISO in revizijske metodologije.

Rezultat je model upravljanja dobaviteljev, ki ga lahko uporabljajo nabava, pravna služba, informacijska varnost, zasebnost in organ upravljanja.

Zakaj NIS2 pogodbe z dobavitelji spremeni v evidence dokazil

NIS2 Article 20 zahteva, da organi upravljanja bistvenih in pomembnih subjektov odobrijo ukrepe za upravljanje tveganj kibernetske varnosti, nadzirajo njihovo izvajanje in odgovarjajo za kršitve. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo in vzdrževanjem, oceno učinkovitosti, kibernetsko higieno, kriptografijo, varnostjo kadrovskih procesov, nadzorom dostopa, upravljanjem sredstev in MFA, kadar je to ustrezno.

Article 21(3) izrecno določa skrbni pregled dobaviteljev. Organizacije morajo upoštevati ranljivosti, značilne za neposredne dobavitelje in izvajalce storitev, splošno kakovost proizvodov in praks kibernetske varnosti ter postopke varnega razvoja.

Takšna formulacija ustvarja praktično obveznost: odnosi z dobavitelji morajo temeljiti na tveganjih, biti pogodbeno izvršljivi in pregledljivi. Vprašalnik dobavitelja, shranjen v mapi, ni dovolj. Splošna pogodba brez časovnice za incidente, brez pravic do dokazil in brez vpogleda v podizvajalce ni dovolj. Certifikat dobavitelja, ki ga nihče ni pregledal, ni dovolj.

ISO/IEC 27001:2022 zagotavlja operativni model. Točke 4.1 do 4.4 zahtevajo, da organizacija razume kontekst, zainteresirane strani, zakonske in pogodbene obveznosti, obseg ISMS in odvisnosti. Točke 5.1 do 5.3 zahtevajo voditeljstvo, politiko, vloge in poročanje. Točke 6.1.1 do 6.1.3 zahtevajo oceno tveganja, obravnavo tveganja in Izjavo o uporabljivosti. Točke 8.1 do 8.3 zahtevajo operativni nadzor, ponavljajoče se ocene tveganj in dokumentirane rezultate.

Za upravljanje dobaviteljev so najpomembnejše kontrole iz Priloge A ISO/IEC 27002:2022:

• A.5.19 Informacijska varnost v odnosih z dobavitelji
• A.5.20 Obravnava informacijske varnosti v pogodbah z dobavitelji
• A.5.21 Upravljanje informacijske varnosti v dobavni verigi IKT
• A.5.22 Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev
• A.5.24 Načrtovanje in priprava upravljanja incidentov
• A.5.25 Ocena dogodkov informacijske varnosti in odločanje o njih
• A.5.26 Odziv na incidente informacijske varnosti
• A.5.27 Učenje iz incidentov informacijske varnosti
• A.5.28 Zbiranje dokazov
• A.5.29 Informacijska varnost med motnjami
• A.5.30 Pripravljenost IKT za neprekinjeno poslovanje
• A.5.31 Zakonske, statutarne, regulativne in pogodbene zahteve
• A.5.34 Zasebnost in varstvo PII
• A.8.8 Upravljanje tehničnih ranljivosti
• A.8.13 Varnostno kopiranje informacij
• A.8.15 Beleženje
• A.8.16 Dejavnosti spremljanja
• A.8.24 Uporaba kriptografije
• A.8.32 Upravljanje sprememb

Ključno je lastništvo. Klavzula ima majhno vrednost, če nihče ni lastnik tveganja, nihče ne pregleduje dokazil, nihče ne spremlja izjem in nihče ne eskalira neskladnosti.

Enterprise Politika varnosti tretjih oseb in dobaviteljev to izrecno določa:

»Pravice do revizije, pregleda in zahteve za varnostna dokazila«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.4.

Za mala in srednja podjetja Politika varnosti tretjih oseb in dobaviteljev za MSP določa enako praktično pričakovanje:

»Pravice do revizije ali razpoložljivost dokazil o skladnosti«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.4.

Ta razlika je pomembna. Manjša organizacija morda ne more izvesti revizije na lokaciji pri vsakem večjem ponudniku storitev v oblaku, lahko pa zahteva dostop do dokazil o zagotovilih, kot so obseg certifikacije ISO/IEC 27001:2022, poročila SOC, povzetki penetracijskih testov, potrditve odprave ranljivosti, povzetki incidentov, poročila o testih neprekinjenega poslovanja in potrditve izbrisa podatkov.

Hrbtenica treh kontrol za zagotovila pri dobaviteljih po NIS2

V Clarysecovem modelu medokvirne skladnosti tri kontrole ISO/IEC 27002:2022 tvorijo hrbtenico upravljanja dobaviteljev po NIS2: 5.19, 5.20 in 5.22.

A.5.19 identificira tveganje dobavitelja

Kontrola A.5.19, Informacijska varnost v odnosih z dobavitelji, je temelj. Od organizacij zahteva, da varujejo informacije in sredstva, do katerih dobavitelji dostopajo ali jih obdelujejo, hranijo oziroma upravljajo.

Zenith Controls to uvršča med preventivne kontrolne ukrepe, ki pokrivajo zaupnost, celovitost in razpoložljivost, s konceptom kibernetske varnosti »Identificiraj« in operativno zmožnostjo »Varnost odnosov z dobavitelji«. A.5.19 povezuje z A.5.20, A.5.21, A.5.14, A.5.36 in A.5.10. V praksi organizacija identificira tveganje dobavitelja, opredeli varnostna pričakovanja, nadzira izpostavljenost dobavne verige IKT, varuje prenos informacij, spremlja skladnost in razširi obveznosti sprejemljive uporabe na zunanje strani.

Za NIS2 se to neposredno preslika na varnost dobavne verige iz Article 21(2)(d) in skrbni pregled dobaviteljev iz Article 21(3). Za GDPR podpira zahtevo po uporabi obdelovalcev, ki zagotavljajo zadostna jamstva. Za DORA podpira upravljanje tveganj tretjih ponudnikov storitev IKT, predpogodbeni skrbni pregled, pregled kritičnosti, tveganje koncentracije in nadzor življenjskega cikla.

A.5.20 zahtevo naredi izvršljivo

Kontrola A.5.20, Obravnava informacijske varnosti v pogodbah z dobavitelji, varnostna pričakovanja pretvori v pogodbene obveznosti. Zenith Controls jasno pojasni razmerje med A.5.19 in A.5.20:

»5.20 služi kot pogodbena formalizacija varnostnih potreb in tveganj, identificiranih v okviru 5.19. Medtem ko 5.19 vključuje ocenjevanje tveganj tretjih oseb in opredelitev varnostnih pričakovanj, 5.20 zagotavlja, da so ta pričakovanja pravno zavezujoča s pogodbami ali sporazumi o ravni storitev. Brez 5.20 varnostni ukrepi, identificirani v 5.19, ne bi bili izvršljivi.«

Tu odločitve o tveganjih po NIS2 postanejo klavzule: obveščanje o kršitvah, pravice do revizije in dokazil, šifriranje, nadzor dostopa, upravljanje ranljivosti, odobritev podizvajalcev, varen prenos, neprekinjenost, regulativno sodelovanje, podpora pri izstopu in izbris podatkov.

A.5.22 dokazuje, da pogodba živi

Kontrola A.5.22, Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev, preprečuje, da bi zagotovila pri dobaviteljih ostala enkratna vaja ob uvajanju. Zenith Controls A.5.22 povezuje z A.5.19 in A.5.20, pa tudi z A.5.29 informacijsko varnostjo med motnjami, A.8.8 upravljanjem tehničnih ranljivosti, A.5.36 skladnostjo s politikami, pravili in standardi informacijske varnosti, A.5.15 nadzorom dostopa ter A.8.27 varno arhitekturo sistemov in inženirskimi načeli.

To je pomembno, ker se storitve dobaviteljev spreminjajo. Lokacije podatkov se spreminjajo. Podobdelovalci se spreminjajo. Ranljivosti se pojavijo. Certifikati potečejo. Vzorci incidentov se pokažejo. Dobavitelj, ki je bil lani sprejemljiv, je lahko danes preveč tvegan.

Kaj morajo vključevati pogodbene klavzule z dobavitelji po NIS2

Zenith Blueprint, faza Kontrole v praksi, korak 23, podaja praktičen nabor področij dogovorov z dobavitelji:

»Ključna področja, ki se običajno obravnavajo v pogodbah z dobavitelji, vključujejo:

✓ obveznosti glede zaupnosti, vključno z obsegom, trajanjem in omejitvami razkritja tretjim osebam; ✓ odgovornosti za nadzor dostopa, na primer kdo lahko dostopa do vaših podatkov, kako se upravljajo poverilnice in kakšno spremljanje je vzpostavljeno; ✓ tehnične in organizacijske ukrepe za varstvo podatkov, šifriranje, varen prenos, varnostno kopiranje in zaveze glede razpoložljivosti; ✓ roke in protokole za poročanje o incidentih, pogosto z določenimi roki (npr. »obvestilo v 24 urah«); ✓ pravico do revizije, vključno s pogostostjo, obsegom in dostopom do relevantnih dokazil (npr. poročila o penetracijskem testiranju, SoA, certifikati); ✓ kontrole podizvajalcev, ki od dobavitelja zahtevajo prenos enakovrednih varnostnih obveznosti na njegove nadaljnje partnerje; ✓ določbe ob koncu pogodbe, kot so vračilo ali uničenje podatkov, vračilo sredstev in deaktivacija računov.«

Iz faze Kontrole v praksi, korak 23: Organizacijski ukrepi.

Močna klavzula dobavitelja po NIS2 je dovolj konkretna, da jo je mogoče testirati. »Dobavitelj mora vzdrževati ustrezno varnost« je šibko. »Dobavitelj mora varnostni kontakt naročnika obvestiti v 24 urah od potrjenih ali domnevnih incidentov, ki vplivajo na sisteme naročnika, podatke naročnika, razpoložljivost storitve ali regulativne obveznosti poročanja« je primerno za revizijo.

Klavzule o incidentih morajo ustrezati časovnici poročanja po NIS2

NIS2 Article 23 uvaja model postopnega poročanja za pomembne incidente: zgodnje opozorilo v 24 urah od seznanitve, obvestilo o incidentu v 72 urah, vmesna poročila na zahtevo in končno poročilo v enem mesecu od obvestila o incidentu. Pomemben incident je incident, ki je povzročil ali lahko povzroči resno operativno motnjo, finančno izgubo ali znatno materialno oziroma nematerialno škodo drugim.

Pogodbe z dobavitelji morajo podpirati to časovnico. Če kritični ponudnik upravljanih storitev potrebuje štiri dni, da potrdi, ali so bila prizadeta okolja naročnika, lahko naročnik zamudi svoj regulativni rok.

Enterprise Politika varnosti tretjih oseb in dobaviteljev zahteva:

»Roke za obveščanje o kršitvah (npr. v 24 ali 72 urah, odvisno od kritičnosti in regulativnih zahtev)«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.3.

SME Politika varnosti tretjih oseb in dobaviteljev za MSP prav tako zahteva opredeljene roke za obveščanje o kršitvah iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.3.

Za incidente v zvezi s PII Enterprise Politika upravljanja incidentov in kršitev v zvezi s PII povezuje kibernetsko varnost, finančni sektor, naročnike in poročanje prejemnikom storitev:

»[Pogojno] Vodja zasebnosti / vodja PIMS MORA usklajevati vsako zahtevano sektorsko poročanje, poročanje o kibernetski varnosti, poročanje v finančnem sektorju, poročanje naročnikom ali prejemnikom storitev o incidentu, kadar incident v zvezi z osebno določljivimi podatki z velikim vplivom doseže veljaven prag poročanja, ter MORA v REG01 in REG10 zabeležiti dokazila o organu, prejemniku, časovnici, oddaji in potrditvi prejema.«

Iz razdelka »Obveščanje in komunikacije«, klavzula politike 4.4.6.

To so zrela dokazila po NIS2: ne le e-poštno obvestilo, temveč zapis o organu, prejemniku, časovnici, oddaji, potrditvi prejema, vplivu, temeljnem vzroku in nadaljnjih ukrepih.

Uskladitev zasebnosti in DORA brez podvajanja programov za dobavitelje

Številni dobavitelji po NIS2 obdelujejo tudi osebne podatke. GDPR Article 28 zahteva, da upravljavci uporabljajo obdelovalce, ki zagotavljajo zadostna jamstva, in da obveznosti obdelovalca opredelijo v pisni pogodbi. GDPR Article 5 zahteva odgovornost za varno in zakonito obdelavo. Obveznosti GDPR glede kršitev zahtevajo tudi hitro sodelovanje, kadar incidenti pri dobavitelju vplivajo na osebne podatke.

Enterprise Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti določa kontrolno točko odobritve:

»[Oba] Lastnik dobavitelja / nabave MORA pred odobritvijo zagotoviti, da pogodbe z obdelovalci in podobdelovalci vključujejo pomoč na področju zasebnosti, varnostna zagotovila, stično točko za obravnavo incidentov prek PII15, vračilo ali izbris prek PII10, povezavo s prenosi prek PII13 ter sodelovanje pri reviziji ali zagotavljanju zagotovil.«

Iz razdelka »Kontrole pogodb in dokumentiranih navodil«, klavzula politike 4.3.6.

Zahteva tudi pregled dokazil pred odobritvijo:

»[Vsi] Vodja informacijske varnosti MORA pred odobritvijo pregledati dokazila za varnostna zagotovila za vsako razmerje z obdelovalcem, podobdelovalcem ali tretjo osebo z dostopom do PII ali gostovanjem PII ter rezultat zabeležiti v REG08 ali REG12.«

Iz razdelka »Skrbni pregled in ocena tveganja«, klavzula politike 4.2.2.

DORA doda dodatno plast, kadar dobavitelj opravlja storitve za finančni subjekt. DORA Articles 28 to 30 zahtevajo upravljanje tretjih ponudnikov storitev IKT, registre pogodb o storitvah IKT, skrbni pregled na podlagi tveganj, presojo kritičnosti, analizo tveganja koncentracije, pravice do revizije in pregleda, pravice do odpovedi, izstopne strategije in obvezne pogodbene določbe. Article 30 je posebej pomemben, ker zahteva pogodbeno vsebino, ki zajema opise storitev, lokacije, varstvo podatkov, dostop in obnovitev, ravni storitev, pomoč pri incidentih, sodelovanje z organi, pravice do revizije, podizvajanje, ukrepe ob nepredvidenih dogodkih in podporo pri prehodu.

Praktičen odgovor niso trije ločeni programi za dobavitelje za NIS2, GDPR in DORA. Praktičen odgovor je en usklajen model dokazil dobaviteljev, preslikan čez več okvirov.

NIST CSF 2.0 je uporaben, ker njegova funkcija GOVERN zahteva razumevanje odvisnosti, zakonskih obveznosti, pogodbenih obveznosti, apetita po tveganju, politik, odgovornosti in nadzora. Njegova kategorija dobavne verige GV.SC zajema vloge dobaviteljev, kritičnost, pogodbene zahteve, skrbni pregled, spremljanje, vključitev v incidente, spremljanje življenjskega cikla in določbe ob zaključku razmerja.

Delovni tok Clarysec za uvajanje kritičnega dobavitelja

Predpostavimo, da uvajate ponudnika upravljanih varnostnih storitev, ki bo spremljal telemetrijo končnih točk, prejemal opozorila z uporabniškimi identifikatorji in podpiral triažo incidentov za organizacijo v obsegu NIS2.

1. korak: razvrstite dobavitelja

Dobavitelja zabeležite v evidenci dobaviteljev z opisom storitve, sistemi in podatki, do katerih dostopa, vključenostjo PII, podporo bistvenim ali pomembnim storitvam, privilegiranim dostopom, državami izvajanja storitve, podizvajalci, odvisnostmi od četrtih oseb, oceno kritičnosti, lastnikom tveganja, lastnikom nabave in pregledovalcem informacijske varnosti.

S tem se izvajajo točke ISO/IEC 27001:2022 4.2, 4.3, 6.1.2 in 8.1, saj povezujejo zahteve zainteresiranih strani, odvisnosti, lastništvo tveganja in operativni nadzor.

2. korak: preslikajte tveganje v SoA

V Zenith Blueprint, faza Upravljanje tveganj, korak 13, Clarysec priporoča navzkrižno sklicevanje na predpise v registru tveganj ali SoA:

»Navzkrižno sklicevanje na predpise: če so določene kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to zabeležite bodisi v registru tveganj (kot del utemeljitve vpliva tveganja) bodisi v opombah SoA.«

Iz faze Upravljanje tveganj, korak 13: Načrtovanje obravnave tveganja in Izjava o uporabljivosti.

Za MSSP vključite najmanj A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 do A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 in A.8.24.

3. korak: zahtevajte izvršljive klavzule

Uporabite varnostno prilogo za dobavitelje, ki zahteva začetno obvestilo o incidentu v 24 urah, podrobno posodobitev v 72 urah, končno poročilo o incidentu, MFA za privilegirani dostop, imenovane uporabniške račune, kontrole podizvajalcev, varen prenos, šifriranje, dokazila o zagotovilih, regulativno sodelovanje, dokazila BCP in DR, podporo pri izstopu, vračilo ali izbris podatkov ter preklic dostopa.

Enterprise Politika upravljanja tveganj odvisnosti od dobaviteljev zagotavlja zahtevo glede neprekinjenosti:

»Kadar je ustrezno, zahteva, da dobavitelj vzdržuje lastne načrte neprekinjenega poslovanja (BCP/DRP) in načrte upravljanja incidentov, jih testira ter nam na zahtevo predloži povzetke ali poročila o testih.«

Iz razdelka »Zahteve za izvajanje«, klavzula politike 6.8.4.

4. korak: pripravite paket dokazil o zagotovilih

Pred odobritvijo zahtevajte podpisano pogodbo, SLA, varnostno prilogo, obseg certifikacije ISO/IEC 27001:2022 ali enakovredno zagotovilo, poročilo SOC, kjer je na voljo, izvršni povzetek penetracijskega testa, povzetek upravljanja ranljivosti, povzetek postopka odzivanja na incidente, povzetek testa BCP ali DR, potrditev nadzora dostopa in MFA, seznam podizvajalcev, postopek izbrisa podatkov in izstopa ter DPA, kadar se obdelujejo PII.

SME Politika varnosti tretjih oseb in dobaviteljev za MSP osnovna pogodbena dokazila opredeli merljivo:

»Podpisane pogodbe in SLA«

Iz razdelka »Uveljavljanje in skladnost«, klavzula politike 8.3.2.1.

Opredeli tudi ponavljajoča se dokazila dobaviteljev:

»Veljavni certifikati informacijske varnosti ali posodobljena dokazila o kontrolah«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.1.2.

Za širši skrbni pregled dobaviteljev Politika spremljanja presoje in skladnosti določa:

»Skrbni pregled dobavitelja mora vključevati pregled certifikatov (npr. ISO 27001, SOC 2), varnostnih vprašalnikov in zapisov incidentov.«

5. korak: spremljajte glede na kritičnost

Enterprise Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti zahteva četrtletno spremljanje za razmerja z visokim tveganjem v zvezi s PII:

»[Vsi] Lastnik dobavitelja / nabave MORA četrtletno spremljati aktivna razmerja z obdelovalci in podobdelovalci z visokim tveganjem ter letno druga aktivna razmerja z obdelovalci in podobdelovalci PII glede na pogoje skrbnega pregleda, status pogodbe, status zagotovil, odprta vprašanja in datume pregledov v REG08.«

Iz razdelka »Stalno spremljanje, pomoč, vmesnik za razkritja in izstop«, klavzula politike 4.5.1.

Tako A.5.22 postane dejanska praksa. Pregled mora ugotoviti, ali dobavitelj ostaja v okviru apetita po tveganju, ali so dokazila aktualna, ali obstajajo odprta vprašanja, ali so se zgodili incidenti in ali spremembe storitve zahtevajo ponovno oceno.

Kako bodo presojevalci testirali klavzule z dobavitelji po NIS2

Presojevalci redko začnejo z branjem politike v izolaciji. Vzorčijo dobavitelje in sledijo revizijski sledi dokazil.

Presojevalec ISO/IEC 27001:2022 bo zahteval popis dobaviteljev, razvrstitev tveganj, merila za dobavitelje, zapise skrbnega pregleda, pogodbe, dokazila, preslikavo SoA in zgodovino spremljanja. Za Prilogo A 5.20 bo presojevalec preveril, ali vzorčene pogodbe vsebujejo izvršljive klavzule. Za Prilogo A 5.22 bo testiral, ali so bila poročila pregledana, izjeme evidentirane in ukrepi spremljani do zaključka.

Pristojni organ po NIS2 se lahko osredotoči na to, ali so bile prakse kibernetske varnosti dobavitelja in postopki varnega razvoja ocenjeni v skladu z Article 21(3). Pregledovalec, usmerjen v DORA, lahko zahteva vnose v registru pogodb IKT, izstopne strategije, analizo tveganja koncentracije in obvezne določbe Article 30. Presojevalec zasebnosti lahko testira pogodbe z obdelovalci, prenos obveznosti na podobdelovalce, stične točke za kršitve in dokazila o zadostnih jamstvih.

Enterprise Politika varnosti PII in nadzora dostopa kaže, kako se nadzor dostopa, ranljivosti, konfiguracija, spremljanje in kriptografija povezujejo nazaj z ISO/IEC 27001:2022:

»ISO/IEC 27001:2022 — točka 6.1.3; točka 8.1; kontrole Priloge A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Obravnavano s klavzulami [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].«

Iz razdelka »Referenčni standardi in okviri«, klavzula politike 13.9.

Kadar ima dobavitelj dostop do PII, privilegiranih sistemov ali podatkov spremljanja, dokazila o nadzoru dostopa niso ločena od zagotovil pri dobaviteljih. So del iste revizijske sledi.

Past nabave: podpisane pogodbe brez operativnih zagotovil

Najpogostejša napaka pri upravljanju dobaviteljev po NIS2 ni odsotnost pogodb. Gre za vrzel med pogodbenim besedilom in vsakodnevnim izvajanjem.

Pogodba lahko zahteva letne povzetke penetracijskih testov, vendar jih noben lastnik ne zahteva. Lahko zahteva 24-urno obveščanje o incidentih, vendar ima dobavitelj samo splošni naslov službe za pomoč uporabnikom. Lahko zahteva odobritev podizvajalcev, vendar nabava nikoli ne prejme obvestil o spremembah. Lahko vključuje pravice do revizije, vendar organizacija nima postopka za ocenjevanje izjem iz poročil SOC. Lahko zahteva izbris podatkov ob izstopu, vendar IT nikoli ne potrdi deaktivacije računov.

Zenith Blueprint, faza Kontrole v praksi, korak 23, pojasni, kako kontrole dobaviteljev zaživijo:

»V praksi ta kontrola zaživi prek:

✓ ocen tveganj dobaviteljev, ✓ vprašalnikov za skrbni pregled pred začetkom sodelovanja, ✓ pogodbenih predlog z vgrajenimi varnostnimi pogoji, ✓ kontrolnih seznamov za uvajanje dobaviteljev, ki vključujejo dodeljevanje dostopa in vzpostavitev spremljanja, ✓ stalnih ponovnih ocen, zlasti kadar se spremeni obseg dobavitelja, pride do incidentov ali nastopi čas podaljšanja.

Ta kontrola se ne konča pri dobaviteljih prve ravni. Vaš dobavitelj lahko storitve odda svojim ponudnikom in tveganje lahko še vedno nosite vi.«

To je sporočilo NIS2 na ravni organa upravljanja: zunanje izvajanje storitve ne pomeni zunanjega izvajanja odgovornosti.

Kontrolni seznam za odpravo pomanjkljivosti v pogodbah z dobavitelji po NIS2

Začnite z 20 najpomembnejšimi dobavitelji po kritičnosti in izvedite usmerjeno odpravo pomanjkljivosti:

• Identificirajte dobavitelje, ki podpirajo bistvene ali pomembne storitve.
• Potrdite, ali vsak dobavitelj obdeluje PII, podpira regulirane storitve ali ima privilegirani dostop.
• Dodelite poslovnega lastnika, lastnika nabave in varnostnega pregledovalca.
• Preverite, ali je ocena tveganja dobavitelja aktualna in usklajena z dejanskim obsegom storitve.
• Potrdite, da pogodba vključuje osnovne varnostne zahteve, obveščanje o incidentih, pravice do revizije ali dokazil, kontrole podizvajalcev, neprekinjenost, varen prenos, nadzor dostopa, sodelovanje pri ranljivostih in izstopne klavzule.
• Potrdite, da roki za obveščanje o kršitvah podpirajo potrebe po 24-urni in 72-urni eskalaciji, kjer je to relevantno.
• Zahtevajte posodobljena dokazila o zagotovilih, vključno s certifikati, poročili SOC, povzetki penetracijskih testov, testi BCP ali DR in zgodovino incidentov.
• Dokazila preglejte, ne le shranite.
• Evidentirajte izjeme in določite lastnike odprave pomanjkljivosti.
• Posodobite SoA in register tveganj, kjer kontrole dobaviteljev podpirajo NIS2, GDPR, DORA ali zaveze naročnikom.
• Načrtujte pogostost spremljanja glede na kritičnost dobavitelja.
• Testirajte eno eskalacijsko pot za incident pri dobavitelju.
• Testirajte eno pot prenehanja pri dobavitelju, vključno z vračilom podatkov, izbrisom, vračilom sredstev in preklicem dostopa.

Če teh točk za kritičnega dobavitelja ne morete dokazati, pogodba še ni pripravljena na revizijo.

Klavzule dobaviteljev pretvorite v dokazila za nadzorni organ

Upravljanje dobaviteljev po NIS2 je zdaj živa operativna disciplina. Nadzorni organi, naročniki, certifikacijski presojevalci, ekipe za zasebnost, partnerji iz finančnega sektorja in organi upravljanja ne bodo vprašali samo, ali klavzule dobaviteljev obstajajo. Vprašali bodo, ali temeljijo na tveganjih, ali so izvršljive, spremljane, podprte z dokazili in povezane s poročanjem o incidentih, neprekinjenostjo, nadzorom dostopa, upravljanjem ranljivosti, prenosom obveznosti na podizvajalce in izstopom.

Clarysec organizacijam pomaga zapreti to vrzel z Zenith Blueprint, ki kontrole dobaviteljev pretvori v faze ISMS, obravnavo tveganj, vnose v SoA, rutine uvajanja in revizijska dokazila. Zenith Controls preslika kontrole za dobavitelje iz ISO/IEC 27002:2022 A.5.19, A.5.20 in A.5.22 na NIS2, DORA, GDPR, NIST, COBIT 2019, podporne standarde ISO in revizijske metodologije. Politike Clarysec za dobavitelje in zasebnost zagotavljajo strukturo klavzul, pričakovanja glede dokazil in rutine spremljanja, zaradi katerih so zagotovila pri dobaviteljih zagovorljiva.

Vaš naslednji korak je preprost: izberite pet kritičnih dobaviteljev, vzorčite njihove pogodbe, preslikajte vsako klavzulo na obravnavo tveganja po ISO/IEC 27001:2022 in kontrole Priloge A, zahtevajte sveža dokazila o zagotovilih ter izvedite namizno vajo 24-urnega obveščanja o incidentu. Če se revizijska sled dokazil prekine, vam orodja Clarysec dajo strukturo, da jo popravite, preden to namesto vas sproži incident, pregled naročnika ali zahteva nadzornega organa.