Opas · 8 min lukuaika
NIS2 Art. 21(2): tarkistuslista toimittajille
Toimiva käsikirjoitus hankinta- ja tietoturvatiimeille: niin uuden toimittajan käyttöönottoon kuin vuosittaiseen tarkastukseenkin. Kustakin NIS2:n artiklan 21(2) kuudesta toimitusketjun kannalta olennaisesta alakohdasta: mitä kysyä, miksi sillä on merkitystä, mitä näyttöä pyytää ja miten reagoida, kun vastaus jää vajaaksi.
Keskeiset huomiot
- Kuusi artiklan 21(2) alakohtaa kantaa suurimman osan toimitusketjun painosta: tässä on, mitä kustakin kysyä ja mikä dokumentti sen todistaa.
- Puolet niistä on teknisiä ja muuttuu ilman varoitusta, joten ne vaativat jatkuvaa tarkistusta eivätkä riviä vuosittaisessa kyselyssä.
- Puute ei ole tuomio. Dokumentoitu, omistettu korjauspäätös tekee asemastasi puolustettavan auditoijan edessä.
Artikla 21(2)(d) tekee toimittajiesi tietoturvan arvioinnista osan omaa riskienhallintaasi, eikä se ole kertaluonteista. Velvollisuus koskee niin toimittajaa, jonka kanssa olet juuri allekirjoittamassa, kuin sitäkin, jonka kanssa olet työskennellyt vuosia. Vuosittainen tarkastus on lattia, ei katto. Vaikeus on siinä, että vaatimustaso (”asianmukaiset toimenpiteet”) skaalautuu riskin mukaan eikä pysy paikallaan, joten keväällä puhtaalta näyttänyt arviointi voi kertoa hyvin vähän syksyllä.
Seuraavassa käydään läpi ne kuusi artiklan 21(2) alakohtaa, jotka kantavat eniten toimitusketjun painoa. Kukin esitetään niin kuin se on aidosti hyödyllinen neuvottelutilanteessa: mitä kysyä, miksi sillä on merkitystä ja mikä dokumentti pyytää näytöksi. Käytä sitä käsikirjoituksena sekä käyttöönottokeskusteluun että vuositarkastukseen, ja lue tekniset alakohdat asioina, jotka todennetaan jatkuvasti, ei kerran.
Huomio soveltamisalasta. Tämä on ohjeistusta, ei oikeudellinen lausunto: valvova viranomaisesi tai tilintarkastaja voi odottaa enemmän toimialasi ja kokosi perusteella, ja sopimussanamuoto kannattaa luetuttaa lakimiehellä. Mainitut aikarajat (korjausikkunat ja vastaavat) ovat järkeviä vertailukohtia, eivät NIS2:n lakisääteisiä takarajoja.
Kuusi alakohtaa siinä järjestyksessä, jossa ne kannattaa kysyä:
Art. 21(2)(a)Riskienhallinta
Aloita erosta toimittajan, joka hallitsee kyberriskiä pysyvänä toimintatapana, ja sellaisen välillä, joka säntäilee kerran vuodessa. Dokumentoitu tietoturvan hallintajärjestelmä (ISO 27001 on selkeä pikamuoto, mutta kirjallinen ISMS-politiikkakin käy) osoittaa, että prosessi on olemassa; paljastavampi kysymys on, milloin johto tai hallitus viimeksi käsitteli sitä ja onko kriittiset järjestelmät ja data tosiasiassa kartoitettu ja luokiteltu. Pyydä politiikka tai sertifikaatti ja merkitse muistiin viimeisimmän käsittelyn päivämäärä: ohjelma, jota kukaan ei ole avannut kahteen vuoteen, on sellainen vain nimellisesti.
Art. 21(2)(b)Poikkeamien käsittely
Jos tämä toimittaja on niin merkittävä, että sen murto voisi häiritä palveluasi, sen poikkeama käynnistää sinun artiklan 23 ilmoituskellosi, ja ehdit siihen vain, jos toimittaja kertoo sinulle nopeasti. Hyvä tahto ei sitä kanna; sopimuksen on kannettava: määritelty aikaikkuna ilmoittaa sinulle tietoturvapoikkeamasta, nimetty yhteyshenkilö, joka vastaa ympäri vuorokauden, ja sen takana testattu reagointisuunnitelma eikä dokumentti, jota kukaan ei ole harjoitellut. Pyydä tiivistelmä häiriönhallintasuunnitelmasta ja tee 24 tunnin ilmoituksesta kirjallinen sopimusehto, ei riviä sähköpostissa.
Art. 21(2)(d)Toimitusketju
Altistuksesi ulottuu allekirjoittamasi toimittajan ohi niihin, joista tämä on riippuvainen: neljännen osapuolen riskiin. Pätevä toimittaja osaa nimetä alihankkijat, jotka koskettavat dataasi tai järjestelmiäsi, pitää heidät omiin sopimuksiinsa kirjatuissa tietoturvaehdoissa eikä epämääräisessä viittauksessa ”alan käytäntöihin”, ja arvioi heidät uudelleen vähintään vuosittain. Kysy, pystyykö toimittaja tuottamaan alihankkijarekisterin ja kuvaamaan, miten se arvioi nämä osapuolet; toimittaja, joka ei osaa nimetä kriittisiä neljänsiä osapuoliaan, kertoi juuri jotain tietämisen arvoista.
Art. 21(2)(e)Hankinta ja kehitys
Tunnetut, paikkaamattomat haavoittuvuudet ja elinkaarensa päässä oleva ohjelmisto ovat yleisimpiä sisäänpääsyteitä, joten toimittajan tulisi osoittaa, että haavoittuvuuksien hallinta on todellista eikä tavoitteellista. Järkeviä vertailukohtia: mitään tuen päättymisen jälkeistä ei ole tuotannossa, kriittiset puutteet (CVSS 9.0 ja yli) paikataan noin kuukauden sisällä julkistuksesta ja kaikkea CISAn Known Exploited Vulnerabilities -luettelossa olevaa käsitellään hätätilanteena. Pyydä kuvaus paikkausprosessista ja tuore haavoittuvuustilannekuva: politiikan ja viimeisimmän skannauksen välinen etäisyys on yleensä se, missä totuus asuu.
Art. 21(2)(h)Kryptografia
Tämä on ulospäin näkyvin alakohta ja se, joka lipsuu hiljaisimmin. Vanhentuneet tai itse allekirjoitetut TLS-varmenteet, sivustot, jotka eivät pakota HTTPS:ää, ja puolitiehen jätetty sähköpostin todennus ovat kaikki yleisiä, muuttuvat ilman varoitusta ja ovat kaikki tarkistettavissa ulkoa. Rima on vaatimaton: voimassa olevat varmenteet kaikkialla, HTTPS pakotettuna jokaisella sivustolla ja rajapinnassa, ja SPF, DKIM ja DMARC aidosti konfiguroituina (hardfail, allekirjoitettu, vähintään quarantine-politiikka) eikä jätettyinä oletuksiin. Pyydä varmenteiden hallintaprosessi ja DMARC- tai DNS-tuloste.
Art. 21(2)(i)/(j)Pääsynhallinta ja todennus
Varastetut tunnistetiedot ovat yhä yleisin tapa, jolla hyökkääjä saa jalansijan, joten toimittajan on osoitettava sekä se, että väärinkäyttö on vaikeaa, että se, että se huomattaisiin nopeasti. Käytännössä se tarkoittaa monivaiheista todennusta pakotettuna jokaisessa kriittisessä järjestelmässä ja ylläpitotilissä ilman hiljaisia poikkeuksia, vuotaneiden tunnistetietojen seurantaa tietomurto- ja dark web -datassa sekä tapaa vaihtaa paljastunut kirjautuminen heti ja kirjata tapaus muistiin. Pyydä nähtäväksi MFA:n pakotuspolitiikka ja se, miten tunnistetietojen vuotoseuranta on järjestetty.
Kun toimittaja jää vajaaksi
Yksittäinen puute on harvoin syy lähteä; valvoja (ja oma hallituksesi) etsii näyttöä siitä, että huomasit sen ja teit siitä tietoisen, omistetun päätöksen. Mitoita reagointi sen mukaan, kuinka paljon puuttuu ja mistä.
Yksi tai kaksi puutetta: dokumentoi ja hyväksy
Kirjaa ne toimittajarekisteriin, pyydä korjaussuunnitelma noin 90 päivän sisällä ja palaa asiaan seuraavassa tarkastuksessa. Kirjattu, hyväksytty riski on puolustettava asema; unohdettu ei ole.
Kolmesta viiteen puutetta tai mikä tahansa puute poikkeamien käsittelyssä: tiivistä seuranta
Siirrä toimittaja korkeamman riskin luokkaan, pyydä kirjallinen korjaussuunnitelma päivämäärineen ja harkitse pääsyn rajaamista kriittisimpiin järjestelmiisi, kunnes puutteet sulkeutuvat.
Kuusi puutetta tai enemmän tai kriittinen tekninen haavoittuvuus: eskaloi
Vie asia CISO:lle tai johdolle, punnitse tosiasiassa hallussasi olevia sopimuskeinoja ja (jos toimittaja yltää tuotantodataan tai -järjestelmiin) harkitse tämän pääsyn keskeyttämistä, kunnes kuva on selvä.
Katso, miten toimittajasi todella pärjäävät
7 päivän ilmaiskokeilu · ei luottokorttia · peru milloin vain
Mitä et voi tehdä käsin
Useat näistä tarkistuksista ovat teknisiä, ja ne rapistuvat ilman, että kukaan lähettää sinulle ilmoitusta: varmenne vanhenee, tunnistetieto ilmestyy vuotoon, toimittaja päätyy kiristysohjelman uhrilistalle. Kerran vuodessa täytetty kysely ei näe mitään tästä, ja juuri se on ero paperitarkastuksen ja sen jatkuvan huolellisuuden välillä, jota ”asianmukaisten toimenpiteiden” vaatimus edellyttää.
norppa.io ajaa tämän listan teknisen puolikkaan joka päivä jokaiselle lisäämällesi toimittajalle:
- Kryptografia (h): TLS-varmenteiden voimassaolo ja HTTPS:n pakotus, SPF/DKIM/DMARC-konfiguraatio, DNSSEC
- Pääsy ja todennus (i): työntekijöiden ja asiakkaiden tunnistetiedot tietomurto- ja dark web -datassa
- Hankinta ja kehitys (e): hyödynnettyjen haavoittuvuuksien luettelomerkinnät ja vakavuuspisteytetyt haavoittuvuuslöydökset
- Poikkeamien käsittely (b): kiristysohjelman uhrilistaesiintymät, hälytys heti kun toimittaja ilmestyy
Prosessitason alakohdat (riskienhallinta, poikkeamien käsittely ja toimitusketjun hallinta) ovat juuri se, mitä varten itsearviointikysely on; voit lähettää sen toimittajalle suoraan portaalista ja lukea vastaukset teknisten löydösten vierellä.