ISO 27001 esiintyy yhä useammin pakollisena vaatimuksena puolustusohjelmistojen hankintakehyksissä eri puolilla Eurooppaa ja sen ulkopuolella. Siitä, mikä oli ennen toivottava erottautumistekijä, on tullut perustason odotus: toimittajat, joilla ei ole voimassa olevaa ISO 27001:2022 -sertifiointia, suljetaan tarjouskilpailujen lyhytlistoilta jo ennen teknisen arvioinnin alkamista. Sen ymmärtäminen, mitä standardi todella edellyttää — eikä vain sen, miltä sertifikaatti näyttää — on olennaista sekä sertifiointia tavoitteleville toimittajille että tarjouksia arvioiville hankintavastaaville.
Tässä artikkelissa tarkastellaan, mitä ISO 27001:2022 edellyttää ohjelmistokehitysorganisaatioiden kontekstissa, missä vuoden 2022 uudistus toi merkittäviä muutoksia ja mitä sertifiointi käytännössä tarkoittaa kehitysprosessien, tiimin kokoonpanon ja projektitoimitusten kannalta.
Mikä ISO 27001:2022 on — ja mikä muuttui
ISO 27001 on kansainvälinen standardi, joka määrittelee vaatimukset tietoturvan hallintajärjestelmälle (ISMS). Toisin kuin tekniset turvallisuusstandardit, jotka määräävät tiettyjä kontrolleja, ISO 27001 edellyttää organisaatioilta tietoturvariskiensä tunnistamista, asianmukaisten kontrollien käyttöönottoa näiden riskien hallitsemiseksi sekä jatkuvan parantamisen kierron ylläpitämistä turvallisuustason säilyttämiseksi ajan myötä.
Vuoden 2022 uudistus korvasi standardin ISO 27001:2013 ja toi merkittäviä muutoksia liitteeseen A, joka sisältää viitekontrollien joukon. Vuoden 2013 versiossa oli 114 kontrollia 14 osa-alueella. Vuoden 2022 versiossa nämä järjestettiin uudelleen 93 kontrolliksi neljään teemaan: organisatoriset kontrollit, henkilöstöön liittyvät kontrollit, fyysiset kontrollit ja teknologiset kontrollit. Merkittävämpää on, että käyttöön otettiin 11 uutta kontrollia — jotka kattavat ohjelmistokehitysorganisaatioiden kannalta suoraan relevantteja alueita:
- Uhkatiedustelu (5.7) — organisaatioiden on kerättävä ja analysoitava tietoa niiden kontekstin kannalta relevanteista uhkista
- Pilvipalvelujen käytön tietoturva (5.23) — selkeät vaatimukset pilvipalvelujen käytön hallinnalle
- ICT-valmius liiketoiminnan jatkuvuudelle (5.30) — jatkuvuussuunnittelussa on otettava huomioon ICT-riippuvuudet
- Verkkosuodatus (8.23) — kontrollit siitä, mihin internet-resursseihin järjestelmät voivat päästä
- Turvallinen koodaus (8.28) — viralliset vaatimukset turvallisille kehityskäytännöille
- Tietojen peittäminen (8.11) — vaatimukset arkaluonteisen datan peittämiselle muissa kuin tuotantoympäristöissä
Puolustusohjelmistotoimittajille kontrolli 8.28 (Turvallinen koodaus) on erityisen merkittävä. Vuoden 2022 standardi edellyttää nyt nimenomaisesti, että organisaatiot soveltavat turvallisen koodauksen periaatteita ohjelmistokehityksessä — eli turvallisen kehityksen käytännöt on dokumentoitava, niitä on noudatettava ja auditoitava, ei vain mainittava käytäntödokumentissa.
Ohjelmistokehityksen kannalta keskeiset kontrollit
ISO 27001 ei määrää tiettyjä teknologioita tai kehitysmenetelmiä. Sen sijaan se vaatii jäsenneltyä lähestymistapaa tietoturvariskien tunnistamiseen ja hallintaan koko ohjelmistokehityksen elinkaaren ajan. Käytännössä tämä kääntyy useiksi vaatimusluokiksi, jotka vaikuttavat siihen, miten ohjelmistokehitysorganisaatio toimii.
Pääsynhallinta (8.2–8.5). Standardi edellyttää, että pääsyä järjestelmiin, koodivarastoihin ja käyttöönottoinfrastruktuuriin hallitaan vähimmäisoikeuksien periaatteella. Puolustusohjelmistojen kehityksessä tämä tarkoittaa, että kehittäjillä ei tulisi olla tuotantopääsyä, koodikatselmoinnin on portitettava yhdistämiset suojattuihin haaroihin ja etuoikeutetun pääsyn käyttöönottojärjestelmiin on oltava aikarajoitettua ja lokitettua. Pääsyoikeudet on tarkistettava säännöllisesti ja peruutettava viipymättä, kun henkilöstö lähtee tai vaihtaa tehtäviä.
Kryptografia (8.24). Organisaatioilla on oltava kryptografisia kontrolleja ohjaava käytäntö: mitkä algoritmit on hyväksytty, miten avaimia hallitaan ja kuka vastaa kryptografisista päätöksistä. Puolustusohjelmistoissa tämä tarkoittaa tyypillisesti yhdenmukaisuutta kansallisten kryptografiastandardien kanssa (esim. CNSS-hyväksytyt algoritmit Yhdysvalloissa, BSI-hyväksytyt Saksassa) mielivaltaisen algoritmivalinnan sijaan.
Turvallinen kehityksen elinkaari (8.25–8.31). Standardi edellyttää, että turvallisuus integroidaan koko kehitysprosessiin: turvallisuusvaatimukset on määriteltävä suunnitteluvaiheessa, turvallisuustestaus on suoritettava ennen julkaisua ja riippuvuudet (kirjastot, kehykset) on arvioitava haavoittuvuuksien varalta. Tämä edellyttää suoraan käytäntöjä, kuten uhkamallinnusta, staattista analyysiä, riippuvuuksien haavoittuvuusskannausta ja tunkeutumistestausta.
Häiriönhallinta (5.24–5.28). Organisaatioilla on oltava dokumentoidut menettelyt tietoturvahäiriöiden havaitsemiseksi, raportoimiseksi ja niihin reagoimiseksi. Ohjelmistokehitysympäristöissä tämä tarkoittaa koodivarastoihin kohdistuvan poikkeavan pääsyn, epätavallisen käännöskäyttäytymisen (yleinen toimitusketjuhyökkäysten merkki) ja käyttöönottokonfiguraatioiden luvattomien muutosten valvontaa.
Hankintahuomautus: ISO 27001 -sertifikaatteja arvioitaessa varmista aina sertifioinnin laajuusmääritys. Sertifikaatti, joka kattaa vain "yrityksen pääkonttorin" tai "hallinnolliset toiminnot", ei anna mitään varmuutta kehitysympäristöstä, jossa koodia todella kirjoitetaan. Laajuuden on nimenomaisesti sisällettävä ohjelmistokehitystoiminnot ja niitä tukeva infrastruktuuri.
Mikä kehitysprosesseissa todella muuttuu
Organisaatiot, jotka tavoittelevat ISO 27001 -sertifiointia ensimmäistä kertaa, huomaavat tyypillisesti, että standardin vaikutus niiden kehitysprosesseihin on odotettua merkittävämpi. Seuraavia muutoksia vaaditaan johdonmukaisesti ja aliarvioidaan johdonmukaisesti.
Riskiarvioinnista tulee dokumentoitu tuotos. ISO 27001 edellyttää, että tietoturvariskit tunnistetaan, arvioidaan ja seurataan. Ohjelmistokehityksessä tämä tarkoittaa riskirekisterin tuottamista, joka kattaa kehitysympäristön riskit (vaarantuneet kehittäjien työasemat, varaston pääsy), toimitusketjun riskit (haitalliset riippuvuudet, vaarantuneet käännöstyökalut) ja operatiiviset riskit (virheellisesti konfiguroidut käyttöönotot, riittämätön pääsynperuutus). Riskirekisteri ei ole kertaluonteinen dokumentti — se on tarkistettava ja päivitettävä määrätyin väliajoin ja aina kun merkittäviä muutoksia tapahtuu.
SDLC-portit muuttuvat pakollisiksi tarkistuspisteiksi. Turvallisuusvaatimukset on otettava huomioon jokaisen kehityssyklin alussa. Turvallisuustestaus on suoritettava ennen ohjelmiston julkaisua. Nämä eivät ole valinnaisia toimintoja, jotka voidaan lykätä seuraavaan sprinttiin — ISO 27001 edellyttää, että ne sisällytetään kehitysprosessiin ja että niiden toteutumisesta on näyttöä. Auditoijat pyytävät turvallisuustestien tuloksia, eivät vain vakuutuksia siitä, että testaus suoritettiin.
Toimittaja- ja riippuvuushallinta edellyttää virallista käsittelyä. Standardi edellyttää, että tietoturvavaatimukset viestitään toimittajille ja että toimittajasuhteita valvotaan. Ohjelmistokehityksessä tämä kattaa ohjelmistossa käytetyt avoimen lähdekoodin kirjastot ja kolmannen osapuolen komponentit. Uusien riippuvuuksien arvioimiseen, olemassa olevien riippuvuuksien tunnettujen haavoittuvuuksien seuraamiseen ja vasta paljastuneisiin haavoittuvuuksiin reagoimiseen on oltava olemassa prosessi, joka on dokumentoitu.
Henkilöstöturvallisuusvaatimukset vaikuttavat rekrytointiin ja perehdytykseen. ISO 27001 edellyttää taustaselvitystä henkilöstöltä, jonka tehtäviin kuuluu pääsy arkaluonteisiin tietoresursseihin. Puolustusohjelmistotoimittajilla tämän voi olla tarpeen olla yhdenmukainen kansallisten turvallisuusvaatimusten (turvallisuusselvitysstandardit) kanssa, ja ISMS:n on dokumentoitava, miten henkilöstöturvallisuus toteutetaan ja ylläpidetään. Tämä vaikuttaa perehdytysaikatauluihin ja aiheuttaa kustannuksia, joita pienemmät organisaatiot joskus aliarvioivat.
Kehitysympäristöjen fyysinen turvallisuus on käsiteltävä virallisesti. Etä- ja hybridikehitysympäristöt tuovat fyysisiä turvallisuushaasteita, jotka standardi edellyttää organisaatioiden käsittelevän. Tämä sisältää käytännöt arkaluonteisen koodin parissa työskentelyyn julkisissa tiloissa, vaatimukset laitteiden salaukselle ja näytön lukitukselle sekä irrotettavan median kontrollit.
Miksi hankintavastaavat vaativat ISO 27001 -sertifiointia
Puolustushankinnan hankintavastaavan näkökulmasta ISO 27001 -sertifiointi palvelee useita tarkoituksia, jotka menevät pidemmälle kuin pelkät turvallisuuskontrollit.
Ensinnäkin se tarjoaa riippumattoman varmennuksen. Sertifioinnin myöntää akkreditoitu kolmannen osapuolen elin organisaation ISMS:n auditoinnin jälkeen. Toisin kuin itsearvioidut vaatimustenmukaisuuskehykset, ISO 27001 -sertifiointi edellyttää, että pätevä auditoija tutkii näyttöä kontrollien toteutuksesta, ei vain käytäntödokumentaatiota. Valvonta-auditoinnit tehdään vuosittain; uudelleensertifiointiauditoinnit kolmen vuoden välein. Tämä tarkoittaa, että sertifikaatilla on määritelty voimassaolon päättyminen ja se edustaa suhteellisen ajantasaista tilaa organisaation turvallisuuskäytännöistä.
Toiseksi se luo vastuullisuutta. ISO 27001 -sertifiointi edellyttää, että ylin johto on näkyvästi sitoutunut ISMS:ään. Tämä tarkoittaa, ettei organisaatio voi uskottavasti väittää, että turvallisuuspuutteet olivat yksittäisiä, johtoon liittymättömiä tapauksia — standardi edellyttää, että johto katselmoi ISMS:n, käsittelee poikkeamat ja kohdentaa resursseja turvallisuuteen. Hankintavastaaville tämä edustaa organisatorisen sitoutumisen tasoa, jota epäviralliset turvallisuuskäytännöt eivät pysty osoittamaan.
Kolmanneksi se yksinkertaistaa due diligence -arviointia. Sen sijaan, että jokaisesta mahdollisesta toimittajasta tehtäisiin yksityiskohtainen turvallisuusarviointi — mikä on resurssi-intensiivistä ja vaikeasti standardoitavaa — ISO 27001 -sertifiointia edellyttävät hankintakehykset voivat käyttää sertifikaattia perustason suodattimena. Tämä on tehokasta, vaikkakin epätäydellistä: sertifioidulla toimittajalla voi silti olla turvallisuusaukkoja, mutta todennäköisyys on pienempi ja vastuullisuusmekanismit ovat vankempia.
Erityisesti puolustussopimuksissa ISO 27001 -sertifiointia täydennetään usein lisävaatimuksilla: kansallisen tason turvallisuuskehyksillä (esim. Cyber Essentials Plus Yhdistyneessä kuningaskunnassa, BSI IT-Grundschutz Saksassa), sopimuskohtaisilla tietojenkäsittelyvaatimuksilla ja joissakin tapauksissa tiettyjen järjestelmien turvallisuusakkreditoinnilla. ISO 27001 on välttämätön perusta näille lisäkerroksille, ei niiden korvaaja.
Toimittajien tulisi myös olla tietoisia siitä, että jotkin puolustushankintakehykset määrittelevät nyt nimenomaisesti standardin ISO 27001:2022, ja siirtymämääräaika tekee vuoden 2013 versioon perustuvista sertifikaateista enää hyväksymättömiä. Vuoden 2013 standardin mukaan sertifioitujen organisaatioiden oli siirryttävä vuoden 2022 versioon lokakuuhun 2025 mennessä. Jokaista sertifikaattia, joka edelleen viittaa vuoden 2013 standardiin tämän päivämäärän jälkeen, tulisi pitää rauenneena hankintatarkoituksessa.