Miten selvitä kunnialla Katakrin I-osa-alueen auditoinnista

TL;DR, dokumentoi tarkasti ja laita prosessit kuntoon.

Kansallisen turvallisuusauditointikriteeristön (Katakri) mukainen auditointi on monille organisaatioille peikko, jota ei voi paeta. Katakri-auditointi auttaa viranomaisia arvioimaan, millainen on organisaation kyky suojata viranomaisen salassa pidettävää tietoa kaikissa niissä ympäristöissä, joissa tietoa käsitellään. Auditoija saattaa tuntua ikävältä näsäviisastelijalta, joka kyselee pikkuasioita ja laittaa raporttiin erilaisia syysruskan värejä, kun vastaukset eivät tunnu oikein tyydyttävän eikä dokumentaatio näytä auditoijan mielestä riittävän tarkalta. Lisäksi auditoija tuntuu aina löytävän juuri sen tapahtuman, jonka prosessievidensseissä ei ole ihan kaikki kohdillaan.

Seuraavassa käyn läpi I-osa-alueen Katakri-vaatimuksia ja niihin liittyviä kehitysehdotuksia, jotka koskevat melkein kaikkia näkemiäni Katakri-auditointia vaativia kohteita. Kehitysehdotuksista yksikään ei liity Nixun tuotteisiin tai palveluihin, vaan toimenpiteet ovat sellaisia, jotka organisaatio voi itse toteuttaa. Toimenpiteisiin vaaditaan lähinnä aikaa ja tahtoa – eli budjetti ja tehtävän asetus.

Yhtäkään seuraavista kohdista ei vaadita sellaisenaan eikä mikään niistä pelkästään riitä Katakri-auditoinnin läpäisemiseen.

Tietoliikenneturvallisuus

Vaatimukset I-01, I-02 ja I-03

Auditoitava kohde tulisi dokumentoida siten, että se voidaan rajata ja sijoittaa organisaation koko verkkoarkkitehtuuriin. Tyypillinen ongelma syntyy, kun järjestelmälle on laadittu pelkästään oma verkkokaavio, mutta sitä ei pystytä sijoittamaan organisaation kokonaisvaltaiseen verkkoarkkitehtuurikuvaan. 

Kohteen kuvauksesta on hyvä käydä selkeästi ilmi liitynnät muihin verkkoalueisiin ja liitynnöissä käytettävät mekanismit. Jos liityntä on TLIII- tai TLII-tasolta alemmalle tasolle, käytössä pitää olla yhdyskäytäväratkaisu.

Verkkodokumentaatiossa tulisi kuvata kaikki tarvittava liikenne perusteluineen: tästä syntyy kommunikaatiomatriisi, jossa on ainakin lähde, kohde, protokolla, portit sekä liikenteen syy. Verkkodokumentaatiossa on suotavaa kuvata myös kaikki suodattavat laitteet. Auditoija tutkii kommunikaatiomatriisia ja valikoi sieltä joukon yhteyksiä, joita auditoija vertaa sitten suodattavien laitteiden sääntöihin. 

Kommunikaatiomatriisin ja suodattavan laitteen välillä tulisi olla prosessi, jonka mukaan suodattavat laitteet on konfiguroitu vastaamaan kommunikaatiomatriisia. Tyypillisesti tämä voi olla tikettijärjestelmä, jossa tiketillä tilataan liikenneavaus. Tiketin käsittelyssä tyypillisesti pitäisi varmistaa, että tilaus on auktorisoitu ja rationaalinen. Kaikista liikenneavauksista ja niiden muutoksista tulisi olla vastaavat prosessievidenssit. Kun auditoija tarkastaa suodattavan laitteen sääntöjä kommunikaatiomatriisiin peilaten, samalla auditoija yleensä haluaa nähdä prosessievidenssit säännön syntyhistoriasta.

Auditoitavan kohteen olisi hyvä laatia lisäksi prosessi, jonka mukaan suodattavien laitteiden asetukset tarkastetaan säännöllisesti sekä huoltojen että poikkeustilanteiden aikana. Vuosikello ratkaisee tästä vain puolet, sillä huolto- ja poikkeustilanteita varten tarvitaan omat prosessit.

Vaatimus I-04

Hallintayhteydet järjestelmiin pitäisi dokumentoida siten, että kaikki hallintayhteydet ovat tunnistettavissa. Tässä usein unohtuu, että virtualisointialustalla löytyy virtualisointijärjestelmän kautta erilaisia yhteyksiä. Myös mahdolliset kaistan ulkopuoliset verkonhallintaratkaisut (Out-of-Band) on syytä dokumentoida.

Hallintayhteydet pitäisi toteuttaa siten, että niissä noudatetaan vähimpien oikeuksien periaatetta. Vaikka ylläpitäjillä tulee olla pääkäyttäjäoikeudet tehtäviensä suorittamiseksi, kaikilla ylläpitäjillä ei tarvitse välttämättä olla kaikkia oikeuksia kaikkiin järjestelmiin. Isolla toimijalla ei mielestäni ole mitään perustelua olla käyttämättä jotain lukuisista PAM-ratkaisuista tämän vaatimuksen tukemiseen.

Tietojärjestelmäturvallisuus

Vaatimukset I-06 ja I-07

Käyttäjähallintaa varten tulisi olla määriteltynä prosessi, jota noudatetaan ja josta jää selkeät evidenssit. Tyypillisesti auditoinnissa tarkastetaan, että kohde pystyy vastaamaan seuraaviin kysymyksiin:

a) Keillä kaikilla on ollut oikeus Z ajankohtana t1?

b) Mitkä ovat olleet käyttäjän X oikeudet ajankohtana t2?

Tekninen ratkaisu (käyttäjänhallintajärjestelmä) on skaalautuva ratkaisu, mutta paperilomakepohjaiset ratkaisut ovat ihan yhtä lailla toimivia, kunhan paperit ovat asianmukaisessa järjestyksessä ja näytettävissä auditoijalle.

Käyttöoikeuksia varten tulisi lisäksi olla prosessit, joiden avulla käyttöoikeudet pidetään ajantasaisina. Tässä korostuu erityisesti organisaation sisäinen kierto, jolloin usein käyttöoikeudet kumuloituvat eivätkä poistu asianmukaisesti.

Käyttäjätodennuksen osalta dokumentoidut asianmukaiset salasanapolitiikat ja -käytännöt ovat usein riittävät TLIV-tasolla. Todennusvaatimukset kuitenkin kattavat myös laitteet ja sovellukset, eli näidenkin käytännöt pitäisi dokumentoida. TLIII-tasolla edellytetään teknistä laitetodennusta ja vahvaa käyttäjätodennusta.

Vaatimus I-08

Järjestelmäasennuksia varten tulisi laatia asennus- ja kovennusohjeistukset kaikille järjestelmätyypeille. Ohjeistuksen tulee pohjautua johonkin tunnettuun kovennusstandardiin. Kaikki järjestelmien poikkeamat kovennuksista perusteluineen tulisi dokumentoida.

Asennus- ja kovennusohjeiden ylläpitoa varten tulisi olla prosessi, jonka mukaan dokumentaatio katselmoidaan säännöllisesti ja päivitetään sitä mukaa, kun toimintaympäristöön tai kovennusstandardeihin tulee muutoksia. Yleinen kompastus tapahtuu siinä, että jo asennettuja järjestelmiä ei päivitetä vastaamaan uusia vaatimuksia. 

Vaatimus I-09

Haittaohjelmasuojauksessa tyypillisesti pääsee alkuun tunnetun valmistajan keskitetyllä hallinnalla varustetulla haittaohjelmasuojauksella, jota ylläpidetään ja jonka tunnistetiedot päivitetään säännöllisesti. Pelkkä ohjelmisto ei kuitenkaan riitä, sillä hälytyksiä varten tarvitaan dokumentoitu prosessi, jonka mukaan hälytyksiä seurataan ja niihin reagoidaan. Tässä haluaisin korostaa sitä, että seurannasta ja reagoinnista vastaavalle taholle tulisi kouluttaa, että testivirus EICAR tulee käsitellä siten, kuin se olisi Iso Mörkö, eli havainnosta tulee seurata reagointi. Kun auditoija tuo kohteeseen EICARin, sillä ei mitata pelkästään virustutkan toimivuutta vaan halutaan tarkastaa koko prosessi.

Vaatimukset I-10 ja I-11

Käytännössä tämä vaatimus edellyttää keskitettyä lokienhallintaa, jonka tuottamia lokeja tietoturvavalvomo valvoo. Lokikattavuuden tulisi olla sellainen, että lokeista voidaan sekä havaita että jälkikäteen tutkia tietoturvapoikkeamat. Lokiratkaisu tulisi dokumentoida ja dokumentaatiossa perustella miksi lokit on valittu. Tietoturvavalvomolle tulisi tuottaa kuvaus siitä, mitä lokeista pitää seurata, miltä normaalitila näyttää ja miten erilaisiin poikkeamiin tulisi vastata. Auditoija tyypillisesti tuottaa jonkinlaisen vaarattoman turvapoikkeaman järjestelmään ja seuraa, että poikkeama käsitellään prosessin mukaisesti.

Vaatimukset I-12 ja I-15

Katakri-vaatimusten mukaan tietoliikenne tulee salata sekä turvallisuusalueen sisäpuolella että ulkopuolella. Turvallisuusalueen ulkopuolelle menevän liikenteen salaamisessa vaatimus edellyttää toimivaltaisen viranomaisen (usein Liikenne- ja viestintävirasto Traficom) hyväksymiä salausratkaisuja ja niissä riittävän pitkiä avainpituuksia. Turvallisuusalueen sisäpuolella voidaan käyttää salaamattomia yhteyksiä tai alemman tason salauksia, jos ne pohjautuvat riskiarviointiin ja niille on saatu toimivaltaisen viranomaisen erillishyväksyntä. Vaatimukset I-01 ja I-04 sisältävät vastaavat vaatimukset salausratkaisuille.

Vaatimus I-13

Tämä vaatimus on kohtuullisen kompleksinen ja käsittelee useita erilaisia asioita. Vaatimuksen alku ottaa kantaa siihen, että jo hankinnassa on ymmärretty järjestelmän turvavaatimukset ja hankinnassa on perusteltu miksi ja miten järjestelmä täyttää vaatimukset. Järjestelmää varten tulisi myös olla käyttöönottoprosessi, jonka mukaan asennukset ja päivitykset tarkastetaan sen osalta, että turvallisuusratkaisut toimivat oikein. Lisäksi vaatimus edellyttää, että verkkohyökkäyksiä vastaan on suojauduttu – Tyypillisesti auditoija haluaa tästä dokumentin, joka kertoo, mitkä ovat arvioidut verkkohyökkäystyypit ja miten niitä vastaan on suojauduttu.

Käyttöturvallisuus 

Vaatimus I-16

Tyypillisesti tässä ITIL (Information Technology Infrastructure Library) -pohjainen muutoksenhallinta kantaa pitkälle. Tavanomaisen ITIL-prosessin lisäksi tulisi huomioida säännölliset turvallisuustarkastukset sekä dokumentaation päivitys osana muutosta. Tyypillisesti auditoija tarkastaa otoksena muutaman muutoksen kaikkien prosessievidenssien osalta mukaan lukien dokumentaation päivitykset.

Tätä vaatimusta on hyvin vaikea (ellei mahdotonta) toteuttaa siten, että järjestelmä on pystytetty projektimoodissa vapaamuotoisemmin ja jossain vaiheessa julistettu tuotantokelpoiseksi. Tällainen käytäntö vastaa sitä, että auditoijalle esitetään koskemattomana hammastahnatuubi, jonne ulos puristettu hammastahna on laitettu takaisin.

Vaatimus I-19

Haavoittuvuuksienhallintaa varten pitäisi olla tieto siitä, mitä komponentteja järjestelmässä on, sillä komponenttiluettelon tulisi kattaa alimmatkin käytetyt open source -kirjastot. Haavoittuvuuksien seurannan tulisi kattaa kaikki komponentit. Kun jossakin komponentissa todetaan haavoittuvuus, merkitys tulisi arvioida riskipohjaisesti ja tunnistetun riskin perusteella tulisi laatia suunnitelma joko riskin poistamiseksi tai pienentämiseksi. Kun suunnitelma on toteutettu, tulisi varmistaa, että kaikki suunnitelman kohdat on tehty. Lisäksi järjestelmälle olisi hyvä tehdä säännöllisiä teknisiä haavoittuvuustarkastuksia. Tyypillisesti tämän kohdan teknisenä ratkaisuna kannattaa käyttää jotain CMDB (configuration management database) -järjestelmää. 

Vaatimus I-20

Varmistusten osalta olisi hyvä olla määriteltyinä RTO (Recovery Time Objective)/RPO (Recovery Point Objective) -arvot ja palautus testattuna siten, että näihin asetettuihin arvoihin on päästy.

Vaatimus I-21

Sähköisen tiedon tuhoamista varten tarvitaan dokumentoitu prosessi ja prosessievidenssit siitä, että prosessia noudatetaan. Tyypillisesti tuhottavat materiaalit pitäisi sijoittaa turvalliseen välivarastoon, josta sertifioitu palveluntarjoaja hakee materiaalin ja tuhoaa sen.

Mikäli tarvitset apua organisaatiosi Katakri-auditoinnin valmisteluissa tai sinulla herää aiheesta muita kysymyksiä, ota meihin yhteyttä.