Tietoturvan asiantuntijan rooli sote-järjestelmän kehityksessä: Näin CISO tai Security Champion tukee tietoturvavaatimusten täyttämisessä

2NS:n asiantuntija Harri Verho kertoo, millainen työprosessi on tietoturvan varmistaminen ja CISO-konsulttina toimiminen uusilla Sote-alueilla käytettävien järjestelmien kehityksessä.

Sovelluksen tietoturvan rakentaminen lähtee mielellään jo suunnitteluvaiheessa uhkien ja riskien arvioinnista. Nykyisessä maailmantilanteessa sote-alueiden järjestelmien uhkamallinnukseen täytyy ottaa huomioon myös valtiolliset toimijat ja näiden varjokoneistot.

Varsinaisen kehitystyön aikana tietoturvasta huolehditaan koko ajan kestävästi. Kehityksen aikana mukaan astuu myös sote-prosessin erikoisuus: KANTA-sertifiointi. Harrin kokemuksen mukaan sertifikaatin vaatimuksia kannattaa seurata huolellisesti mahdollisimman ajoissa, jotta sovelluksen kehitys etenee mahdollisimman sujuvasti.

Sote-järjestelmien omat vaatimukset

KANTA-sertifiointi on jaettu eri luokkiin sovelluksen käsittelemien tietojen perusteella. Terveydenhuollon asiakastietoja käsittelevät järjestelmät kuuluvat luokkiin A ja B. A-luokka jakautuu edelleen kolmeen alaluokkaan A1, A2 ja A3. Tietojärjestelmän luokitteluun vaikuttaa järjestelmän käyttötarkoitus, Kanta-liitettävyys, järjestelmässä käsiteltyjen asiakastietojen luonne ja laajuus sekä järjestelmän riskitaso ja kriittisyys.

Sovelluksen auditointitason määrityksen jälkeen lähdetään täyttämään auditoijalta saadun listan vaatimuksia.

-A1-järjestelmän tapauksessa dokumentoitavia vaatimuksia oli eräässä projektissa yhteensä 30 kappaletta alakohtineen ja 11 vaatimusta piti osoittaa demonstroinnin kautta, Harri muistaa.

Auditointi on kehitystyössä tärkeä etappi

Tässä kohtaa CISO:n mukanaolo ja hyvä pohjatyö maksaa itsensä takaisin, sillä hyvässä tapauksessa suuri osa materiaalia on jo valmiiksi kasassa.

-Meilläkin materiaali oli jo suurelta osin kasassa, tosin järjestelmämme edelleen työn alla oleva kehitys aiheutti omat haasteensa koska arkkitehtuuriin valittiin edelleen komponentteja mikä vaikutti kokonaisarkkitehtuuriin sekä tietoturvaan, Harri kertaa.

CISO on myös tässä kohtaa linkkinä auditoijan ja kehitystiimin välillä ja voi tarkentaa esimerkiksi sitä, koskevatko kaikki järjestelmäluokan vaatimukset nyt kehitettävää sovellusta. Esimerkiksi tässä A1-luokan tapauksessa lista päivittyi vielä tarkastelun jälkeen ja näin ollen auditointi- ja kehitystyö sujuivat molemmat jouhevammin.

Auditointi tapahtuu workshopeissa, joissa esitellään pyydettyihin asiakohtiin liittyvää dokumentointia, samalla voidaan antaa tarvittavaa lisä- ja taustatietoa auditoijalle. Näillä voidaan selvittää esimerkiksi järjestelmän tiedonhallintamallia, kehittäjän käsikirjaa ja prosesseja, arkkitehtuuria sekä lokien ja varmistuksien hallintaa.

Workshoppien aikana auditoijat tarkentavat tarpeensa ja kehittäjätiimi tietoturva-asiantuntijoiden johdolla voi esittää tarvittavan toiminnallisuuden vaatimusten mukaan.  Workshoppien jälkeen voi olla vielä tarkentavia kysymyksiä, joihin toimitetaan vastaukset.

-Lopulta sovellusauditointiin saadaan toivon mukaan myönteinen vastaus ja sovelluskehityksen yksi tärkeimpiä välietappeja on saavutettu. Joskus on skumpatkin tämän kunniaksi poksauteltu, Harri kehaisee.