Poikkeamien rekisteröinnissä ohjelmistokehityksessä on kyse kahdesta eri asiasta, jotka usein sekoittuvat toisiinsa: haavoittuvuudesta tai häiriöstä ohjelmistossa, jonka rakennatte ja toimitatte, sekä poikkeamasta omassa kehitysketjussanne — ympäristössä, jossa koodia tuotatte. Se, mitä dokumentoitte, kenen on tiedettävä siitä ja mihin siihen liittyviä jatkotoimenpiteitä kuuluu, vaihtelee lajin mukaan. Joka ei tee tätä erottelua, jää usein maamme tärkeimman poikkeaman ohi: saastuminen koodin muodostusputkistossa, joka leviää koodin kautta kaikkiin asiakkaisiin, jotka siitä ottavat vastaan.
Haavoittuvuus toimitetussa koodissa vaikuttaa suoraan asiakkaaseen: asiakas suorittaa ohjelmiston, joten asiakas ottaa riskin. Poikkeama kehitysketjussa — varastettu käyttöoikeus, vaaraan joutunut muodostus-tunnus, vuoto lähdekoodi-säilössä — koskee ensin sinua, mutta voi ulottua jokaiseen asiakkaaseen, joka käsittelee kyseistä koodia. Molemmissa tapauksissa pätee, että tietoturvakysymyslista tai tarkastaja ei kysy, onko koskaan jotain mennyt pieleen, vaan voitko näyttää, mitä olet siitä dokumentoinut ja oppinut.
Mitä dokumentoitte poikkeamasta koodissa
Haavoittuvuudessa tai häiriössä toimitetussa ohjelmistossa on kysymys: milloin se havaittiin, kuka tai mikä sen havaitsi (sisäinen testi, asiakkaan ilmoitus, skannaus, ulkopuolinen tutkija), mitkä ohjelmiston osat siihen liittyvät, mikä on mahdollinen vaikutus, mitä toimenpiteitä ryhdyttiin ja milloin, ja kuka organisaatiossanne on vastuussa seurannasta. Hyvä rekisteröinti osoittaa myös, onko korjaus otettu käyttöön kaikilla asiakkailla, jotka käyttävät kyseistä versiota, vai vain niillä, jotka ilmoituksesta ilmoittivat. Jälkimmäinen on juuri sitä, mitä vastaanottaja kysymyslistassa kysyy: ei sitä, oliko sinulla koskaan haavoittuvuus, vaan sitä, takaaako prosessisi, että jokainen, joka siihen joutuu, saa siitä kuulla.
Mitä dokumentoitte poikkeamasta kehitysketjussa
Poikkeama omassa kehitysympäristössäsi — vaaraan joutunut tunnus, jolla on pääsy lähdekoodiin, muodostus-palvelin, joka käyttäytyy odottamattomasti, riippuvuus, joka myöhemmin osoittautuu pahanpuoleiseksi — vaatii hieman erilaisen rekisteröinnin. Tässä on kysymys: mistä järjestelmästä tai tunnuksesta oli kyse, kenellä oli pääsy sinä aikana kun se tapahtui, onko jälkiä siitä, että koodia on muutettu tai katsottu, ja mitkä asiakkaat käyttävät ohjelmistoa, joka rakennettiin tai toimitettiin sinä ajanjaksona. Tämä on niiden poikkeamien tyyppi, jossa kehitysketjun pääsynvalvonta vaikuttaa suoraan: ilman ajantasaista käsitystä siitä, kuka saa missä tehdä mitä, on tämä selvityskysymys poikkeaman sattuessa huomattavasti hankalampi vastata.
Kelle ilmoitatte ja kenelle ei
Se, oletko itse tietoturvalain (Cyberbeveiligingswet) huolenpitovelvollisuuden alainen vai et, määrää, kenelle ilmoitatte poikkeamasta. Entiteetit, jotka on nimetty itse kriittisiksi tai tärkeiksi, ovat velvollisia ilmoittamaan viranomaiselle; mitä tarkalleen on tehtävä ja millä aikataululla, kuvataan direktiivissä ja kansallisessa laissa, ja vaihtelee tilanteen mukaan. Ohjelmistoyritys, jota toimitusketju koskettaa — joka itse ei siis ole velvoitettu, mutta toimittaa asiakkaalle, joka on — ei ole velvollinen ilmoittamaan viranomaiselle, mutta sillä on tavallisesti sopimuksellinen velvoite ilmoittaa asiakas. Se ei tee omaa rekisteröintiä vähemmän tärkeäksi: asiakas, joka kysyy, oliko sinulla koskaan poikkeama, haluaa nähdä konkreettisen vastauksen, ei takaiskuarvioita.
Elävä rekisteri, ei arkisto
Poikkeamien rekisteröinti toimii parhaiten elävänä dokumenttina: listana, jossa kunkin poikkeaman tila, todiste ja omistaja löytyvät, ei irrallisen raportin sijaan, joka katoaa kansioon käsittelyn jälkeen. Se sopii yhteen sen kanssa, miten laajempi huolellisuusvelvollisuus on rakennettu, jossa kymmenen toimenpidettä jokainen vaativat tilaa ja omistajaa. Joka haluaa nähdä, miten poikkeamarekisteröinti liittyy muihin yhdeksään toimenpiteeseen, löytää sen yleiskatsauksen osoitteesta kaikkien aiheiden sivu tilanteen mukaan.
Riippuu siitä, onko organisaationne itse huolellisuusvelvollisuuden piirissä, kärsitäänkö sitä ketjussa, vai ei kumpaakaan, muutamalla kysymyksellä näet NIS2-tarkistus, joka muutamalla kysymyksellä antaa viitteen. Joka haluaa täsmälleen tietää, mistä secria.eu:n tieto tulee ja miten sitä ylläpidetään, lukee sen sivulla siitä, miten se toimii. Ja joka lukemisen jälkeen haluaa tietää, mitä tilaus lisää ilmaiseksi saatavilla olevaan, löytää sen selkeästi yleiskatsaus siitä, mitä sisältyy.
Tämä teksti on yleinen selitys, ei oikeudellinen neuvonta omasta tilanteestanne. Arvioidaksenne omaa poikkeamaprosessianne tai ilmoitusvelvollisuuttanne ottakaa yhteyttä asianajajaan tai sektoriinne toimivaltaiseen valvontaviranomaiseen.