Skannauksista auditointinäytöksi: ISO 27001:2022, NIS2, DORA

On maanantai kello 08.16. Kriittinen etäkoodin suorittamisen haavoittuvuus on juuri julkaistu internetiin avautuvan sovelluspalvelimen hallintanäkymässä. Infrastruktuuritiimi kertoo, että toimittajan korjauspäivitys on saatavilla. Sovellusomistaja varoittaa, että palvelin tukee liikevaihdon kannalta kriittistä asiakastyönkulkua. Lakitiimi kysyy, voisiko haavoittuvuuden hyväksikäyttö käynnistää NIS2-, DORA- tai GDPR-raportointivelvoitteen. Tietoturvajohtaja Maria avaa auditointikalenterin ja näkee varsinaisen ongelman: ISO 27001:2022 -valvonta-auditointi alkaa ensi viikolla, NIS2-valmiuskatselmointi on jo käynnissä, ja merkittävä fintech-asiakas on pyytänyt DORA-näyttöä.

Skanneri näyttää punaista. Tikettitaulu näyttää toimintaa. Taulukkolaskenta näyttää tehdyn työn. Mikään näistä ei kuitenkaan automaattisesti osoita kontrollin toimivuutta.

Tämä on aukko, jonka monet organisaatiot havaitsevat liian myöhään. Haavoittuvuusskannaus ei ole sama asia kuin valmius osoittaa haavoittuvuuksien hallinta auditoinnissa. Skannaus kertoo, että jokin voi olla pielessä. Auditointinäyttö osoittaa, että organisaatio tiesi, mitä sillä oli, arvioi riskin, osoitti omistajuuden, toimi politiikan mukaisesti, hallitsi muutoksen, dokumentoi poikkeukset, varmisti tulokset ja katselmoi lopputuloksen.

ISO/IEC 27001:2022-, NIS2- ja DORA-viitekehyksissä tämä näyttöketju on yhtä tärkeä kuin tekninen korjaus. Skanneri aloittaa tarinan. Omaisuusluettelo, haavoittuvuusrekisteri, tiketti, riskipäätös, muutostallenne, korjauspäivitysloki, validointinäyttö, poikkeuksen hyväksyntä ja johdon katselmointi täydentävät sen.

Clarysecin lähestymistapa on yksinkertainen: haavoittuvuuksien hallintaa ei tule käsitellä kuukausittaisena teknisenä rituaalina. Sitä tulee käsitellä hallittuna näyttötyönkulkuna.

Miksi skannausraportit eivät riitä auditointinäytöksi

Haavoittuvuusskannaus on tiettyyn ajanhetkeen sidottu tekninen havainto. Se voi tunnistaa CVE:n, puuttuvan korjauspäivityksen, tukemattoman kirjaston, altistuneen palvelun tai heikon konfiguraation. Tämä on hyödyllistä, mutta ei riittävää.

Auditoija kysyy toisenlaisia kysymyksiä:

• Kuuluiko kyseinen omaisuuserä soveltamisalaan?
• Kuka omistaa omaisuuserän ja liiketoimintapalvelun?
• Arvioitiinko haavoittuvuus altistumisen, hyväksikäytettävyyden, liiketoimintavaikutuksen ja tietojen arkaluonteisuuden perusteella?
• Toteutettiinko korjaavat toimenpiteet määritetyssä määräajassa?
• Jos korjaavia toimenpiteitä viivästettiin, kuka hyväksyi jäännösriskin?
• Asennettiinko korjauspäivitys hallitun muutoksenhallinnan kautta?
• Varmennettiinko korjaus uudelleenskannauksella tai teknisellä validoinnilla?
• Säilytettiinkö näyttö ja katselmoiko johto sen?

Skannerivientien kansio vastaa näihin kysymyksiin harvoin. ISO 27001:2022 -auditoinnissa auditoija testaa, toimiiko ISMS suunnitellulla tavalla. NIS2:n mukaan hallintoelimet hyväksyvät kyberturvallisuuden riskienhallintatoimenpiteet ja valvovat niitä. DORA edellyttää finanssialan toimijoilta dokumentoitua ICT-riskienhallinnan viitekehystä, poikkeaman elinkaarta, häiriönsietokyvyn testausta ja ICT-toimittajariskien hallintaa. GDPR:n näkökulmasta kysymys on siitä, suojasivatko asianmukaiset tekniset ja organisatoriset toimenpiteet henkilötietoja ja voidaanko osoitusvelvollisuus todentaa.

ISO/IEC 27001:2022 kohdat 4.1–4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä, vaatimuksensa ja ISMS:n soveltamisalan. Haavoittuvuuksien ja korjauspäivitysten hallintaa ei voida suunnitella irrallaan muusta toiminnasta. Sen on heijastettava asiakassopimuksia, valvontaviranomaisia, pilviriippuvuuksia, ulkoistettuja ICT-palveluja, tietosuojavelvoitteita ja kriittisiä palveluja.

ISO/IEC 27001:2022 kohdat 6.1.1–6.1.3 edellyttävät riskien arviointia, riskien käsittelyä, hallintakeinojen valintaa, soveltuvuuslausuntoa sekä riskinomistajan hyväksyntää jäännösriskille. Tämä tarkoittaa, että haavoittuvuusnäytön tulee liittyä riskirekisteriin, riskienkäsittelysuunnitelmaan ja SoA:han.

ISO/IEC 27005:2022 vahvistaa tätä mallia ohjaamalla organisaatioita kokoamaan liitteestä A, toimialakohtaisista velvoitteista, säädöksistä, sopimuksista, sisäisistä säännöistä ja olemassa olevista kontrolleista tulevat vaatimukset riskien arvioinnin perustaksi. Se korostaa myös todennäköisyyttä, seurausta, lakisääteisiä velvoitteita, toimittajasuhteita, tietosuojavaikutuksia ja kolmannen osapuolen vaikutuksia koskevia kriteerejä. Käytännössä haavoittuvuus ei ole pelkkä CVSS-luku. Se on riskitapahtuma, joka liittyy omaisuuseriin, velvoitteisiin, sidosryhmiin ja liiketoiminnan seurauksiin.

Korjauspäivitysnäyttöön kohdistuva sääntelypaine

Nykyaikainen kyberturvallisuussääntely suhtautuu aiempaa vähemmän sallivasti epämuodolliseen paikkaukseen.

NIS2 koskee monia keskisuuria ja suuria toimijoita erittäin kriittisillä ja kriittisillä toimialoilla, ja se voi ulottua myös tiettyihin toimijoihin koosta riippumatta. Sen soveltamisalaan kuuluvat digitaalisen infrastruktuurin tarjoajat, kuten pilvipalvelut, datakeskuspalvelut, sisällönjakeluverkot, julkisten sähköisten viestintäpalvelujen tarjoajat, luottamuspalvelut, DNS- ja TLD-palvelut sekä ICT-palvelunhallinnan tarjoajat, kuten hallinnoidut palveluntarjoajat ja hallinnoidut tietoturvapalveluntarjoajat. Se kattaa myös tärkeät digitaaliset palveluntarjoajat, kuten verkossa toimivat markkinapaikat, hakukoneet ja sosiaalisen verkostoitumisen alustat.

NIS2 Article 20 tekee kyberturvallisuudesta hallintoelimen vastuun. Article 21 edellyttää asianmukaisia ja oikeasuhteisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, kuten riskianalyysiä, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, toimitusketjun tietoturvaa, turvallista hankintaa, turvallista kehittämistä, turvallista ylläpitoa, haavoittuvuuksien käsittelyä ja julkistamista, vaikuttavuuden arviointia, kyberhygieniaa, pääsynhallintaa, omaisuudenhallintaa ja todennusta. Article 23 luo vaiheistetun merkittävistä poikkeamista ilmoittamisen prosessin, johon kuuluvat ennakkovaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja tarvittaessa loppuraportti yhden kuukauden kuluessa.

DORA muodostaa finanssialan toimijoille suoraan sovellettavan digitaalisen operatiivisen häiriönsietokyvyn sääntökokonaisuuden 17. tammikuuta 2025 alkaen. Se kattaa ICT-riskien hallinnan, merkittävistä ICT-poikkeamista raportoinnin, operatiivisen häiriönsietokyvyn testauksen, kyberuhkatiedustelun jakamisen, ICT-toimittajariskien hallinnan ja kriittisten ICT-kolmansien osapuolten palveluntarjoajien valvonnan. Articles 5 and 6 asettavat ICT-riskien hallinnoinnin hallintoelimen vastuulle ja edellyttävät dokumentoitua, integroitua ja säännöllisesti katselmoitua ICT-riskienhallinnan viitekehystä. Article 8 vahvistaa tarpeen tunnistaa ICT:n tukemat liiketoimintatoiminnot, tietovarat, ICT-omaisuuserät ja riippuvuudet. Articles 17 to 20 edellyttävät ICT:hen liittyvien poikkeamien havaitsemista, kirjaamista, luokittelua, eskalointia, raportointia, viestintää, korjaavia toimenpiteitä ja oppimista. Articles 28 to 30 edellyttävät, että ICT-toimittajariskiä hallitaan rekisterien, huolellisuuden, sopimusperusteisten suojatoimien, auditointioikeuksien, exit-suunnittelun ja valvonnan avulla.

DORA:n soveltamisalaan kuuluvien finanssialan toimijoiden osalta DORA yleensä korvaa vastaavat NIS2-riskienhallinta- ja raportointivelvoitteet. NIS2 on kuitenkin edelleen merkityksellinen ekosysteemikoordinaation ja DORA:n ulkopuolisten toimijoiden kannalta. Finanssialan asiakkaita palveleville SaaS-, MSP- ja MSSP-palveluntarjoajille käytännön tilanne on suoraviivainen: asiakkaat voivat edellyttää haavoittuvuusnäyttöä täyttääkseen omat DORA-velvoitteensa.

GDPR lisää vielä yhden kerroksen. Articles 2 and 3 voivat koskea EU:hun sijoittautuneita organisaatioita sekä EU:n ulkopuolisia organisaatioita, jotka tarjoavat tavaroita tai palveluja EU:ssa oleville henkilöille tai seuraavat heidän käyttäytymistään. Article 5 edellyttää henkilötietojen suojaamista ja vaatimustenmukaisuuden osoitusvelvollisuutta. Article 4 määrittelee henkilötietojen tietoturvaloukkauksen tietoturvapoikkeamaksi, joka johtaa henkilötietojen vahingossa tapahtuvaan tai lainvastaiseen häviämiseen, tuhoutumiseen, muuttumiseen, luvattomaan luovuttamiseen tai henkilötietoihin pääsyyn. Viivästynyt korjauspäivitys tietokannassa, identiteettialustalla tai asiakasportaalissa voi muodostua tietosuojaan liittyväksi osoitusvelvollisuuskysymykseksi.

Politiikasta näyttöön

Ensimmäinen vaihe on sääntöjen määrittely. Vahva haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka ei ole pelkkä auditointiasiakirja. Se on kontrollin operatiivinen perusta.

Yritysympäristöissä Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka kytkee teknisen paikkauksen nimenomaisesti useisiin vaatimustenmukaisuusvaatimuksiin:

Tämä politiikka tukee ISO/IEC 27001 liite A:n hallintakeino 8.8:n ja ISO/IEC 27002 -ohjeistuksen mukaista vaatimustenmukaisuutta sekä käsittelee DORA Article 8-, NIS2 Article 21-, GDPR Article 32- ja COBIT 2019 DSS- ja APO-alueiden sääntelyvaatimuksia.

Kohdasta “Tarkoitus”.

Sama politiikka asettaa hallinnointiodotuksen keskeiselle näyttöartefaktille:

Tietoturvaoperaatiotiimin on ylläpidettävä keskitettyä haavoittuvuuksien hallintarekisteriä, ja tietoturvajohtajan tai delegoidun toimivaltaisen henkilön on katselmoitava se kuukausittain.

Kohdasta “Hallinnointivaatimukset”, politiikkalauseke 5.1.

Se määrittää myös skannausrytmin:

Kaikki järjestelmät on skannattava vähintään kuukausittain; korkean riskin tai ulkoisesti altistuvat omaisuuserät on skannattava viikoittain.

Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.1.

Lisäksi se estää kiireellistä paikkausta muuttumasta hallitsemattomaksi tekniseksi toiminnaksi:

Kaikki korjaavat toimenpiteet on koordinoitava muutoksenhallintaprosessin kautta (P5 - Muutoksenhallintapolitiikka mukaisesti), jotta vakaus ja auditointijäljen säilyminen varmistetaan.

Kohdasta “Hallinnointivaatimukset”, politiikkalauseke 5.5.

Pk-yrityksissä samat näyttöperiaatteet voidaan toteuttaa yksinkertaisemmin. Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka pk-yrityksille toteaa:

Ylläpidä täsmällisiä tallenteita asennetuista korjauspäivityksistä, avoimista havainnoista ja poikkeuksista auditointivalmiuden varmistamiseksi

Kohdasta “Tavoitteet”, politiikkalauseke 3.4.

Se määrittää tämän jälkeen korjauspäivityslokin auditointinäytöksi:

Korjauspäivityslokia on ylläpidettävä ja katselmoitava auditointien ja tietoturvapoikkeamiin reagointitoimien aikana

Kohdasta “Hallinnointivaatimukset”, politiikkalauseke 5.4.1.

Ja se täsmentää vähimmäissisällön:

Lokien on sisällettävä laitteen nimi, asennettu päivitys, paikkauspäivä ja mahdollisen viivästyksen syy

Kohdasta “Hallinnointivaatimukset”, politiikkalauseke 5.4.2.

Kiireellisen internetiin avautuvan altistuksen osalta pk-yrityksen politiikka asettaa mitattavan vaatimuksen:

Kriittiset korjauspäivitykset on asennettava 3 päivän kuluessa julkaisusta, erityisesti internetiin avautuvissa järjestelmissä

Lähde: Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka pk-yrityksille, kohta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.1.

Nämä lausekkeet muuttavat teknisen työn näytöksi. Politiikka määrittää odotukset. Rekisteri kirjaa havainnot. Tiketti osoittaa työn. Muutostallenne hallitsee käyttöönottoa. Korjauspäivitysloki todistaa toimenpiteen. Riskirekisteri tallentaa poikkeukset. Katselmuspöytäkirjat osoittavat valvonnan.

Clarysecin näyttö ensin -malli

Clarysecin näyttö ensin -malli perustuu yhteen periaatteeseen: jokaisen haavoittuvuushavainnon on oltava jäljitettävissä havaitsemisesta päätökseen.

Zenith Blueprint: auditoijan 30 vaiheen tiekartta käsittelee Kontrollit käytännössä -vaiheen kohdassa Vaihe 19: Teknologiset hallintakeinot I haavoittuvuuksien hallintaa toistettavana kontrollina eikä teoreettisena vaatimuksena:

Haavoittuvuuksien hallinta on yksi modernin kyberhygienian kriittisimmistä osa-alueista. Vaikka palomuurit ja virustorjuntatyökalut tarjoavat suojaa, niiden vaikutus voi heikentyä, jos paikkaamattomat järjestelmät tai virheellisesti määritetyt palvelut jäävät altistuneiksi.

Sama vaihe selittää, että organisaatioiden tulisi käyttää säännöllisiä paikkausaikatauluja, haavoittuvuusskannereita, luokittelua ja priorisointia, työn osoittamista, korjaavien toimenpiteiden seurantaa, korvaavia kontrolleja ja jäännösriskin hyväksyntää. Tärkeintä on, että se kehystää auditointiajattelun oikein:

Kontrollissa ei ole kyse täydellisyydestä, vaan organisoidusta, läpinäkyvästä ja vastuutetusta prosessista.

Auditoijille tällä erolla on merkitystä. Kypsällä organisaatiolla voi olla avoimia haavoittuvuuksia ja silti se voi osoittaa kontrollin, jos sillä on riskiperusteinen priorisointi, dokumentoitu omistajuus, hyväksytyt poikkeukset, korvaavat kontrollit ja varmennettu korjaaminen.

Zenith Blueprint varoittaa myös, että auditoijat tarkastavat tämän alueen perusteellisesti:

Tämä on auditoijille korkean prioriteetin kontrolli, ja he yleensä perehtyvät siihen syvällisesti. Varaudu kysymyksiin siitä, kuinka usein järjestelmiä paikataan, mitä prosessia noudatatte zero-day-haavoittuvuuden julkistamisen yhteydessä ja mitkä järjestelmät ovat vaikeimpia paikata.

Siksi tietoturvajohtajan ei tule mennä auditointiin pelkän skannerin hallintanäkymän kanssa. Näyttöpaketin on osoitettava hallinnointi, prosessi, toteutus, varmennus ja parantaminen.

ISO 27002 -hallintakeinojen kartoitus auditointinäyttöön

Zenith Controls: ristiin vaatimustenmukaisuuden opas toimii ristiin vaatimustenmukaisuuden kompassina kartoittamalla ISO/IEC 27002:2022 -hallintakeinoja ja osoittamalla, miten ne liittyvät auditointiodotuksiin. Haavoittuvuuksien ja korjauspäivitysten hallinnassa kolme ISO/IEC 27002:2022 -hallintakeinoa muodostaa operatiivisen kolmion.

ISO/IEC 27002:2022 hallintakeino 8.8, teknisten haavoittuvuuksien hallinta, on keskeinen hallintakeino. Se on ennaltaehkäisevä, tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa tunnistamisen ja suojaamisen kyberturvallisuuskäsitteiden kanssa ja liittyy uhkien ja haavoittuvuuksien hallintaan.

ISO/IEC 27002:2022 hallintakeino 8.32, muutoksenhallinta, on myös ennaltaehkäisevä. Se kytkee paikkauksen hallittuun käyttöönottoon, testaukseen, hyväksyntään, palautussuunnitelmaan ja auditoitavuuteen.

ISO/IEC 27002:2022 hallintakeino 5.36, tietoturvapolitiikkojen, sääntöjen ja standardien noudattaminen, varmistaa, ettei prosessi ole valinnainen tai yksittäisten henkilöiden sankarisuorituksista riippuvainen. Se kytkee haavoittuvuuksien hallinnan politiikan noudattamiseen, varmentamiseen ja valvontaan.

Tämä kartoitus ehkäisee yleisen auditointiepäonnistumisen. Tietoturva sanoo: ”Me paikkasimme sen.” IT-operaatiot sanovat: ”Me otimme sen käyttöön.” Vaatimustenmukaisuus sanoo: ”Emme pysty todistamaan tapahtumaketjua.” Kartoitettu näyttöketju antaa kaikille kolmelle tiimille saman tarinan.

Auditoijien odottama näyttöketju

Puolustettavissa oleva haavoittuvuuksien hallinnan näyttöketju sisältää seitsemän vaihetta.

Käytännön ero ”me teemme skannauksia” ja ”olemme valmiita auditointia varten” välillä on jatkuvuus. Jos haavoittuvuutta ei voida jäljittää löytämisestä sulkemiseen, kontrolli on heikko. Jos poikkeuksia on, mutta kukaan ei ole hyväksynyt niitä, prosessi on heikko. Jos korjauspäivitykset ohittavat muutoksenhallinnan, auditointijälki on heikko. Jos kriittiset haavoittuvuudet jäävät avoimiksi ilman korvaavia kontrolleja, hallinnointi on heikko.

Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka tukee automaatiota osana tätä mallia:

Automaattisia työkaluja on otettava käyttöön konfiguraation vaatimustenmukaisuuden, haavoittuvuuksien hallinnan, korjauspäivitysten tilan ja etuoikeutettujen käyttöoikeuksien seuraamiseksi.

Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.4.1.

Pk-yrityksille Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille määrittää teknisten kontrollien varmennuksen käytännönläheisesti:

Teknisten kontrollien varmennus (esim. varmuuskopioinnin tila, pääsynhallinnan konfiguraatio, korjauspäivitystallenteet)

Kohdasta “Politiikan toteutusvaatimukset”, politiikkalauseke 6.1.1.2.

Pienet organisaatiot eivät tarvitse yritystason työkalustoa ollakseen valmiita auditointia varten. Ne tarvitsevat yhdenmukaista näyttöä. Kevyt rekisteri, tikettitaulu, korjauspäivitysloki ja kuukausittainen katselmointi voivat riittää, jos ne ovat täydellisiä, ajan tasalla ja riskisidonnaisia.

Esimerkki: yksi kriittinen havainto täysin auditointivalmiina

Marian viikoittainen ulkoinen skannaus tunnistaa CVE-2026-12345-haavoittuvuuden internetiin avautuvassa maksuliikenteen API-yhdyskäytävässä. Skanneri luokittelee sen kriittiseksi. Palvelu käsittelee asiakkaan identiteetti- ja tapahtumametatietoja, joten GDPR- ja DORA-vaikutukset ovat mahdollisia. Yhdyskäytävän omistaa Platform Engineering, mutta korjauspäivitys edellyttää lyhyttä käyttökatkoa.

Tältä auditointivalmis työnkulku näyttää.

1. Luo haavoittuvuusrekisterimerkintä

Tietoturvatiimi kirjaa havainnon keskitettyyn rekisteriin:

• Havaintotunnus: VULN-2026-0142
• Lähde: viikoittainen ulkoinen skannaus
• Löytämisen päivämäärä ja aika
• Omaisuuserä: api-gw-prod-01
• Omistaja: Platform Engineering
• Altistuminen: internetiin avautuva
• Tietokonteksti: asiakkaan identiteetti- ja tapahtumametatiedot
• Vakavuus: kriittinen
• SLA: 72 tuntia tai politiikan perusteella tiukempi
• Tiketti: SEC-4821
• Muutostallenne: CHG-10988
• Tila: korjaaminen suunniteltu

2. Luokittele ja priorisoi liiketoiminta- ja sääntelykontekstin perusteella

Tiimi tarkistaa hyväksikäyttömenetelmän saatavuuden, hyökkäyspinnan, todentamisvaatimukset, liiketoimintavaikutuksen ja tietojen arkaluonteisuuden. Koska järjestelmä on internetiin avautuva ja tukee asiakastyönkulkuja, haavoittuvuus pysyy kriittisenä. Riskinomistaja on Head of Platform, ja tietoturvajohtajalle ilmoitetaan mahdollisten NIS2-, DORA- ja GDPR-vaikutusten vuoksi.

ISO/IEC 27005:2022 kohdat 7.1–7.4 tukevat riskien tunnistamista, omistajuutta, seurausta, todennäköisyyttä ja priorisointia. Kohdat 8.2–8.6 tukevat käsittelyvaihtoehdon valintaa, hallintakeinon määrittämistä, SoA-kytkentää, käsittelysuunnittelua ja jäännösriskin hyväksyntää.

3. Avaa hallittu hätämuutos

Korjauspäivitys aikataulutetaan samalle illalle. Muutostallenne sisältää toimittajaviitteen, vaikutuksen alaiset palvelut, testisuunnitelman, palautussuunnitelman, huoltoikkunan, asiakasviestintää koskevan päätöksen, hyväksynnät ja käyttöönoton jälkeisen validointivaatimuksen.

Tämä tukee suoraan ISO/IEC 27002:2022 hallintakeino 8.32:ta ja yrityspolitiikan vaatimusta koordinoida korjaavat toimenpiteet muutoksenhallinnan kautta.

4. Asenna korjauspäivitys ja päivitä korjauspäivitysloki

Korjauspäivityslokiin kirjataan laitteen nimi, asennettu päivitys, paikkauspäivä ja mahdollinen viivästyksen syy. Jos paikkausta olisi viivästetty, tiimi dokumentoisi korvaavat kontrollit, kuten web-sovelluksen palomuurisäännöt, tilapäiset pääsyrajoitukset, lisätyn lokituksen, eristämisen tai tehostetun valvonnan.

5. Varmenna ja sulje

Tietoturva skannaa API-yhdyskäytävän uudelleen. Haavoittuvuus ei enää näy. Tiketti päivitetään puhtaalla skannausnäytöllä, korjauspäivityksen versiolla, käyttöönoton aikaleimalla ja muutostallenteen linkillä. Haavoittuvuusrekisterin tilaksi muutetaan ”Suljettu, varmennettu”.

6. Katselmoi raportointivaikutus

Jos hyväksikäyttöä tai palveluhäiriötä ei tapahtunut, NIS2- tai DORA-poikkeamaraportointi ei välttämättä käynnisty. Jos vaarantumisen indikaattoreita löytyy, poikkeamaprosessin on luokiteltava vaikutus ja eskalointi. NIS2:n mukaan merkittävä poikkeama voi edellyttää ennakkovaroitusta ja vaiheistettua raportointia. DORA:n mukaan merkittävä ICT:hen liittyvä poikkeama edellyttää luokittelua ja raportointia sovellettavan toimivaltaisen viranomaisen prosessin kautta.

7. Vie opit johdon katselmointiin

Kuukauden lopussa tietoturvajohtajan katselmoinnissa todetaan, että haavoittuvuus havaittiin viikoittaisella ulkoisella skannauksella, korjattiin SLA:n mukaisesti, varmennettiin uudelleenskannauksella ja suljettiin ilman poikkeamaa. Jos vastaavat ongelmat toistuvat, riskienkäsittelysuunnitelmaan voidaan lisätä turvalliset peruskonfiguraatiot, automatisoitu korjauspäivitysten käyttöönotto, toimittajaeskalointi tai sovelluksen modernisointi.

Kun auditoija kysyy CVE-2026-12345:stä, Maria voi esittää kuratoidun paketin sähköpostien ja kuvakaappausten sijaan.

Tämä on auditointivalmista. Ei siksi, että organisaatiolla ei ollut haavoittuvuuksia, vaan siksi, että sillä oli kontrolli.

Yksi näyttökokonaisuus, useita velvoitteita

Hyvin suunniteltu haavoittuvuuksien ja korjauspäivitysten hallintaohjelma voi täyttää useiden viitekehysten vaatimuksia ilman päällekkäistä työtä.

ISO 27001:2022 -standardin osalta näyttö tukee riskiperusteista ISMS:ää, liite A:n hallintakeinojen toteutusta, soveltuvuuslausuntoa, riskienkäsittelysuunnitelmia, sisäistä tarkastusta ja jatkuvaa parantamista. Jos ISO/IEC 27002:2022 hallintakeino 8.8 on SoA:ssa sovellettava, organisaation tulee pystyä osoittamaan oikeudellinen, sääntelyyn liittyvä, riskiin perustuva tai liiketoiminnallinen perustelu. Tämä perustelu sisältää usein NIS2 Article 21:n, DORA:n ICT-riskivelvoitteet, GDPR:n osoitusvelvollisuuden, asiakassopimukset ja operatiivisen häiriönsietokyvyn tarpeet.

NIS2:n osalta sama näyttö auttaa osoittamaan Article 21 -toimenpiteet, kuten riskianalyysin, haavoittuvuuksien käsittelyn, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun tietoturvan, kyberhygienian, pääsynhallinnan ja vaikuttavuuden arvioinnin. Article 20 osoitetaan tietoturvajohtajan katselmoinnilla, hallitukselle raportoinnilla, johdon hyväksynnällä ja kyberturvallisuuskoulutuksella. Article 23 tulee merkitykselliseksi, jos hyväksikäyttö aiheuttaa tai voi aiheuttaa vakavan operatiivisen häiriön, taloudellisen menetyksen tai haittaa muille.

DORA:n osalta haavoittuvuus- ja korjauspäivitysnäyttö tukee ICT-riskienhallinnan viitekehystä, hallintoelimen valvontaa, häiriönsietokyvyn strategiaa, poikkeamien havaitsemista ja luokittelua, häiriönsietokyvyn testausta ja ICT-kolmansien osapuolten valvontaa. Kun ICT-palveluntarjoaja ylläpitää tai hallinnoi vaikutuksen alaista järjestelmää, Articles 28 to 30 edellyttävät huolellisuutta, sopimusperusteisia suojatoimia, auditointioikeuksia, poikkeama-apua ja exit-näkökohtia.

GDPR:n osalta sama näyttö tukee Article 5:n mukaista osoitusvelvollisuutta ja Article 32:ssa edellytettyä tietoturvan tasoa. Jos haavoittuvuus johtaa luvattomaan pääsyyn henkilötietoihin, niiden muuttamiseen, häviämiseen tai luovuttamiseen, haavoittuvuuden aikajana, korjauspäivitystallenteet, valvontalokit ja loukkauksen arviointimuistiinpanot ovat välttämättömiä.

COBIT 2019- ja ISACA-tyyppisessä varmennuksessa haavoittuvuuksien hallintaa arvioidaan operatiivisen tietoturvan, kontrollien seurannan, muutosten mahdollistamisen ja hallinnointivastuun kautta. Zenith Blueprint -oppaan ristiin vaatimustenmukaisuuden viitteet nostavat esiin COBIT 2019 DSS05.04:n ja BAI09.02:n sekä ITAF-varmennusodotukset haavoittuvuuksien hallinnalle, paikkaukselle ja turvalliselle muutoksenhallinnalle.

Tukevat ISO-standardit vahvistavat toimintamallia. ISO/IEC 27005:2022 tukee riskien arviointia ja käsittelyä. ISO/IEC 27035:2023 tukee tietoturvapoikkeamiin reagointia, kun haavoittuvuuksia hyödynnetään. ISO/IEC 30111 tukee haavoittuvuuksien käsittelyprosesseja. ISO/IEC 29147 tukee haavoittuvuuksien julkistamista ja tiedotteita. ISO/IEC 27017 tukee pilvipalvelujen haavoittuvuuksien hallintaa. ISO 22301 tukee jatkuvuussuunnittelua, kun tekniset haavoittuvuudet voivat häiritä liiketoimintapalveluja.

Miten eri auditoijat testaavat samaa prosessia

Eri arvioijat käyttävät eri näkökulmia. Näyttö voi olla sama, mutta kysymykset muuttuvat.

Politiikka kertoo, mitä pitäisi tapahtua. Operatiivinen näyttö osoittaa, mitä tapahtui. Katselmointitallenteet osoittavat, että johto tiesi, haastoi ja toimi.

Yleiset syyt, joiden vuoksi korjauspäivitysten hallinta epäonnistuu auditoinnissa

Useimmat havainnot eivät johdu skannerin puuttumisesta. Ne johtuvat katkenneesta jäljitettävyydestä.

Omaisuusluettelo on puutteellinen.
Jos skanneri löytää omaisuuseriä, jotka puuttuvat CMDB:stä tai omaisuusrekisteristä, omistajuutta ja liiketoimintavaikutusta ei voida arvioida luotettavasti. Tämä heikentää ISO 27001:2022 -soveltamisalaa, riskien arviointia ja käsittelyä.

Haavoittuvuuksia seurataan vain skannerissa.
Skannerin hallintanäkymät eivät ole hallinnointirekistereitä. Niistä puuttuvat usein riskinomistajan hyväksyntä, poikkeuksen perustelu, muutosviitteet ja liiketoimintakonteksti.

Kriittisistä havainnoista puuttuu SLA-näyttö.
Politiikka voi sanoa, että kriittiset haavoittuvuudet korjataan kolmen päivän kuluessa. Auditointikysymys on, todistavatko tallenteet, että näin tapahtui.

Poikkeukset ovat epämuodollisia.
Legacy-järjestelmiä, käyttökatkorajoitteita ja toimittajaviiveitä esiintyy. Mutta ”emme voineet paikata sitä” on muutettava dokumentoiduksi poikkeukseksi, jossa on korvaavat kontrollit, päättymispäivä ja jäännösriskin hyväksyntä.

Hätäpaikkaus ohittaa muutoksenhallinnan.
Hätämuutokset ovat edelleen muutoksia. Jos hyväksyntää, testausta tai palautusnäyttöä ei ole, auditoijat voivat päätellä, että korjaaminen loi operatiivisen riskin.

Kolmannen osapuolen järjestelmät ovat näkymättömiä.
NIS2:n ja DORA:n mukaan toimittaja- ja ICT-kolmannen osapuolen riskit ovat keskeisiä. Jos palveluntarjoaja paikkaa alustan, tarvitset silti näytön, sopimusperusteiset oikeudet, palveluraportoinnin ja eskalointireitit.

Kukaan ei katselmoi trendejä.
Toistuvat haavoittuvuudet voivat viitata heikkoon konfiguraationhallintaan, puutteellisiin turvallisen kehittämisen käytäntöihin, tukemattomiin omaisuuseriin tai toimittajan epäonnistumiseen. Kuukausittainen katselmointi muuntaa teknisen datan hallinnointitoimenpiteiksi.

Clarysecin haavoittuvuuksien auditointipaketti

Tulevaa ISO 27001:2022-, NIS2- tai DORA-valmiuskatselmointia varten Clarysec auttaa organisaatioita kokoamaan haavoittuvuuksien ja korjauspäivitysten hallinnan auditointipaketin, joka sisältää seuraavat:

• Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, mukaan lukien soveltamisala, roolit, skannausrytmi, korjauspäivitysten SLA:t ja poikkeussäännöt
• Omaisuusluettelo-ote, joka näyttää soveltamisalaan kuuluvat järjestelmät, omistajat, kriittisyyden ja altistumisen
• Viimeisimmät sisäiset ja ulkoiset haavoittuvuusskannausraportit
• Keskitetty haavoittuvuuksien hallintarekisteri, jossa ovat avoimet, suljetut ja poikkeuksena käsitellyt kohteet
• Korjauspäivityslokit, jotka näyttävät laitteen, päivityksen, paikkauspäivän ja viivästysten syyt
• Muutostallenteet otokseen valituista kriittisistä ja korkean vakavuuden haavoittuvuuksista
• Näyttö uudelleenskannauksista tai validoinnista korjaavien toimenpiteiden jälkeen
• Poikkeusten ja jäännösriskien hyväksynnät viivästyneille tai paikkauskelvottomille järjestelmille
• Tietoturvatiedotteiden seurantaprosessi toimittajille, kirjastoille ja pilvipalveluille
• Kuukausittaiset tietoturvajohtajan tai johdon katselmuspöytäkirjat
• Ristiinkartoitus ISO 27001:2022-, NIS2-, DORA-, GDPR- ja COBIT 2019 -velvoitteisiin
• Sisäisen tarkastuksen tai teknisten kontrollien varmennuksen tulokset

Zenith Blueprint -oppaan Auditointi, katselmointi ja parantaminen -vaiheen kohdassa Vaihe 24 Clarysec korostaa soveltuvuuslausunnon, riskirekisterin ja riskienkäsittelysuunnitelman välistä jäljitettävyyttä:

SoA:n tulee olla yhdenmukainen riskirekisterisi ja riskienkäsittelysuunnitelmasi kanssa. Tarkista kahdesti, että jokainen riskien käsittelyksi valitsemasi kontrolli on merkitty SoA:ssa ”Sovellettava”.

Tämä on erityisen tärkeää haavoittuvuuksien hallinnassa. Jos hallintakeino 8.8 on sovellettava, auditointipaketin tulee todistaa paitsi se, että skannauksia tehdään, myös se, että havaintoja hallinnoidaan riskien käsittelyn ja jatkuvan parantamisen kautta.

30 päivän valmiussprintti

Jos auditointi on lähellä, älä aloita kirjoittamalla kaikkea uudelleen. Aloita rakentamalla näyttö nopeasti.

Tämä sprintti ei poista kaikkea teknistä velkaa. Se muuttaa auditointikeskustelun. Sen sijaan, että puolustaisit sekavaa skannerivientiä, voit näyttää hallitun prosessin, jossa on omistajat, aikataulut, toimenpiteet, päätökset ja valvonta.

Siirry skannauksista puolustettavaan näyttöön

Haavoittuvuuksien ja korjauspäivitysten hallinnan valmius auditointia varten ei tarkoita sen todistamista, ettei haavoittuvuuksia ole. Se tarkoittaa sen todistamista, että organisaatio pystyy löytämään ne, ymmärtämään ne, priorisoimaan ne, korjaamaan ne, hallitsemaan poikkeukset ja osoittamaan valvonnan.

Clarysecin Zenith Blueprint, Zenith Controls, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka, Haavoittuvuuksien ja korjauspäivitysten hallintapolitiikka pk-yrityksille, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka pk-yrityksille tarjoavat rakenteen tällaisen näyttötyönkulun rakentamiseen.

Jos organisaatiosi valmistautuu ISO 27001:2022 -sertifiointiin, NIS2-valmiuteen, DORA:n mukaiseen digitaaliseen operatiiviseen häiriönsietokykyyn, asiakkaan huolellisuusarviointiin tai sisäiseen tarkastukseen, aloita yhdellä kysymyksellä:

Voidaanko jokainen kriittinen haavoittuvuus jäljittää skannauksesta sulkemiseen?

Jos vastaus on ei, Clarysec voi auttaa rakentamaan rekisterin, politiikkakokonaisuuden, ristiin vaatimustenmukaisuuden kartoituksen, johdon katselmointipaketin ja auditointivalmiin näyttötyönkulun, joka muuttaa teknisen skannauksen puolustettavaksi hallinnoinniksi.