⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

Šibki člen: priročnik za vodjo informacijske varnosti za vzpostavitev programa obvladovanja tveganj dobavne verige, skladnega z NIS2

Igor Petreski
21 min read
Diagram poteka, ki prikazuje 15-koračni priročnik za vodjo informacijske varnosti za vzpostavitev programa obvladovanja tveganj dobavne verige, skladnega z NIS2, ter zajema celoten življenjski cikel dobavitelja: od opredelitve politik in razvrščanja po tveganjih do stalnega spremljanja, obravnave incidentov in končne priprave na večregulativno revizijo.

Opozorilo je bilo na prvi pogled nepomembno, manjše odstopanje iz storitve spremljanja tretje osebe. Za Anyo, vodjo informacijske varnosti v srednje velikem logističnem podjetju, je bilo to že tretje takšno obvestilo istega dobavitelja v enem mesecu: »Zaznana anomalija pri prijavi.« Dobavitelj, majhen, vendar kritičen ponudnik programske opreme za upravljanje voznega parka, jo je prepričeval, da ne gre za nič posebnega. Lažno pozitiven rezultat. Toda Anya je vedela, da je težava resnejša. To niso bile zgolj tehnične napake; bili so opozorilni tresljaji, ki so kazali na globljo nestabilnost v kritičnem delu njene dobavne verige. Ker je bilo njeno podjetje po Direktivi NIS2 zdaj razvrščeno kot »pomemben subjekt«, so se ti tresljaji zdeli kot predhodniki potresa.

Stari način upravljanja dobaviteljev, ki je temeljil na rokovanju in ohlapno zapisani pogodbi, je dokončno preteklost. NIS2 jasno pokaže, da je varnostni profil tveganja organizacije močan le toliko kot njen najšibkejši člen. Šibki člen ni več »nekje zunaj« — je znotraj vaše dobavne verige. V okviru NIS2 neuspešno upravljanje tveganj dobaviteljev ni zgolj tehnična pomanjkljivost. Je regulativno tveganje na ravni upravnega odbora z operativnimi, uglednimi in finančnimi posledicami. Anyin problem ni bil le en nezanesljiv dobavitelj. Šlo je za sistemsko ranljivost, vgrajeno v njeno poslovanje, in presojevalci bi jo iskali. Potrebovala je več kot hitro odpravo; potrebovala je priročnik.

Ta vodnik zagotavlja prav ta priročnik. Predstavili bomo strukturiran pristop, s katerim lahko vodje informacijske varnosti, vodje skladnosti in revizorji vzpostavijo zagovorljiv, medregulativni program obvladovanja tveganj dobavne verige. Z uporabo robustnega okvira, kot je ISO/IEC 27001:2022, in strokovnih orodij Clarysec lahko nujna tveganja dobavne verige povežete z izvedljivimi metodami za izpolnjevanje zahtev NIS2, DORA, GDPR in drugih okvirov.

Mandat tveganja: kako NIS2 na novo opredeljuje varnost dobavne verige

Direktiva NIS2 varnost dobavne verige iz zgolj dobre prakse spreminja v pravno zavezujočo obveznost. Zahteva stalen, na tveganjih temelječ pristop k varovanju dobavnih verig IKT in OT, razširja področje uporabe na številne sektorje ter neposredno vzpostavlja odgovornost vodstva za neuspehe pri skladnosti. To pomeni:

  • Razširjen obseg: Vsak dobavitelj, podobdelovalec, ponudnik storitev v oblaku in zunanji izvajalec, ki posega v vaše okolje IKT, je v obsegu.
  • Nenehno izboljševanje: NIS2 zahteva živ proces ocenjevanja tveganj, spremljanja in prilagajanja, ne enkratnega pregleda. Ta proces morajo sprožati tako notranji dogodki (incidenti, kršitve) kot zunanje spremembe (nova zakonodaja, spremembe storitev dobaviteljev).
  • Obvezne kontrole: Odziv na incidente, obravnava ranljivosti, redno varnostno testiranje in robustno šifriranje so zdaj zahtevani po celotni dobavni verigi, ne le znotraj lastnega varnostnega oboda.

S tem se brišejo meje med notranjo varnostjo in tveganji tretjih oseb. Kibernetska odpoved vašega dobavitelja postane vaša regulativna kriza. Strukturiran okvir, kot je ISO/IEC 27001:2022, postane nepogrešljiv, saj zagotavlja kontrole in procese, potrebne za vzpostavitev odpornega in preverljivega programa, ki izpolnjuje zahteve NIS2. Pot se ne začne s tehnologijo, temveč s strategijo, osredotočeno na tri ključne kontrole:

  • 5.19 - Informacijska varnost v odnosih z dobavitelji: vzpostavitev strateškega okvira za upravljanje tveganj dobaviteljev.
  • 5.20 - Obravnava informacijske varnosti v dogovorih z dobavitelji: zapis varnostnih pričakovanj v pravno zavezujoče pogodbe.
  • 5.22 - Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev: zagotavljanje stalnega nadzora in prilagajanja skozi celoten življenjski cikel dobavitelja.

Obvladovanje teh treh področij dobavno verigo iz vira negotovosti spremeni v dobro upravljano, skladno in odporno sredstvo.

Korak 1: vzpostavitev upravljavskih temeljev s kontrolo 5.19

Anyino prvo spoznanje je bilo, da vseh dobaviteljev ne more obravnavati enako. Dobavitelj pisarniškega materiala ni bil enak ponudniku njene kritične programske opreme za upravljanje voznega parka. Prvi korak pri vzpostavitvi programa, skladnega z NIS2, je razumeti in razvrstiti ekosistem dobaviteljev glede na tveganje.

Kontrola 5.19, Informacijska varnost v odnosih z dobavitelji, je strateški temelj. Prisili vas, da presežete preprost seznam dobaviteljev in vzpostavite večstopenjski sistem upravljanja. Ta proces mora temeljiti na jasni politiki, ki jo potrdi upravni odbor. Clarysecova Politika varnosti tretjih oseb in dobaviteljev to dejavnost neposredno povezuje s širšim okvirom organizacije za obvladovanje tveganj:

»P6 – Politika upravljanja tveganj. Usmerja identifikacijo, oceno in zmanjševanje tveganj, povezanih z odnosi s tretjimi osebami, vključno s podedovanimi ali sistemskimi tveganji iz ekosistemov dobaviteljev.« Iz razdelka »Povezane politike in povezave«, klavzula politike 10.2.

Ta integracija zagotavlja, da se tveganja iz odvisnosti nižje v dobavni verigi oziroma izpostavljenosti »četrtim osebam« upravljajo kot del vašega lastnega ISMS. Sam postopek razvrščanja mora biti metodičen. V koraku 23 faze »Revizija in izboljšave« Zenith Blueprint: 30-koračni časovni načrt za revizorje usmerja organizacije, naj dobavitelje razvrstijo na podlagi ključnih vprašanj:

  • Ali dobavitelj ravna z vašimi občutljivimi ali reguliranimi informacijami oziroma jih obdeluje?
  • Ali zagotavlja infrastrukturo ali platforme, od katerih so odvisne vaše kritične operacije?
  • Ali v vašem imenu upravlja ali vzdržuje sisteme?
  • Ali bi njegova kompromitacija lahko neposredno vplivala na vaše cilje glede zaupnosti, celovitosti ali razpoložljivosti?

Anya je s to logiko ponovno ocenila ponudnika programske opreme za upravljanje voznega parka. Obdeloval je lokacijske podatke v realnem času (občutljivo), njegova platforma je bila bistvena za vsakodnevno poslovanje (kritična infrastruktura), kompromitacija pa bi lahko ustavila dostave (velik vpliv na razpoložljivost). Takoj je bil prerazvrščen iz »standardnega dobavitelja« v »kritičnega dobavitelja z visokim tveganjem«.

Takšno razvrščanje na podlagi tveganja določa raven skrbnega pregleda, pogodbenih zahtev in stalnega spremljanja. Kot pojasnjuje naš Zenith Controls: vodnik za medokvirno skladnost, je ta pristop neposredno usklajen s pričakovanji ključnih predpisov.

PredpisZahtevaKako kontrola 5.19 to naslavlja
NIS2Article 21(2)(d) zavezuje k obvladovanju tveganj dobavne verige.Zagotavlja okvir za identifikacijo in razvrščanje tveganj dobaviteljev.
DORAArticles 28-30 zahtevajo razvrstitev kritičnih dobaviteljev IT in finančnih storitev.Vzpostavlja proces razvrščanja ponudnikov IKT glede na kritičnost.
GDPRArticle 28 zahteva, da upravljavci uporabljajo le obdelovalce, ki zagotavljajo ustrezna jamstva.Vzpostavlja podlago za skrbni pregled, potreben za oceno jamstev.

Ta temeljni korak ni le interna vaja; je podlaga, na kateri je zgrajen celoten zagovorljiv program varnosti dobavne verige.

Korak 2: oblikovanje trdnih dogovorov s kontrolo 5.20

Ko je Anya identificirala dobavitelja z visokim tveganjem, je odprla njihovo pogodbo. Šlo je za standardno nabavno predlogo z nejasno klavzulo o zaupnosti in skoraj ničemer drugim, povezanim s kibernetsko varnostjo. Pogodba ni vsebovala posebnih varnostnih kontrol, roka za obveščanje o kršitvah ali pravice do revizije. Z vidika presojevalca NIS2 je bila brez vrednosti.

Tu postane ključna kontrola 5.20, Obravnava informacijske varnosti v dogovorih z dobavitelji. Gre za mehanizem, ki tveganja, identificirana v 5.19, prevede v izvršljive, pravno zavezujoče obveznosti. Pogodba ni le komercialni dokument; je primarna varnostna kontrola.

Vaše politike morajo voditi to preobrazbo. Politika varnosti tretjih oseb in dobaviteljev to določa kot ključni cilj:

»Uskladiti varnostne kontrole tretjih oseb z veljavnimi regulativnimi in pogodbenimi obveznostmi, vključno s standardi GDPR, NIS2, DORA in ISO/IEC 27001.« Iz razdelka »Cilji«, klavzula politike 3.6.

Ta klavzula politiko iz smernice spremeni v neposreden mandat za nabavno in pravno ekipo. Za Anyo je to pomenilo vrnitev k dobavitelju in ponovna pogajanja. Novi pogodbeni dodatek je vključeval konkretne, nepogajljive klavzule:

  • Obvestilo o kršitvi: Dobavitelj mora vsak sum varnostnega incidenta, ki vpliva na podatke ali storitve njenega podjetja, prijaviti v 24 urah, ne »v razumnem roku«.
  • Pravica do revizije: Podjetje si pridržuje pravico, da letno izvede varnostne presoje ali zahteva revizijska poročila tretjih oseb (na primer SOC 2 Type II).
  • Varnostni standardi: Dobavitelj mora upoštevati konkretne varnostne kontrole, kot sta večfaktorska avtentikacija za ves administratorski dostop in redno skeniranje ranljivosti njegove platforme.
  • Upravljanje podobdelovalcev: Dobavitelj mora razkriti in pridobiti predhodno pisno odobritev za vse svoje podizvajalce, ki bodo ravnali s podatki podjetja.
  • Izhodna strategija: Pogodba mora določiti postopke za varno vračilo ali uničenje podatkov ob prenehanju pogodbe, s čimer se zagotovi urejen postopek izstopa.

Kot poudarja Zenith Controls, je ta praksa osrednjega pomena v več okvirih. GDPR v Article 28(3) zahteva podrobne pogodbe o obdelavi osebnih podatkov. DORA v Article 30 predpisuje izčrpen seznam pogodbenih določil za kritične ponudnike IKT. Z uvedbo robustne kontrole 5.20 Anya ni izpolnjevala le ISO/IEC 27001:2022; hkrati je gradila zagovorljiv položaj za presoje NIS2, DORA in GDPR.

Korak 3: stražni stolp — stalno spremljanje s kontrolo 5.22

Anyin začetni problem, ponavljajoča se varnostna opozorila, je izhajal iz klasične napake: »podpiši in pozabi«. Močna pogodba je neuporabna, če se shrani v arhiv in se nanjo nikoli več ne sklicuje. Zadnji del sestavljanke je kontrola 5.22, Spremljanje, pregled in upravljanje sprememb storitev dobaviteljev. To je operativna kontrola, ki zagotavlja, da se obljube iz pogodbe tudi izpolnjujejo.

Ta kontrola upravljanje dobaviteljev iz statične dejavnosti ob uvajanju spremeni v dinamičen, stalen proces. Po Zenith Controls to vključuje več medsebojno povezanih dejavnosti:

  • Pregledi uspešnosti: Redno načrtovani sestanki (npr. četrtletno za dobavitelje z visokim tveganjem) za obravnavo uspešnosti glede na varnostne SLA, pregled poročil o incidentih in načrtovanje prihajajočih sprememb.
  • Pregled revizijskih artefaktov: Proaktivno zahtevanje in analiza revizijskih poročil dobavitelja, certifikatov in rezultatov penetracijskega testiranja. Revizor bo preveril, ali teh poročil ne le zbirate, temveč tudi aktivno spremljate in upravljate vse izjeme, ki jih vsebujejo.
  • Upravljanje sprememb: Ko dobavitelj spremeni svojo storitev — na primer z migracijo k novemu ponudniku storitev v oblaku ali uvedbo novega API — mora to pri vas sprožiti varnostni pregled. S tem preprečite, da bi dobavitelji nevede v vaše okolje vnesli nova tveganja.
  • Stalno spremljanje: Uporaba orodij in virov obveščevalnih podatkov o grožnjah za obveščenost o zunanjem varnostnem profilu tveganja dobavitelja. Nenaden padec varnostne ocene ali novica o kršitvi mora sprožiti takojšen odziv.

Ta stalna zanka spremljanja, pregledovanja in prilagajanja je bistvo »stalnega procesa obvladovanja tveganj«, ki ga zahteva NIS2. Zagotavlja, da se zaupanje nikoli ne predpostavlja; stalno se preverja.

Izvedljiv primer: kontrolni seznam za pregled dobavitelja

Da bi to prenesli v prakso, je Anyina ekipa pripravila kontrolni seznam za nove četrtletne preglede s ponudnikom upravljanja voznega parka, na podlagi revizijskih metodologij iz Zenith Controls.

Področje pregledaDokazila za zbiranje in obravnavoŽeleni rezultat
SLA in uspešnostPoročila o razpoložljivosti, dnevniki incidentov, časi reševanja zahtevkov za podporo.Preveriti skladnost s pogodbenimi zavezami glede razpoložljivosti in podpore.
Varnostni incidentiPodrobno poročilo o vseh varnostnih opozorilih (vključno z »lažno pozitivnimi«), analiza temeljnega vzroka in sanacijski ukrepi.Potrditi transparentno poročanje in učinkovito obravnavanje incidentov.
Skladnost in revizijeNajnovejše poročilo SOC 2 ali povzetek penetracijskega testiranja.Pregledati ugotovitve in spremljati dobaviteljev načrt odprave za vse identificirane ranljivosti.
Upravljanje ranljivostiPoročila o ritmu nameščanja popravkov za kritične sisteme.Zagotoviti, da dobavitelj izpolnjuje obveznost pravočasnega nameščanja popravkov za kritične ranljivosti.
Prihajajoče spremembeRazprava o dobaviteljevem načrtu razvoja produkta, spremembah infrastrukture ali novih podobdelovalcih.Proaktivno oceniti varnostne posledice prihodnjih sprememb, preden so implementirane.

To preprosto orodje je pogovor iz splošnega usklajevalnega sestanka spremenilo v osredotočen, z dokazili podprt sestanek upravljanja varnosti ter ustvarilo preverljivo evidenco stalnega nadzora.

Določitev meje: sprejem tveganja v svetu NIS2

Začetni incident z dobaviteljem je Anyo prisilil, da se sooči s temeljnim vprašanjem: katera raven tveganja je sprejemljiva? Tudi z najboljšimi pogodbami in spremljanjem vedno ostane nekaj preostalega tveganja. Zato so jasna, s strani vodstva odobrena merila za sprejem tveganja nujna.

V koraku 10 faze »Tveganja in implementacija« Zenith Blueprint zagotavlja ključne usmeritve glede te točke. Ni dovolj reči »sprejemamo nizka tveganja«. Opredeliti morate, kaj to pomeni v kontekstu vaših zakonskih in regulativnih obveznosti.

»V merilih za sprejem upoštevajte tudi zakonske/regulativne zahteve. Nekatera tveganja so lahko nesprejemljiva ne glede na verjetnost zaradi zakonodaje … Podobno NIS2 in DORA uvajata določene osnovne varnostne zahteve – njihovo neizpolnjevanje (tudi če je verjetnost incidenta nizka) lahko pomeni nesprejemljivo tveganje skladnosti. Vključite te vidike, npr.: »Vsako tveganje, ki bi lahko povzročilo neskladnost z veljavno zakonodajo (GDPR itd.), ni sprejemljivo in ga je treba zmanjšati.««

To je za Anyo spremenilo pravila igre. S pravno in nabavno ekipo je posodobila politiko upravljanja tveganj. Nova merila so izrecno določila, da vsak kritični dobavitelj, ki ne izpolnjuje osnovnih varnostnih zahtev, predpisanih z NIS2, predstavlja nesprejemljivo tveganje in sproži takojšen načrt obravnave tveganja. S tem je odpravila nejasnost pri odločanju in vzpostavila jasen upravljavski sprožilec. Kot določa Politika varnosti tretjih oseb in dobaviteljev:

»Izjeme z visokim tveganjem (npr. dobavitelji, ki obdelujejo regulirane podatke ali podpirajo kritične sisteme) morajo odobriti vodja informacijske varnosti, pravna služba in vodstvo nabave ter jih je treba vnesti v register izjem ISMS.« Iz razdelka »Obravnava tveganj in izjeme«, klavzula politike 7.3.

Revizor je tu: obvladovanje presoje z več zornih kotov

Šest mesecev pozneje, ko so notranji revizorji prišli izvesti oceno pripravljenosti na NIS2, je bila Anya pripravljena. Vedela je, da bodo njen program dobavne verige presojali z več zornih kotov.

  • Revizor ISO/IEC 27001:2022: Ta revizor se je osredotočil na proces in dokazila. Zahteval je evidenco dobaviteljev, preveril razvrstitev po tveganjih, vzorčil pogodbe glede posebnih varnostnih klavzul in pregledal zapisnike četrtletnih preglednih sestankov. Njen strukturiran pristop, zgrajen na kontrolah 5.19, 5.20 in 5.22, je zagotovil jasno revizijsko sled.

  • Revizor COBIT 2019: Ta revizor je z vidika upravljanja želel videti povezavo s poslovnimi cilji. Vprašal je, kako se tveganje dobaviteljev poroča izvršnemu odboru za tveganja. Anya je predstavila register tveganj, ki je prikazoval, kako je bila določena ocena tveganja dobavitelja in kako je bila preslikana v splošni apetit po tveganju podjetja.

  • Ocenjevalec NIS2: Ta oseba se je osredotočila na sistemsko tveganje za bistvene storitve. Ni ga zanimala le pogodba; želel je vedeti, kaj bi se zgodilo, če bi dobavitelj v celoti prenehal delovati. Anya ga je vodila skozi načrt neprekinjenega poslovanja, ki je zdaj vključeval razdelek o odpovedi kritičnega dobavitelja, pripravljen v skladu z načeli ISO/IEC 22301:2019.

  • Revizor GDPR: Ker je dobavitelj obdeloval lokacijske podatke, se je ta revizor takoj osredotočil na varstvo podatkov. Zahteval je pogodbo o obdelavi osebnih podatkov (DPA) in dokazila o skrbnem pregledu, s katerim je zagotovila, da dobavitelj zagotavlja »zadostna jamstva«, kot zahteva Article 28. Ker je njen proces zasebnost vključeval že od začetka, je bila DPA robustna.

Ta večperspektivni revizijski pogled kaže, da dobro implementiran ISMS na podlagi ISO/IEC 27001:2022 ne zadosti le enemu standardu. Ustvari odporen in zagovorljiv položaj v celotnem regulativnem okolju. Spodnja tabela povzema, kako ti koraki ustvarjajo preverljiva dokazila za vsak pregled.

KorakSklic na politiko/kontroloPreslikava NIS2Preslikava GDPRPreslikava DORADokazila o izvedbi
Razvrstitev dobaviteljev po ravneh5.19, Blueprint S10/S23Article 21Article 28Art. 28-30Evidenca dobaviteljev v ISMS, razvrščena po tveganjih.
Varnostne pogodbene klavzule5.20, ISO/IEC 27036-2Article 22Article 28(3)Art. 30Vzorčne pogodbe z varnostnimi dodatki, SLA.
Stalni pregled5.22, ISO/IEC 22301Article 21Article 32Art. 31Zapisniki sestankov, nadzorne plošče uspešnosti, revizijski dnevniki.
Določila o varstvu podatkov5.20, ISO/IEC 27701Recital 54Arts. 28, 32Art. 30Sklenjene pogodbe o obdelavi osebnih podatkov (DPA).
Obvestilo o incidentu5.22, ISO/IEC 27036-2Article 23Arts. 33, 34Art. 31Dnevniki incidentov dobaviteljev, evidence komuniciranja.
Izhod/prenehanje5.20, ISO/IEC 27001:2022 A.5.11Pomembno za odpornostArticle 28(3)Art. 30Potrdila o uničenju podatkov, kontrolni seznami postopka izstopa.

Vaš priročnik za ukrepanje

Anyina zgodba ni edinstvena. Vodje informacijske varnosti in vodje skladnosti po vsej EU se soočajo z istim izzivom. Grožnja regulativnih glob in osebna odgovornost, ki jo uvaja NIS2, tveganje dobavne verige postavljata med najpomembnejše poslovne skrbi. Dobra novica je, da je pot naprej jasna. Z uporabo strukturiranega pristopa ISO/IEC 27001:2022, ki temelji na tveganjih, lahko vzpostavite program, ki je hkrati skladen in dejansko odporen.

Ne čakajte, da vas v ukrepanje prisili incident. Že danes začnite graditi okvir dobavne verige, skladen z NIS2:

  1. Vzpostavite upravljanje: Uporabite Clarysecovo Politiko varnosti tretjih oseb in dobaviteljev - SME ali predloge za večja podjetja, da opredelite pravila izvajanja.
  2. Poznajte svoj ekosistem: Uporabite merila razvrščanja iz Zenith Blueprint za identifikacijo in razvrstitev kritičnih dobaviteljev z visokim tveganjem.
  3. Okrepite pogodbe: Revidirajte obstoječe dogovore z dobavitelji glede na zahteve kontrole 5.20 iz ISO/IEC 27001:2022 ter uporabite smernice za medokvirno skladnost v Zenith Controls, da izpolnite pričakovanja NIS2, DORA in GDPR.
  4. Implementirajte stalno spremljanje: Načrtujte prvi četrtletni varnostni pregled z najkritičnejšim dobaviteljem in uporabite naš kontrolni seznam kot vodilo. Vse ugotovitve dokumentirajte v ISMS.
  5. Pripravite revizijska dokazila: Zberite vzorčne pogodbe, zapisnike pregledov, dnevnike incidentov in ocene tveganj, preslikane na ključne kontrole za vsakega kritičnega dobavitelja.

Vaša dobavna veriga ni nujno vaš najšibkejši člen. S pravim okvirom, procesi in orodji jo lahko spremenite v vir moči in temelj svoje strategije kibernetske varnosti.

Ste pripravljeni zgraditi dobavno verigo, ki zadosti regulatorjem in upravnemu odboru? Prenesite Clarysec Zenith Blueprint in že danes pospešite svojo pot do skladnosti in odpornosti.

Frequently Asked Questions

About the Author

Igor Petreski

Igor Petreski

Compliance Systems Architect, Clarysec LLC

Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

Share this article

Related Articles