EU:n CRA:n tietoturvatukijaksojen hallinta ISO 27001:n avulla
On tiistai klo 08.20, ja verkkoon liitetyn B2B-yhdyskäytävän tuoteomistaja saa viestin säännellyltä asiakkaalta: “Vahvistatteko laiteohjelmistoversion 4.6 tietoturvatukijakson, haavoittuvuuksiin reagoinnin palvelutasosopimuksen sekä sen, säilyykö laite tietoturvapäivitysten piirissä viisivuotisen palvelusopimuksemme ajan.”
Klo 09.00 hankinta on välittänyt DORA-huolellisuusarvioinnin kyselyn. Klo 10.15 lakiasiat kysyy, vastaako markkinoitu tukijakso asiakassopimuksia. Klo 11.00 tietoturvajohtaja kutsutaan NIS2-toimittajariskin katselmointiin, koska tuotetta käyttää hallinnoidun palvelun tarjoaja EU:ssa. Lounaan jälkeen tietosuojatiimi kysyy, voiko tuotteen tukematon API-kirjasto vaikuttaa henkilötietojen turvallisuuteen GDPR:n näkökulmasta.
Epämukava tosiasia käy nopeasti ilmi. Yrityksellä on tiekartta, korjauspäivitysprosessi, julkaisukalenteri ja asiakastukiportaali, mutta sillä ei ole hallittua todentavaa aineistoa tietoturvatukijaksoista.
Tällä puutteella on merkitystä. EU Cyber Resilience Act -säädöksen mukaan tietoturvatukijakso ei ole pelkkä tuotemerkintä. Se on elinkaarisitoumus, joka vaikuttaa haavoittuvuuksien käsittelyyn, päivitysten saatavuuteen, toimittajariippuvuuksien hallintaan, asiakasviestintään, sopimuksellisiin vakuutuksiin ja markkinoille saattamisen jälkeiseen seurantaan. SaaS-toimittajille, laitevalmistajille, ohjelmistojulkaisijoille, pilvipalveluntarjoajille ja ICT-palveluntarjoajille tukijaksosta tulee vaatimustenmukaisuuden kohde, jota auditoijat ja säännellyt ostajat testaavat.
Käytännön ratkaisu ei ole jälleen yksi irrallinen vaatimustenmukaisuustaulukko. Ratkaisu on hallita tietoturvatukijaksoa ISO/IEC 27001:2022 -standardin mukaisessa tietoturvallisuuden hallintajärjestelmässä ja kartoittaa sama todentava aineisto NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT-tyyppisten auditointiodotusten mukaisesti.
Tämä on Clarysecin toimintamalli: käytä ISMS:ää näyttömoottorina, määritä vastuut täytäntöönpantavilla politiikoilla, rakenna jäljitettävyys Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -materiaalin avulla ja käytä Zenith Controls: The Cross-Compliance Guide Zenith Controls -opasta vaatimustenmukaisuuksien välisenä kompassina.
Miksi tietoturvatukijakso on nyt auditoinnin kohde
Tietoturvatukijakso vastaa yksinkertaiseen kysymykseen: kuinka kauan valmistaja tarjoaa tuotteelle tai tuoteversiolle tietoturvapäivityksiä, haavoittuvuuksien korjausta, lieventämisohjeita ja niihin liittyvää asiakastukea?
Käytännössä vastaus riippuu monista tekijöistä:
- Tuotearkkitehtuuri ja ylläpidettävyys
- Kolmannen osapuolen komponenttien ja avoimen lähdekoodin riippuvuuksien tuki
- Toimittajien ja pilvipalvelujen sitoumukset
- Haavoittuvuusilmoitusten vastaanotto-, luokittelu-, korjaus- ja julkistamisprosessit
- Julkaisutuotannon ja testauksen kapasiteetti
- Asiakassopimusten ehdot ja sääntelyvelvoitteet
- Tietoturvapoikkeamiin reagointi ja ilmoituspolut palvelun vastaanottajille
- Todentavan aineiston säilytys ja hyväksymiskirjaukset
Jos valmistaja lupaa viiden vuoden tietoturvatuen, mutta kriittinen kryptografinen kirjasto menettää tukensa kolmen vuoden jälkeen, tukijaksosta tulee riskipäätös. Jos asiakas on DORA:n soveltamisalaan kuuluva finanssialan toimija, samasta tukijaksosta tulee osa ICT-kolmansien osapuolten varmentamista. Jos tuote käsittelee henkilötietoja, tukematon ohjelmisto voi liittyä GDPR:n mukaiseen käsittelyn turvallisuuden osoitusvelvollisuuteen. Jos tuote tukee NIS2:n mukaista keskeistä tai tärkeää toimijaa, elinkaaren tietoturvasta tulee toimitusketjun turvallisuuskysymys.
NIS2 tekee tästä hallinnointinäkökulmasta nimenomaisen. Article 20 edellyttää, että keskeisten ja tärkeiden toimijoiden hallintoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet, valvovat toteutusta ja saavat koulutusta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen hankinta, turvallinen kehittäminen ja ylläpito, haavoittuvuuksien käsittely ja julkistaminen, vaikuttavuuden arviointi, kyberhygienia, kryptografia, pääsynhallinta, omaisuudenhallinta ja todennus. Article 23 lisää vaiheistetut merkittäviä poikkeamia koskevat raportointivelvoitteet.
DORA luo vastaavan paineen finanssialan toimijoille. Se edellyttää ICT-riskien hallintaa, digitaalisen toiminnan häiriönsietokyvyn testausta, poikkeamien hallintaa ja ICT-kolmansien osapuolten riskien hallintaa. DORA Article 28 kattaa ICT-kolmansien osapuolten riskienhallinnan periaatteet, ja Article 30 edellyttää kirjallisia sopimusjärjestelyjä, joissa on selkeät palvelukuvaukset, turvatoimet, poikkeamatilanteissa annettava apu, auditointioikeudet, irtisanomisoikeudet ja irtautumisjärjestelyt.
GDPR lisää tietosuojakerroksen. Jos tuote käsittelee henkilötietoja, rekisterinpitäjät ja henkilötietojen käsittelijät tarvitsevat Article 32:n mukaiset asianmukaiset tekniset ja organisatoriset toimenpiteet, Article 28:n mukaisen sopimuksellisen selkeyden sekä Articles 33 ja 34:n mukaisen tietoturvaloukkauksen arviointi- ja ilmoitusvalmiuden.
Siksi CRA:n tietoturvatukijaksoa on hallittava kuten ISMS:n hallintakeinoperhettä, ei yksittäisenä tuotehallinnan kenttänä.
ISO 27001 CRA:n tietoturvatukijaksojen hallintakeinojen selkärankana
ISO/IEC 27001:2022 on hyödyllinen, koska se on skaalautuva, riskiperusteinen ja hallintajärjestelmäkeskeinen. Se edellyttää, että organisaatio määrittää toimintaympäristön, sidosryhmät, soveltamisalan ja toisiinsa liittyvät prosessit ja muuntaa sen jälkeen lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset vaatimukset riskienarvioinniksi, riskien käsittelyksi, operatiivisiksi hallintakeinoiksi ja todentavaksi aineistoksi ISO/IEC 27001:2022.
Tietoturvatukijaksojen hallinnassa tämä tarkoittaa, että organisaation on:
- Tunnistettava soveltamisalaan kuuluvat tuotteet, versiot, moduulit, pilvipalvelut ja riippuvuudet.
- Tunnistettava sidosryhmät, kuten asiakkaat, sääntelyviranomaiset, jakelijat, maahantuojat, integraattorit, henkilötietojen käsittelijät, alikäsittelijät, tietoturvapoikkeamiin reagoinnin kumppanit ja toimittajat.
- Kirjattava lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset tukivelvoitteet.
- Arvioitava riskit, jotka voivat estää tukisitoumusten täyttämisen.
- Valittava hallintakeinot haavoittuvuuksien hallintaan, turvalliseen kehittämiseen, toimittajavarmennukseen, poikkeamien hallintaan, liiketoiminnan jatkuvuuteen, tietosuojaan ja dokumentoituun tietoon.
- Laadittava soveltuvuuslausunnon kirjaukset, joissa selitetään, miksi hallintakeinoja sovelletaan.
- Katselmoitava tukijakso, kun arkkitehtuuri, toimittajariippuvuudet, uhka-altistus tai asiakassitoumukset muuttuvat.
Zenith Controls tunnistaa kolme aiheeseen liittyvää ISO/IEC 27002:2022 -hallintakeinoa tämän hallinnointiongelman keskeisiksi ankkureiksi: 5.31 lakisääteiset, viranomais-, sääntely- ja sopimusperusteiset vaatimukset, 8.8 teknisten haavoittuvuuksien hallinta ja 8.25 turvallisen kehityksen elinkaari. Ne eivät ole ainoat asiaan liittyvät hallintakeinot, mutta ne muodostavat hallinnan selkärangan.
| Tietoturvatukijaksoa koskeva päätös | ISO 27001- ja ISO 27002 -todentavan aineiston alue | Miksi auditoijat välittävät |
|---|---|---|
| Tukikeston määrittäminen tuoteversiokohtaisesti | Toimintaympäristö, sidosryhmät, lakisääteiset ja sopimusperusteiset vaatimukset, hallintakeino 5.31 | Osoittaa, että sitoumus perustuu velvoitteisiin ja riskiin, ei mielivaltaiseen markkinointiin |
| Tukijakson ja poikkeusten hyväksyntä | Johtajuus, roolit, riskin hyväksyminen, soveltuvuuslausunto | Osoittaa vastuutetun päätöksenteon ja jäännösriskin hyväksynnän |
| Haavoittuvuuksiin reagoinnin ylläpito tuen aikana | Hallintakeino 8.8, turvallinen kehittäminen, testaus, muutoksenhallinta | Osoittaa, että organisaatio pystyy toimittamaan tietoturvapäivityksiä |
| Toimittajien ja komponenttien seuranta | Toimittajasuhteet, ICT-toimitusketju, pilvipalvelut, ulkoistettu kehittäminen | Osoittaa, että sitoumukset ovat realistisia ulkoisista riippuvuuksista huolimatta |
| Tukitilan ja päättymispäivien viestintä | Dokumentoitu tieto, asiakasviestintä, julkistamisprosessit | Osoittaa, ettei asiakkaita johdeta harhaan ja että he voivat hallita omaa riskiään |
| Tuen pidentäminen tai lyhentäminen | Muutosten hallinta, riskien uudelleenarviointi, sopimuskatselmointi, johdon katselmointi | Osoittaa, että elinkaarimuutokset ovat hallittuja ja todennettuja |
| Auditointinäytön säilyttäminen | Dokumentoitu tieto, tallenteiden suojaus, todentavan aineiston kerääminen | Osoittaa, että väitteet voidaan testata sertifioinnissa, asiakasauditoinnissa tai viranomaistiedustelussa |
Keskeistä on jäljitettävyys. Tuotteen tukijakson on oltava jäljitettävissä velvoitteesta riskiskenaarioon, riskiskenaariosta valittuihin hallintakeinoihin, hallintakeinoista politiikkavaatimuksiin ja politiikkavaatimuksista todentavaan aineistoon.
Zenith Blueprint, riskienhallintavaihe, Step 13, kuvaa tämän jäljitettävyyskurinalaisuuden suoraan:
“Ristiinviittaa sääntelyyn: jos tietyt hallintakeinot on toteutettu nimenomaisesti GDPR:n, NIS2:n tai DORA:n noudattamiseksi, voit kirjata sen joko riskirekisteriin osana riskivaikutuksen perustelua tai SoA-kirjauksiin.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskienhallintavaihe, Step 13: riskienkäsittelyn suunnittelu ja soveltuvuuslausunto Zenith Blueprint
CRA:n tietoturvatukijakson osalta soveltuvuuslausunnossa ei pidä vain todeta, että “haavoittuvuuksien hallintaa sovelletaan”. Sen on selitettävä, että haavoittuvuuksien hallintaa sovelletaan, koska yrityksellä on CRA:n mukaisia elinkaarisitoumuksia, NIS2:n mukaisia turvallisen kehittämisen ja toimitusketjun odotuksia, DORA-asiakkaiden huolellisuusvaatimuksia, GDPR:n mukaisia tietoturvavelvoitteita henkilötietoja käsiteltäessä sekä sopimusperusteisia tukilupauksia.
Tukilupauksesta hallituksi elinkaareksi
Valmistajan määrittämän tietoturvatukijakson on läpäistävä kuusi hallinnointitestiä.
Ensiksi se on määritettävä. Organisaatio tarvitsee vakiotaksonomian, kuten aktiivinen tuki, vain tietoturvatuki, laajennettu tuki, rajoitettu tuki ja tukematon. Kunkin tilan on kuvattava päivitysten saatavuus, haavoittuvuuksien käsittely, asiakasviestintä ja eskalointipolut.
Toiseksi siitä on tehtävä riskienarviointi. Viiden vuoden tuki pilvihallitulle SaaS-tuotteelle, jolla on hallitut päivityskanavat, eroaa viiden vuoden tuesta sulautetulle laitteelle, jolla on kenttärajoitteita, kolmannen osapuolen piiririippuvuuksia ja asiakkaan hallinnoimia käyttöönottoikkunoita.
Kolmanneksi se on hyväksyttävä. Tuotehallinnan, tietoturvan, lakiasioiden, tietosuojan, asiakastuen ja vastuullisen johdon on hyväksyttävä perustukijakso ja poikkeukset.
Neljänneksi siitä on viestittävä. Asiakkaiden on ymmärrettävä tuen alkamispäivä, päättymispäivä, päivitystapa, haavoittuvuuksien ilmoituskanava, korjausodotukset, tuen päättymisen seuraukset ja käytettävissä olevat pidennysvaihtoehdot.
Viidenneksi sitä on seurattava. Riippuvuudet muuttuvat. Toimittajat lopettavat kirjastojen ylläpidon. Haavoittuvuuksia ilmenee. Asiakasympäristöt muuttuvat. Tukijaksojen hallinnan on sisällettävä komponenttien elinkaariseuranta, toimittajakatselmointi, haavoittuvuussyötteet, korjauspäivityslokit, julkaisujen testaus ja poikkeamista saadut opit.
Kuudenneksi siitä on säilytettävä todentava aineisto. Jos auditoija, viranomainen tai säännelty asiakas pyytää näyttöä, organisaation on pystyttävä esittämään vaatimustenmukaisuusrekisteri, tuotetukirekisteri, riskienarviointi, SoA-kartoitus, haavoittuvuusrekisteri, korjauspäivitystiedot, toimittajakatselmoinnit, julkaisuhyväksynnät ja asiakasilmoitukset.
Clarysecin politiikat tekevät tästä käytännöllistä. Enterprise Laki- ja sääntelyvaatimusten noudattamisen politiikka Laki- ja sääntelyvaatimusten noudattamisen politiikka edellyttää:
“Kaikki lakisääteiset ja sääntelyyn perustuvat velvoitteet on kartoitettava tiettyihin politiikkoihin, hallintakeinoihin ja omistajiin tietoturvallisuuden hallintajärjestelmässä (ISMS).”
Lähde: Laki- ja sääntelyvaatimusten noudattamisen politiikka, politiikan toteutusvaatimukset, lauseke 6.2.1 Laki- ja sääntelyvaatimusten noudattamisen politiikka
Pk-yrityksillä vastaava kurinalaisuus alkaa yksinkertaisemmasta rekisteristä. Pk-yrityksen Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys toteaa:
“Toimitusjohtajan on ylläpidettävä yksinkertaista, jäsenneltyä vaatimustenmukaisuusrekisteriä, jossa luetellaan:”
Lähde: Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys, hallinnointivaatimukset, lauseke 5.1.1 Laki- ja sääntelyvaatimusten noudattamisen politiikka - pk-yritys
Tukijaksositoumuksen on oltava vaatimustenmukaisuusrekisterissä, jos se perustuu lakiin, asiakassopimukseen, toimialasääntelyyn tai säännellyn ostajan odotukseen. Sen ei pidä sijaita vain julkaisutiedotteissa tai markkinointitekstissä.
Rakenna CRA:n tietoturvatukijaksorekisteri yhdessä työpajassa
Kuvitellaan SaaS-toimittaja, joka myy verkkoon liitettyä analytiikkalaitetta EU:n logistiikkapalveluntarjoajille ja finanssialan asiakkaille. Tuotteeseen sisältyy sulautettu agentti, pilvipalvelun API, mobiilihallintasovellus ja useita avoimen lähdekoodin kirjastoja. Myynti haluaa luvata viiden vuoden tietoturvatuen jokaiselle merkittävälle laiteversiolle.
Tietoturvajohtaja voi järjestää kohdennetun työpajan tuotehallinnan, suunnittelun, lakiasioiden, tietosuojan ja toimittajahallinnan kanssa.
Vaihe 1: Luo tukijaksorekisteri
Luo yksi rivi kutakin tuoteversiota kohti ja sisällytä siihen:
- Tuote ja versio
- Julkaisupäivä
- Tuen alkamispäivä
- Vakiomuotoinen tietoturvatuen päättymispäivä
- Laajennetun tuen vaihtoehto
- Päivitysten toimitustapa
- Haavoittuvuuksien julkistuskanava
- Kriittisen korjauspäivityksen tavoiteaika
- Tietojen käsittelyrooli, kuten rekisterinpitäjä, henkilötietojen käsittelijä tai molemmat
- Kriittiset toimittajat ja komponentit
- Vaikutuksen piirissä olevat asiakassektorit
- Riskinomistaja
- Hyväksyntäpäivä
- Todentavan aineiston sijainti
Tästä rekisteristä tulee ISMS:n mukaista dokumentoitua tietoa. Zenith Blueprint, ISMS-perustan ja johtajuuden vaihe, Step 6, antaa asiakirjahallintaa koskevan odotuksen:
“Asiakirjoilla tulisi olla asianmukainen tunniste (otsikko, mahdollisesti asiakirjanumero tai yksilöllinen tunniste, tekijä), asianmukainen muoto sekä katselmointi ja hyväksyntä soveltuvuuden varmistamiseksi ennen käyttöä.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, ISMS-perustan ja johtajuuden vaihe, Step 6: dokumentoitu tieto ja ISMS-kirjaston rakentaminen Zenith Blueprint
Clarysecin Enterprise PIMS:n dokumentoidun tiedon ja todentavan aineiston hallintapolitiikka PIMS:n dokumentoidun tiedon ja todentavan aineiston hallintapolitiikka soveltaa vastaavia näyttöperiaatteita tietosuojadokumentaatioon:
“[Kaikki] Tietosuojavastaavan / PIMS-päällikön ON annettava asiakirjatunniste, omistaja, versionumero, hyväksyntätila, voimaantulopäivä ja katselmointipäivä REG12:ssa ennen PIMS:n dokumentoidun tiedon julkaisemista.”
Lähde: PIMS:n dokumentoidun tiedon ja todentavan aineiston hallintapolitiikka, luominen, hyväksyntä, versiointi ja julkaisu, lauseke 4.2.1 PIMS:n dokumentoidun tiedon ja todentavan aineiston hallintapolitiikka
Vaikka tukijaksorekisteri ei oletusarvoisesti olisi tietosuoja-asiakirja, sama kurinalaisuus pätee: omistaja, versio, hyväksyntä, voimaantulopäivä ja katselmointipäivä.
Vaihe 2: Kytke tukilupaukset riskien käsittelyyn
Laadi kullekin tuoteversiolle riskiskenaarioita, kuten:
- Tuetusta versiosta löydetään kriittinen haavoittuvuus, mutta suunnittelukapasiteettia ei ole käytettävissä.
- Kolmannen osapuolen komponentti menettää tukensa ennen ilmoitetun tietoturvatukijakson päättymistä.
- Toimittaja muuttaa hosting-sijaintia tai alihankkijaa ja vaikuttaa päivitysten toimitukseen.
- Haavoittuvuus vaikuttaa henkilötietoihin ja käynnistää tietoturvaloukkauksen arvioinnin.
- Säännelty finanssialan asiakas edellyttää todentavaa aineistoa ICT-kolmansien osapuolten häiriönsietokyvystä.
ISO/IEC 27001:2022 -standardin lausekkeet 6.1.1–6.1.3 tarjoavat suunnittelumoottorin: tunnista riskit, arvioi todennäköisyys ja seuraukset, nimeä riskinomistajat, valitse käsittelytavat, vertaa valittuja hallintakeinoja Annex A:han, tuota soveltuvuuslausunto ja hanki jäännösriskin hyväksyntä.
Riskille “tukematon komponentti ennen tukijakson päättymispäivää” riskikirjauksen on sisällettävä ISO/IEC 27002:2022 -hallintakeinot 5.31, 8.8 ja 8.25 sekä toimittajiin liittyvät hallintakeinot, kuten 5.19 tietoturva toimittajasuhteissa, 5.20 tietoturvan käsittely toimittajasopimuksissa, 5.21 tietoturvan hallinta ICT-toimitusketjussa ja 5.22 toimittajapalvelujen seuranta, katselmointi ja muutoksenhallinta.
Vaihe 3: Määritä haavoittuvuuksien ja korjauspäivitysten näyttösäännöt
Tukijakso on uskottava vain, jos haavoittuvuuksien hallinta toimii sen aikana.
Pk-yrityksen Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys asettaa kiireelliselle altistumiselle tiukan vaatimuksen:
“Kriittiset korjauspäivitykset on asennettava 3 päivän kuluessa julkaisusta, erityisesti internetiin avautuviin järjestelmiin”
Lähde: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys, politiikan toteutusvaatimukset, lauseke 6.1.1 Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys
Se edellyttää myös auditointivalmiita tallenteita:
“Korjauspäivityslokia on ylläpidettävä ja se on katselmoitava auditointien ja tietoturvapoikkeamiin reagoinnin aikana”
Lähde: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys, hallinnointivaatimukset, lauseke 5.4.1 Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka - pk-yritys
Enterprise-ympäristöissä Enterprise Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka edellyttää:
“Tietoturvaoperaatiotiimin on ylläpidettävä keskitettyä haavoittuvuuksien hallintarekisteriä, ja tietoturvajohtajan tai delegoidun toimivaltaisen henkilön on katselmoitava se kuukausittain.”
Lähde: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, hallinnointivaatimukset, lauseke 5.1 Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka
Zenith Blueprint, hallintakeinot käytännössä -vaihe, Step 19, selittää ISO/IEC 27002:2022 -hallintakeinon 8.8 taustalla olevan operatiivisen odotuksen:
“Pysy ajan tasalla ohjelmistoihin ja laitteistoihin liittyvistä uusista tietoturvavirheistä (esimerkiksi toimittajahälytysten, CVE-syötteiden jne. avulla). Arvioi, mitkä niistä ovat olennaisia (käytämmekö tätä ohjelmistoa? kuinka kriittinen virhe on?) ja asenna korjaukset tai toteuta lievennykset viipymättä.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, hallintakeinot käytännössä -vaihe, Step 19: teknologiset hallintakeinot I Zenith Blueprint
Jokaisella tuetulla tuoteversiolla on oltava haavoittuvuuksia koskeva näyttöketju: ilmoituksen vastaanotto, relevanssianalyysi, vakavuus, vaikutuksen alaiset versiot, korjaussuunnitelma, korjausjulkaisu, lieventämisohjeet, asiakasviestintä ja sulkemishyväksyntä.
Vaihe 4: Kytke turvallinen kehittäminen tukikestoon
Tietoturvatuki alkaa ennen julkaisua. Se perustuu kehityskäytäntöihin, jotka tekevät tuotteesta ylläpidettävän.
Pk-yrityksen Turvallisen kehityksen politiikka - pk-yritys Turvallisen kehityksen politiikka - pk-yritys toteaa:
“Komponentit on päivitettävä säännöllisesti, kun tietoturvakorjauksia julkaistaan. Jos kriittinen haavoittuvuus tunnistetaan, komponentti on päivitettävä tai korvattava välittömästi.”
Lähde: Turvallisen kehityksen politiikka - pk-yritys, politiikan toteutusvaatimukset, lauseke 6.6.3 Turvallisen kehityksen politiikka - pk-yritys
Pk-yrityksen Sovellusturvallisuusvaatimusten politiikka - pk-yritys Sovellusturvallisuusvaatimusten politiikka - pk-yritys edellyttää, että sopimuksissa ja vaatimuksissa:
“määritetään velvoitteet haavoittuvuuksien julkistamiselle, vasteajoille ja korjauspäivityksille.”
Lähde: Sovellusturvallisuusvaatimusten politiikka - pk-yritys, hallinnointivaatimukset, lauseke 5.3.2 Sovellusturvallisuusvaatimusten politiikka - pk-yritys
Jos yritys lupaa tukea vuoteen 2031 asti, arkkitehtuurin on tuettava ylläpidettäviä päivityksiä, riippuvuuksien korvaamista, turvallisia koontiputkia, regressiotestausta ja hätäjulkaisuja. ISO/IEC 27002:2022 -hallintakeinoista turvallinen kehittäminen, turvallinen arkkitehtuuri, turvallinen ohjelmointi, tietoturvatestaus, ulkoistettu kehittäminen, ympäristöjen erottaminen ja muutoksenhallinta mahdollistavat tukijakson toteuttamisen.
Yksi näyttökokonaisuus CRA:lle, NIS2:lle, DORA:lle ja GDPR:lle
Sama tukijaksoa koskeva todentava aineisto voi vastata eri sääntelykeskusteluihin, mutta kukin viitekehys kysyy asiaa eri tavalla.
| Todentavan aineiston kohde | CRA:n tukijaksoa koskeva tarkoitus | NIS2-relevanssi | DORA-relevanssi | GDPR-relevanssi |
|---|---|---|---|---|
| Tuotteen tukijaksorekisteri | Määrittää tuetut versiot, päättymispäivät, päivitystavan ja omistajat | Tukee Article 21:n mukaista riskienhallintaa ja palvelun häiriönsietokykyä | Tukee ICT-omaisuutta ja kolmansien osapuolten varmentamista Articles 28 ja 30:n mukaisesti | Tukee osoitusvelvollisuutta, kun tuotteet käsittelevät henkilötietoja |
| Haavoittuvuuksien hallintarekisteri | Seuraa haavoittuvuuksia tuetuissa versioissa | Tukee Article 21(2)(e):n mukaista turvallista hankintaa, kehittämistä, ylläpitoa sekä haavoittuvuuksien käsittelyä ja julkistamista | Tukee häiriönsietokyvyn testausta ja korjaavien toimenpiteiden näyttöä Articles 24 ja 25:n mukaisesti | Tukee Article 32:n mukaista käsittelyn turvallisuutta ja tietoturvaloukkauksen arviointia |
| Toimittajariippuvuusrekisteri | Tunnistaa toimittajat, jotka voisivat rikkoa tukisitoumukset | Tukee Article 21(2)(d):n mukaista toimitusketjun turvallisuutta | Tukee ICT-kolmansien osapuolten riskiä, alihankintaa ja irtautumissuunnittelua | Tukee Article 28:n mukaista käsittelijöiden ja alikäsittelijöiden seurantaa |
| Korjauspäivitysloki ja julkaisutallenne | Todistaa, että korjaukset toimitettiin tuen aikana | Tukee vaikuttavuuden arviointia ja poikkeamanäyttöä | Tukee korjaavien toimenpiteiden näyttöä ja asiakasvarmennusta | Tukee teknisiä ja organisatorisia toimenpiteitä |
| Asiakasilmoitusten tallenne | Osoittaa tuki- ja lieventämisviestinnän | Tukee palvelun vastaanottajalle annettavaa viestintää ja Article 23 -analyysia | Tukee asiakasviestintää, kun finanssialan intressit ovat vaikutuksen piirissä | Tukee tietoturvaloukkaus- ja läpinäkyvyysanalyysiä |
| Johdon katselmoinnin pöytäkirjat | Osoittavat valvonnan ja parantamisen | Tukevat Article 20:n mukaista johdon osoitusvelvollisuutta | Tukevat hallintoelimen hallintaa | Tukevat osoitusvelvollisuutta ja tietosuojariskien katselmointia |
Toimittajariippuvuus on usein kohta, jossa tukisitoumukset pettävät. Enterprise Toimittajariippuvuuksien riskienhallintapolitiikka Toimittajariippuvuuksien riskienhallintapolitiikka edellyttää:
“Toimittajariippuvuusrekisteri: toimittajahallintatoiminnon on ylläpidettävä ajantasaista rekisteriä kaikista kriittisistä toimittajista, mukaan lukien tiedot tarjotuista palveluista/tuotteista; siitä, onko toimittaja ainoa lähde; käytettävissä olevista vaihtoehtoisista toimittajista tai korvattavuudesta; nykyisistä sopimusehdoista; sekä arvio vaikutuksesta, jos toimittaja epäonnistuisi tai vaarantuisi.”
Lähde: Toimittajariippuvuuksien riskienhallintapolitiikka, toteutusvaatimukset, lauseke 6.1 Toimittajariippuvuuksien riskienhallintapolitiikka
Zenith Blueprint, hallintakeinot käytännössä -vaihe, Step 23, varoittaa, että auditoijat tarkastavat toimittajasopimuksia ja toimittajaseurannan todentavaa aineistoa:
“Auditoijat käyvät läpi otoksia sopimuksista tai palvelusopimuksista. He etsivät nimenomaisia tietoturvalausekkeita, kuten tietoturvaloukkauksista ilmoittamisen määräaikoja, pääsyn rajoituksia, tietojenkäsittelyvelvoitteita, salausvaatimuksia tai auditointioikeuksia.”
Lähde: Zenith Blueprint: An Auditor’s 30-Step Roadmap, hallintakeinot käytännössä -vaihe, Step 23: organisatoriset hallintakeinot Zenith Blueprint
DORA-asiakkaille tämä on kriittistä. Kriittisiä tai tärkeitä toimintoja tukevien ICT-palvelujen sopimuksissa tarvitaan selkeät palvelukuvaukset, alihankinnan ehdot, turvatoimet, poikkeama-apu, auditointi- ja tarkastusoikeudet, irtisanomisoikeudet sekä siirtymäjärjestelyt. Toimittaja, joka ei pysty tukemaan näitä sitoumuksia, voi estää valmistajaa antamasta uskottavaa tukijaksolupausta.
Hallintakeinojen vastaavuustaulukko auditointivalmiiseen tukijaksojen hallintaan
| Hallintakeino tai vaatimus | Oikea auditointitulkinta | Tietoturvatukijaksoa koskeva todentava aineisto |
|---|---|---|
| ISO/IEC 27002:2022 5.31 lakisääteiset, viranomais-, sääntely- ja sopimusperusteiset vaatimukset | Tunnista ja dokumentoi sovellettavat lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset velvoitteet | Vaatimustenmukaisuusrekisteri, asiakassopimusten katselmointi, CRA:n tukijaksovelvoitteiden kartoitus |
| ISO/IEC 27002:2022 8.8 teknisten haavoittuvuuksien hallinta | Tunnista, arvioi, priorisoi ja korjaa tekniset haavoittuvuudet | Haavoittuvuusrekisteri, CVE-analyysi, korjauspäivitysloki, lieventämispäätökset |
| ISO/IEC 27002:2022 8.25 turvallisen kehityksen elinkaari | Määritä turvallisen kehittämisen säännöt koko tuotteen elinkaarelle | SDLC-politiikka, tietoturvavaatimukset, komponenttipäivitysten näyttö, julkaisuhyväksynnät |
| NIS2 Article 20 | Hallintoelimet hyväksyvät, valvovat ja ymmärtävät kyberturvallisuuden riskitoimenpiteet | Johdon hyväksyntä, koulutuksen todentava aineisto, johdon katselmoinnin pöytäkirjat |
| NIS2 Article 21(2)(d) | Toimitusketjun turvallisuus on osa kyberturvallisuuden riskienhallintaa | Toimittajariippuvuusrekisteri, toimittajakatselmoinnit, sopimuslausekkeet |
| NIS2 Article 21(2)(e) | Hankinnan, kehittämisen ja ylläpidon turvallisuus sisältää haavoittuvuuksien käsittelyn ja julkistamisen | Turvallisen kehittämisen näyttö, julkistamismenettely, korjaustallenteet |
| DORA Article 28 | Finanssialan toimijat hallitsevat ICT-kolmansien osapuolten riskiä koko elinkaaren ajan | Toimittajavarmennuspaketti, huolellisuusarvioinnin vastaus, alihankkijan todentava aineisto |
| DORA Article 30 | ICT-sopimuksiin sisältyvät keskeiset tietoturva-, pääsy-, auditointi-, irtisanomis- ja irtautumismääräykset | Sopimusliite, SLA, auditointioikeudet, irtautumissuunnitelma |
| GDPR Article 32 | Henkilötiedot on suojattava asianmukaisilla teknisillä ja organisatorisilla toimenpiteillä | Henkilötietoja koskeva haavoittuvuuskattavuus, korjauspäivitystiedot, pääsynhallinta, tietoturvaloukkauksen arviointi |
| NIST CSF 2.0 ID.RA-01 ja PR.PS-02 | Haavoittuvuudet tunnistetaan ja ohjelmistoa ylläpidetään, korvataan tai poistetaan riskin mukaisesti | Nykyprofiili, tavoiteprofiili, haavoittuvuusrekisteri, elinkaaripäätökset |
Tämän vastaavuustaulukon avulla tietoturva-, laki-, tuote- ja myyntitiimit voivat puhua samaa kieltä. Tukijaksorekisteri ei ole vain CRA-näyttöä. Se on toimittajavarmennusta NIS2:lle, kolmansien osapuolten varmentamista DORA:lle, käsittelyn turvallisuuden tukea GDPR:lle ja hallinnointiartefakti ISO 27001 -sertifiointia varten.
Tietosuojanäkökulma: kun tukemattomasta tulee turvatonta
Tietoturvatukijaksojen hallinta ei ole vain kyberturvallisuuskysymys. Jos tuote tallentaa, siirtää tai käsittelee henkilötietoja, tukemattomasta ohjelmistosta voi tulla tietosuojariski.
GDPR soveltuu käsittelyyn EU:ssa sijaitsevan toimipaikan yhteydessä, ja se voi soveltua myös EU:n ulkopuolisiin organisaatioihin, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. Se määrittelee henkilötiedot laajasti ja käsittelee henkilötietojen tietoturvaloukkausta tietoturvaloukkauksena, joka aiheuttaa käsiteltyjen henkilötietojen vahingossa tapahtuvan tai lainvastaisen tuhoamisen, häviämisen, muuttamisen, luvattoman luovuttamisen tai niihin pääsyn.
Tukijaksojen hallinnassa tietosuojatiimien on tiedettävä, mitkä tuoteversiot käsittelevät henkilötietoja, mitkä järjestelmät ovat edelleen tuettuja ja vaikuttavatko haavoittuvuudet henkilötietojen luottamuksellisuuteen, eheyteen tai saatavuuteen.
Clarysecin Enterprise PII-tietoturvan pääsynhallintapolitiikka PII-tietoturvan pääsynhallintapolitiikka edellyttää:
“[Molemmat] Järjestelmäomistajan / sovellusomistajan ON kirjattava henkilötietoja käsittelevien järjestelmien haavoittuvuuksien arvioinnin kattavuus REG12:een vähintään neljännesvuosittain ja olennaisen teknisen muutoksen jälkeen.”
Lähde: PII-tietoturvan pääsynhallintapolitiikka, turvallinen konfigurointi ja haavoittuvuuksien hallinta, lauseke 4.7.4 PII-tietoturvan pääsynhallintapolitiikka
Enterprise Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallinnan politiikka Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallinnan politiikka lisää jatkuvan seurannan korkean riskin tietosuojasuhteille:
“[Kaikki] Toimittaja- / hankintaomistajan ON seurattava aktiivisia korkean riskin käsittelijä- ja alikäsittelijäsuhteita neljännesvuosittain sekä muita aktiivisia henkilötietojen käsittelijä- ja alikäsittelijäsuhteita vuosittain suhteessa huolellisuusarvioinnin ehtoihin, sopimustilaan, varmennustilaan, avoimiin asioihin ja katselmointipäiviin REG08:ssa.”
Lähde: Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallinnan politiikka, jatkuva seuranta, avustaminen, luovutusrajapinta ja irtautuminen, lauseke 4.5.1 Henkilötietojen käsittelijöiden, alikäsittelijöiden ja kolmansien osapuolten tietosuojahallinnan politiikka
Kun haavoittuvuudesta tulee poikkeama, Enterprise Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka edellyttää useiden viitekehysten mukaista ilmoituskynnysten arviointia:
“[Ehdollinen] Tietosuojavastaavan / PIMS-päällikön ON arvioitava sovellettavat lakisääteiset, sektorikohtaiset, finanssialaa koskevat, kyberturvallisuus-, sopimus-, asiakas- ja palvelun vastaanottajan raportointikynnykset kunkin vaikutuksiltaan merkittävän henkilötietopoikkeaman osalta ja kirjattava soveltuvuuden lopputulos REG01:een, REG08:aan ja REG10:een.”
Lähde: Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka, luokittelu ja tietoturvaloukkauksen arviointi, lauseke 4.2.6 Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka
Tämä on käytännön leikkauskohta CRA:n tukisitoumusten, NIS2:n mukaisen poikkeamaviestinnän, DORA:n mukaisten merkittävien ICT-poikkeamien käsittelyn ja GDPR:n mukaisen tietoturvaloukkauksen osoitusvelvollisuuden välillä.
Miten auditoijat testaavat samaa tukijaksoprosessia
Vahvan tukijaksojen hallintaprosessin on kestettävä useita auditointityylejä. Todentava aineisto ei juuri muutu, mutta auditoijan näkökulma muuttuu.
| Auditoijan näkökulma | Todennäköinen auditointikysymys | Odotettu todentava aineisto |
|---|---|---|
| ISO 27001 -auditoija | Miten määrititte tukijaksojen riskit ja valitsitte hallintakeinot? | ISMS:n soveltamisala, sidosryhmävaatimukset, riskirekisteri, SoA, riskienkäsittelysuunnitelma, johdon katselmointi |
| NIST CSF -arvioija | Miten hallinnointi, toimitusketju, suojaus, havaitseminen, reagointi ja palautuminen kytkeytyvät toisiinsa? | Nykyprofiili, tavoiteprofiili, priorisoitu toimintasuunnitelma, toimittajaluettelo, poikkeama- ja palautumistallenteet |
| DORA-asiakasarvioija | Pystyttekö tukemaan kriittisiä tai tärkeitä ICT-palveluja sopimuskauden ajan? | ICT-palvelukuvaus, häiriönsietokyvyn testauksen näyttö, poikkeamaprosessi, kolmansien osapuolten rekisteri, irtautumis- ja siirtymäsuunnitelma |
| NIS2-painotteinen auditoija | Miten hallitsette turvallista kehittämistä, toimitusketjua, haavoittuvuuksien käsittelyä ja palvelun vastaanottajille annettavaa viestintää? | Tukirekisteri, haavoittuvuusrekisteri, toimittajakatselmoinnit, julkistamismenettely, ilmoitusnäyttö |
| GDPR- tai tietosuoja-auditoija | Aiheuttavatko tukemattomat komponentit henkilötietojen turvallisuusriskin? | Henkilötietojärjestelmien inventaario, haavoittuvuuskattavuus, käsittelijöiden seuranta, tietoturvaloukkauksen arviointitallenteet |
| COBIT- tai ISACA-auditoija | Onko elinkaaripäätöksiä hallittu, omistettu, mitattu ja parannettu? | Prosessiomistajuus, RACI, hallintatavoitteet, KPI-mittarit, poikkeushyväksynnät, korjaavat toimenpiteet |
NIST CSF 2.0 on hyödyllinen viestintäkerros, koska sen GOVERN Function sisältää lakisääteiset, sääntelyyn perustuvat, sopimusperusteiset ja tietosuojavelvoitteet, riskienhallintatavoitteet, riskinottohalukkuuden, roolit, politiikat ja valvonnan. Sen toimitusketjutulokset kattavat toimittajastrategian, kriittisyyden, sopimukset, huolellisuusarvioinnin, seurannan, poikkeamakoordinoinnin ja suhteen päättämistä koskevat määräykset.
COBIT- ja ISACA-tyyliset auditoijat keskittyvät usein hallinnointisuunnitteluun: kuka omistaa päätöksen, mikä prosessi on määritelty, mitkä mittarit osoittavat suorituskyvyn, miten poikkeukset hyväksytään ja miten jatkuva parantaminen hoidetaan.
Clarysecin Enterprise Tietoturvapolitiikka Tietoturvapolitiikka kiteyttää auditoitavuusperiaatteen:
“Kaikkien toteutettujen hallintakeinojen on oltava auditoitavissa, ja niiden tukena on oltava dokumentoidut menettelyt sekä säilytetty todentava aineisto toiminnasta.”
Lähde: Tietoturvapolitiikka, politiikan toteutusvaatimukset, lauseke 6.6.1 Tietoturvapolitiikka
Jokaisen tietoturvatukijakson on pystyttävä täyttämään tämä lause.
Pidennä, lyhennä tai päätä tuki luomatta väärää varmuutta
Vaikeimmat hallinnointihetket eivät tapahdu tuotteen julkaisussa. Ne tapahtuvat silloin, kun todellisuus muuttuu.
Tukea saatetaan joutua pidentämään, koska säännellyt asiakkaat ovat riippuvaisia tuotteesta, migraatio ei ole toteuttamiskelpoinen tai toimialan asiakkaalla on sopimusperusteisia jatkuvuustarpeita. Tukea saatetaan joutua lyhentämään tai rajoittamaan, koska toimittaja lopettaa tietoturvaylläpidon, komponenttia ei voida enää paikata, alusta saavuttaa tekniset rajansa tai tuotearkkitehtuuri ei pysty turvallisesti tukemaan tiettyä haavoittuvuusluokkaa.
Hallitun tukijaksomuutoksen on sisällettävä:
- Muutoksen käynnistävä tekijä, kuten toimittajan elinkaaren päättyminen, kriittinen haavoittuvuus, asiakassopimus tai sääntelymuutos
- Vaikutuksen alaiset tuotteet, versiot, asiakkaat ja sektorit
- Henkilötietojen ja kriittisen palvelun vaikutusanalyysi
- Toimittajan ja komponenttien toteutettavuuskatselmointi
- Riskienarviointi ja jäännösriskipäätös
- Päivitetty tukijaksorekisteri
- Päivitetty asiakasilmoitus ja sopimusasema
- Päivitetyt SoA-kirjaukset, jos hallintakeinot tai velvoitteet muuttuvat
- Johdon hyväksyntä ja katselmointipäivä
Enterprise Haavoittuvuuksien koordinoidun julkistamisen politiikka Haavoittuvuuksien koordinoidun julkistamisen politiikka on hyödyllinen, kun muutoksen taustalla on haavoittuvuus:
“Kaikille vahvistetuille haavoittuvuuksille on laadittava korjaus- tai lieventämissuunnitelma. Korjauksen toteutus on priorisoitava vakavuuden perusteella. Esimerkiksi kriittiset haavoittuvuudet on korjattava tai lievennettävä 14 päivän kuluessa, jos se on toteutettavissa, tai nopeammin, jos aktiivista hyväksikäyttöä havaitaan, kun taas vakavuudeltaan vähäisemmät havainnot on käsiteltävä kohtuullisessa ajassa.”
Lähde: Haavoittuvuuksien koordinoidun julkistamisen politiikka, toteutusvaatimukset, lauseke 6.6 Haavoittuvuuksien koordinoidun julkistamisen politiikka
Jos täyttä korjausta ei voida toimittaa välittömästi, korvaavat hallintakeinot, käytöstä poistettu toiminnallisuus, tehostettu seuranta tai asiakkaalle annettavat konfigurointiohjeet voivat olla tilapäisesti hyväksyttäviä, mutta päätös on dokumentoitava ja siitä on viestittävä.
Käytännön Clarysec-tarkistuslista tukijaksovalmiuteen
Käytä tätä tarkistuslistaa ennen minkään CRA:n tietoturvatukijaksositoumuksen julkaisemista tai uusimista.
- Onko tuote ja versio lueteltu tukijaksorekisterissä?
- Onko tuen päättymispäivä hyväksytty tuotehallinnan, tietoturvan ja vastuullisen johdon toimesta?
- Onko lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset ajurit kartoitettu vaatimustenmukaisuusrekisteriin?
- Sisältyykö tukijakson riskiskenaario riskirekisteriin?
- Onko hallintakeinot kartoitettu soveltuvuuslausuntoon, mukaan lukien 5.31, 8.8 ja 8.25 soveltuvin osin?
- Onko kriittiset toimittajat ja komponentit kartoitettu toimittajariippuvuusrekisteriin?
- Onko olemassa näyttöä siitä, että komponentit voidaan paikata tai korvata tukijakson aikana?
- Onko haavoittuvuusilmoitusten vastaanoton, luokittelun, korjaamisen ja julkistamisen vastuut määritelty?
- Ovatko kriittisten korjauspäivitysten palvelutasot yhdenmukaisia politiikan ja asiakassopimusten kanssa?
- Säilytetäänkö korjauspäivityslokit, julkaisutallenteet ja haavoittuvuuspäätökset?
- Kattavatko haavoittuvuuksien arvioinnin näytöt henkilötietojärjestelmät, joissa henkilötietoja käsitellään?
- Ovatko asiakasilmoitukset, tukilausumat ja sopimusehdot yhdenmukaisia?
- Onko olemassa prosessi tuen pidentämiseen, lyhentämiseen tai päättämiseen riskihyväksynnällä?
- Saavatko johdon katselmoinnit syötteinä tukijakson riskit, toimittajat, haavoittuvuudet ja poikkeamat?
- Voidaanko todentava aineisto tuottaa 48 tunnin kuluessa asiakasauditointia tai viranomaistiedustelua varten?
Enterprise PIMS-seurannan, auditoinnin ja parantamisen politiikka PIMS-seurannan, auditoinnin ja parantamisen politiikka vahvistaa tietosuojaohjelmien johdon katselmointikurinalaisuutta:
“[Molemmat] Ylimmän johdon ON katselmoitava PIMS:n vaatimustenvastaisuus, korjaavat toimenpiteet, seurantatulokset, auditointitulokset, tietosuojariski, toimittajavarmennus ja sidosryhmämuutosten syötteet REG12:ssa jokaisen johdon katselmoinnin aikana.”
Lähde: PIMS-seurannan, auditoinnin ja parantamisen politiikka, PIMS:n johdon katselmointi, lauseke 4.3.5 PIMS-seurannan, auditoinnin ja parantamisen politiikka
Tietoturvatukijaksojen hallinnassa saman katselmointirytmin on koskettava koko ISMS:ää: haavoittuvuuksien, korjauspäivitysten suorituskyvyn, toimittajavarmennuksen, asiakassitoumusten, poikkeamien, tukipoikkeusten ja korjaavien toimenpiteiden on syötettävä johdon katselmointia.
Tee tietoturvatukijaksosta puolustettava
EU Cyber Resilience Act muuttaa tuoteturvallisuuden ajattelutapaa. Se ohjaa valmistajia ja ohjelmistotoimittajia ajattelemaan julkaisupäivää pidemmälle. Tietoturvatukijaksosta tulee elinkaarilupaus, joka on suunniteltava, hallittava, seurattava ja todennettava.
Tietoturvajohtajille opetus on selvä: älä jätä tukijaksoa pelkkään tuotemarkkinointiin. Vaatimustenmukaisuuspäälliköille: älä rakenna erillistä CRA-näyttösiiloa. Auditoijille: testatkaa, ovatko tukisitoumukset jäljitettävissä riskeihin, hallintakeinoihin, toimittajiin, poikkeamiin ja dokumentoituihin hyväksyntöihin. Liiketoimintavastaaville: muistakaa, että uskottava tukijakso voi olla markkinaetu erityisesti myytäessä NIS2-säännellyille sektoreille, DORA:n piirissä oleville finanssialan toimijoille ja tietosuojaherkille asiakkaille.
Clarysec auttaa organisaatioita viemään tämän käytäntöön seuraavien avulla:
- Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ISMS-jäljitettävyyden, dokumentoidun tiedon, SoA-kartoituksen ja auditointivalmiuden rakentamiseen
- Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022 -hallintakeinojen kartoittamiseen NIS2:een, DORA:an, GDPR:ään, NIST CSF 2.0:aan ja auditointiodotuksiin
- Enterprise- ja pk-yrityspolitiikkapaketit haavoittuvuuksien hallintaan, turvalliseen kehittämiseen, lakisääteiseen vaatimustenmukaisuuteen, toimittajariippuvuuksiin, tietosuojan todentavaan aineistoon ja tietoturvapoikkeamiin reagointiin
- Käytännön rekisterit ja todentavan aineiston työnkulut, jotka muuttavat tukijaksolupaukset auditoitavaksi hallinnaksi
Seuraava askel on yksinkertainen: valitse yksi lippulaivatuotteen versio ja rakenna sille tietoturvatukijakson näyttöaineisto. Kartoita velvoite, hyväksy tukijakso, testaa haavoittuvuusprosessi, validoi toimittajariippuvuudet, vahvista asiakasviestintä ja säilytä tallenteet.
Jos pystyt puolustamaan yhden tuotteen, voit skaalata mallin. Jos et pysty puolustamaan yhtä tuotetta, puute ei ole dokumentaatiossa. Se on hallinnassa.
Lataa Zenith Blueprint, käytä Zenith Controls -opasta todentavan aineistosi kartoittamiseen tai pyydä Clarysec-valmiusarviointi, jotta CRA:n tietoturvatukijaksot voidaan muuttaa auditointivalmiiksi ISO 27001 -hallinnaksi.
About the Author
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