Eurooppalainen kyberturvallisuuskenttä elää murroskautta. NIS2-direktiivin ja CRA-asetuksen (Cyber Resilience Act) myötä tietoturva on muuttunut teknisestä suorituksesta tiukasti säännellyksi liiketoimintavastuuksi. Näiden muutosten johdosta organisaatiot joutuvat miettimään kuinka sovittaa yhteen perinteiset tietoturvakehykset ja asetuksista nousevat lakisääteiset velvoitteet.
Tässä blogisarjassa tarkastelemme kuinka ISO 27001 -standardin mukainen tietoturvan hallintajärjestelmä (ISMS) toimii ponnahduslautana NIS2- ja CRA-vaatimusten saavuttamisessa, jonka prosessissa erityisesti haavoittuvuushallinta nousee keskeiseen rooliin. 2NS on sitoutunut korkean tason tietoturvaan ja olemme ISO 27001 -sertifioitu yritys. Käytämme blogisarjassa esimerkkinä omaa tietoturvan hallintajärjestelmäämme havainnollistamaan NIS2:sta ja CRA:sta nousevia muutoksia. Alkuun käsittelemme ISMS-järjestelmäämme ISO 27001 -standardin valossa ja seuraavissa blogeissa kerromme lisää NIS2:n ja CRA:n tuomista muutoksista.
Mikä on ISO 27001 -tietoturvastandardi?
ISO 27001 on tietoturvastandardi, joka määrittelee vaatimukset tietoturvan hallintajärjestelmän (ISMS) perustamiselle, käyttöönotolle, ylläpidolle ja jatkuvalle kehittämiselle. Tietoturvan hallintajärjestelmä (ISMS) on kokonaisvaltainen rakenne, jolla ylläpidetään yrityksen tietoturvaa. Hallintajärjestelmää pyritään jatkuvasti seuraamaan ja parantamaan, niin että se pystyy joustavasti vastaamaan muuttuvien olosuhteiden asettamiin vaatimuksiin. ISO 27001 on arvostettu standardi ja osoitus siitä, että yritys on luotettava kumppani, jonka tietoturva on kunnossa.
Kuinka 2NS:n ISMS on rakennettu?
2NS:llä on ISO/IEC 27001- sekä ISO 9001-sertifioinnit ja sen ISMS noudattaa näiden stardardien mukaista tietoturvallisuuden hallintajärjestelmää.
Hallintajärjestelmä koostuu neljästä askelmasta:
• Hallintajärjestelmä (Management system)
• Riskien arviointi (Risk assessment)
• Riskien käsittely (Risk treatment)
• Tulokset (Result)
Hallintajärjestelmä muodostaa rungon, jonka toiminnan ytimessä on PDCA-kehityssykli. PDCA (Plan, Do, Check, Act) voidaan nähdä hallintajärjestelmän moottorina, jonka eri osissa määritellään, kuinka hallintajärjestelmää toteutetaan aina suunnittelusta toimintaan, sekä millaisia toimia sen eri vaiheissa toteutetaan.
Hallintajärjestelmän toteutumista seurataan määräajoin ja kehityskohtia pyritään parantamaan seuraavalla PDCA-syklillä. PDCA:lle tyypillisiä toimia voivat olla esimerkiksi päätökset siitä, miten erilaisia riskejä lähestytään organisaatiossa, mitä metriikkaa käytetään, kuka vastaa mistäkin ja miten prosessit dokumentoidaan.
Riskien arvioinnissa noudatetaan ISO 27001:stä tulevaa 8.2 Information security risk assessment -säädöstä, joka asettaa tietyt vaatimukset tietoturvan riskien arvioinnin aikatauluista ja tulosten dokumentoinnista. 2NS:llä riskien arviointi toteutetaan vuosittain tai merkittävän muutoksen koittaessa. Riskien arvioinnin osiossa arvioidaan todennäköisiä 2NS:ään kohdistuvia riskejä ja niiden vaikutuksia mahdollisen altistumisen seurauksena. Havainnot kerätään omaksi tietoturvariskien käsittelysuunnitelmaksi, joka huomioi hyväksytyt ja ei-hyväksytyt riskit. Jälkimmäisten kohdalla annetaan tarkempi kuvaus vaihtoehdoista tilanteen hoitamiselle sekä kytketään ne asianmukaisiin tietoturvallisuuden hallintakeinoihin (Annex A).
Riskien käsittelyssä hyödynnetään ISO 27001:n 8.3 Information security risk treatment -säädöstä riskien arvioinnin tulosten dokumentoinnista ja säilyttämisestä, sekä sitoudutaan toteuttamaan tietoturvariskien käsittelysuunnitelmaa. Riskien arvioinnin aikana löydetyt uhat kytketään tässä vaiheessa yhteen tai useampaan Annex A tietoturvallisuuden hallintakeinoon, jotka ovat ISO 27001:n määrittämiä suojamekanismeja tunnistettuja uhkia vastaan. Hallintakeinot on jaettu neljään kategoriaan, joiden pohjalta yritykset voivat valita oman toimintansa kannalta merkitykselliset keinot. 2NS:llä on käytössä hallintakeinoja ohjeistuksen mukaisesti neljästä kategoriasta, joista keskitymme nyt tarkemmin teknisten haavoittuvuuksien hallintaa säätelevään A 8.8:aan.
Hallintajärjestelmän viimeisessä vaiheessa tarkastellaan tuloksia. Tämä vaihe kuvaa edellisten vaiheiden prosesseista syntyneitä käytänteitä ja toimintaohjeita. Ne osoittavat, että yrityksen suorituskykyä on arvioitu ja tulokset ovat mitattavissa, dokumentoituja ja toimivat konkreettisena näyttönä yrityksen tietoturvan tasosta. Tämä vaihe on erityisen tärkeä, sillä onnistunut tietoturva tähtää lopulta siihen ettei vakavia tietoturvaloukkauksia tai poikkeamia ole raportoitavaksi.
Annex A 8.8 controller – teknisten haavoittuvuuksien hallinta
Annex A 8.8 -hallintakeino asettaa vaatimuksen tunnistaa, arvioida ja pienentää omien IT-järjestelmien ja ohjelmistojen haavoittuvuuksia nopealla aikataululla. Tällä huolehditaan, että yritys on tietoinen omiin järjestelmiinsä kohdistuvista tietoturvapuutteista ja ottaa aktiivisen, riskiarvioihin perustuvan lähestymistavan haavoittuvuuksien korjaamiseksi ennen kuin vihamieliset toimijat ehtivät hyödyntää niitä. 2NS:llä teknisten haavoittuvuuksien hallinta noudattaa A.8.8:n mukaisia säädöksiä. Ideaalitilanteessa Annex A:n mukainen teknisen haavoittuvuuden hallinta koostuu seuraavista osista:
1. Selkeästi määritellyt omistajuudet ja roolit. 2NS:llä teknisestä haavoittuvuushallinnasta vastaa CISO. Tietoturvariskien käsittelysuunnitelmassa määritellään vielä uhkakohtaisesti eri riskien hallinta tietyille henkilöille. Selkeä omistajuus ehkäisee katkoja ja viiveitä.
2. Ajantasainen luettelo käytössä olevista palveluista, laitteista ja järjestelmistä. Tämä koskee rautatasoa, ohjelmistoja ja pilvipalveluita. 2NS:llä on asianmukaisesti dokumentoitu asset -palveluluettelo (A.5.9), josta käy ilmi käytettävissä olevat palvelut, järjestelmät, laitteisto sekä käytöstä poistetut palvelut ja työkalut.
3. Teknisten haavoittuvuuksien tunnistaminen. Tunnistamisen tarkoituksena on pysyä ajan tasalla uusista tietoturvauhista. 2NS:llä hyödynnetään Traficomin Kyberturvallisuuskeskuksen Hyöky-palvelua, joka on kansallinen hyökkäyspinta-alan kartoitustyökalu. Lisäksi ajantasaisia haavoittuvuusuutisia seurataan eri laitetoimittajien ja tietoturvatoimijoiden uutiskirjeiden tilauksella, edellisessä kohdassa mainitun palveluluettelon pohjalta. Zero-day haavoittuvuuksista tiedottaa Traficomin Kyberturvallisuuskeskus. Teknisten haavoittuvuuksien tunnistamisen alle kuuluvat myös kolmannen osapuolen palveluntarjoajien riskit, kuten ohjelmistot, avoimen lähdekoodin kirjastot ja pilvipalvelut. A.5.20 -hallintakeino vaatii, että tietoturvan hallinnasta on pystyttävä sopimaan erikseen kaikkien kumppaniverkoston toimijoiden kanssa. Sovittavia seikkoja voivat olla esimerkiksi juridiset vaatimukset koskien datan oikeaoppista käsittelyä.
4. Riskien arviointi. Yrityksen täytyy kyetä erottelemaan haavoittuvuudet sen pohjalta kuinka realistisen uhan ne muodostavat, millaiset liiketoimintariskit ovat tai kuinka helposti haavoittuvuus on hyödynnettävissä. Kaikki haavoittuvuudet eivät muodosta samanarvoista riskiä, joten relevanttien uhkien priorisoiminen, korkean riskin painottaminen ja liiketoimintakriittiset järjestelmät on asettettava etusijalle. 2NS:llä ISMS:n Riskien arviointi -osio listaa teknisen puolen haavoittuvuuksia koskevat skenaariot. Lisäksi käytössä on tietoturvapoikkeamien hallintaprosessi, jossa määritetään toimet poikkeaman käsittelylle sen vakavuustasteen tunnistamisen jälkeen.
5. Päätökset oikaisevista toimista. Riskien arvioinnin jälkeen yrityksen täytyy päättää kuinka haavoittuvuuksien löytämisen jälkeen toimitaan. On tehtävä valintoja toimista, joilla haavoittuvuuksia paikataan. Onko paikkaaminen mahdollista vai tehdäänkö väliaikaisia korjauksia? Onko valvontaa tarpeen lisätä? Tarvitaan selkeät toimintatavat ja käytänteet haavoittuvuuksien paikkaamis- ja päivityssykleille, järjestelmien eristämiselle tai poistamiselle sekä mahdollisille konfiguraatiomuutoksille. 2NS:llä palvelimet ja laitteisto päivitetään säännöllisesti. Ohjelmistopuolella sovelluskehykset ja kirjastot tarkistetaan jokaisen buildin yhteydessä. Ohjelmistokehitys ei kuitenkaan ole 2NS:n toiminnan ytimessä, mutta prosessiin on ohjeistus, joka noudattaa ohjelmistokehityksestä tuttua putkea koodikatselmoinnista testaukseen ennen tuotantoon vientiä. Edellä mainittujen toimien aikataulu perustuu riskien vakavuuteen.
6. Muutoksenhallinnan käytännöt. Oikaisevat toimet tuovat mukanaan muutoksia, joiden hallinta vaatii omat prosessinsa. 2NS:llä tätä ohjaa muutoksenhallintaprosessi, joka käynnistetään, jos yrityksen operatiivinen kyvykkyys on uhattuna tai prosesseihin tai käytänteisiin kohdistuu suurempia muutoksia. Prosessin vaiheet koostuvat muutosehdotuksen arvioinnista, riskien analyysista ja suunnitelmasta sisältäen aikataulun sekä tarpeen vaatiessa roll back -suunnitelman, prosessin toteutuksen ja jälkiarvioinnin. Muutoshallinnan tausta-ajatuksena on parantaa yrityksen kyvykkyyttä reagoida tehokkaasti äkillisiin muutoksiin ja välttyä mahdolliselta epävakaudelta, joka aiheutuisi suunnitelman puutteesta.
7. Haavoittuvuushallinnan aktiivisuuden seuranta ja dokumentointi. Yritysten tulisi noudattaa hyviä dokumentaatiokäytänteitä pitäessään kirjaa tunnistetuista haavoittuvuuksista, riskien arviointiprosesseista ja toimista riskien minimoimiseksi. 2NS:llä noudatetaan PDCA-syklin Check osion suorituskyvyn mittaukseen liittyvää ISO 27001 9.1 ohjeistusta seurannasta, mittaamisesta, analysoinnista ja arvioinnista. Tässä vaiheessa vahvistetaan korjaavien toimien tehokkuus, eli haavoittuvuudet on tunnistettu ja käytössä olevat hallintakeinot toimivat halutusti eikä uusia ongelmia ilmene. Tuloksena on seurantaraportti, automaattisesti Jiran pohjalta päivittyvä lista ISMS:n käyttämistä keinoista, sekä tieto niiden omistajuudesta ja auditointien toistuvuudesta. Tulokset raportoidaan vuosittain johdolle osana management review -katselmointeja.
8. Haavoittuvuushallinnan prosessin tarkastaminen ja parantaminen. Haavoittuvuushallinnan viimeisessä vaiheessa jo tehtyjä toimia arvioidaan ja mietitään kuinka prosessia voitaisiin entisestään parantaa. Tässä kohtaa noudatetaan 10.1 ”jatkuvan parantamisen” säädöstä. Toteuttaakseen tätä kohtaa, yritysten on sitouduttava jatkuvasti parantamaan omaa ISMS:äänsä luomalla sitä tukevia prosesseja, joilla osoitetaan tietoturvakyvykkyyden parantuminen. Tämä voi käytännössä näkyä korjaustoimien jälkeisenä lyhyenä katsauksena siihen, kuinka nopeasti uhka havaittiin, tavoittiko se heti oikean vastuuhenkilön ja kykenikö muutoksenhallintaprosessi vastaamaan tehokkaasti järjestelmiin kohdistuneeseen uhkaan. 2NS:llä jatkuva parantaminen on käytössä PDCA-syklin Act-osiossa. Sen toiminnallisuudet on sidottu auditointeihin ja johdon katselmointeihin, joiden pohjalta pyritään tunnistamaan mahdolliset kehityskohdat. Nämä lisätään sitten seurantaraportin kaltaiseen muutoksia käsittelevään changes Jira-putkeen, josta ne päätyvät edelleen tiketeiksi asianosaisten työpöydille. Tähän haavoittuvuushallinnan vaiheeseen kuuluu myös ISMS:n käytänteiden ja toimintatapojen sekä hallintakeinojen toimivuuden arviointi (10.2 poikkeavuudet ja oikaisevat toimet). Esimerkkinä tästä voi olla tilanne, jossa jokin ohjeistus ei ole tavoittanut henkilöstöä tai jotain tunnistettua riskiä säätelevä hallintakeino ei toiminutkaan halutusti. 2NS:llä tässä osiossa mainitut prosessit kuuluvat niin ikään osaksi johdon katselmoinneissa käytyjä keskusteluja ISMS:n eri toiminnallisuuksista.
Yhteenvetona voidaan todeta, että 2NS:llä noudatetaan suoraan ISO 27001 -standardissa määriteltyä ohjeistusta sekä tietoturvan hallintajärjestelmän (ISMS) rakentamisesta että sen eri osissa säädettyjen prosessien toteuttamisesta. NIS2-direktiivi tuo kuitenkin tullessaan muutamia muutoksia, jotka laajentavat ISO 27001 standardissa määriteltyjä vaatimuksia ja toisaalta lisäävät yritysten raportointiin ja varmentamiseen liittyviä velvollisuuksia. Lähtökohtaisesti ISO 27001 sertifioidulla yrityksellä on hyvä pohja tulevien muutosten (NIS2 ja CRA) liittämiseksi omiin prosesseihin ja käytänteisiin, ja ISO 27001 sertifiointia kannattaakin ehdottomasti harkita. Seuraavassa blogissamme pureudumme tarkemmin NIS2:n tuomiin muutoksiin.
Iiro Vanhatalo,
Tietoturva-asiantuntija, 2NS Cybersecurity