Kaikki ymmärtävät, että täydelllistä ja murtovarmaa järjestelmää ei ole olemassakaan. Kiperämpi kysymys on, miten turvallisuuden taso määritetään riittäväksi ja realistiseksi? Miten asiakas voi todentaa turvallisen ohjelmistokehityksen olemassaolon? Entä voiko turvallisuutta mitata?
Ohjelmistojen toimitusketjuihin kohdistuvat hyökkäykset ovat lisääntyneet, ja yritysten on voitava luottaa käyttämiinsä palveluntarjoajiin. Pelkkä lupaus ”tietoturva-asioiden huomioinnista” ei enää riitä. Erityisesti EU:n NIS2-direktiivi vaatii kriittisten alojen toimijoita (ja heidän toimittajiaan) huolehtimaan turvallisista toimintatavoistaan.
Tämä tarkoittaa, että yrityksen on pystyttävä osoittamaan, että sen käyttämät ohjelmistot ja palveluntarjoajat noudattavat asianmukaisia tietoturvakäytäntöjä.
Secure by Design ohjaa turvalliseen prosessiin
Center for Internet Security (CIS) on julkaissut yhteistyössä SAFECoden kanssa Secure by Design (SbD) -viitekehyksen riittävän turvallisuustason määrittelyyn ja seurantaan. Viitekehys rakentuu NIST:n Secure Software Development Framework (SSDF, SP 800-218) -standardin päälle, joka on laajasti hyväksytty viitekehys turvallisen ohjelmistokehityksen käytännöille. Tavoitteena on varmistaa, että turvatoimet ovat oikeassa suhteessa riskeihin ja liiketoiminnan tarpeisiin. CIS auttaa yrityksiä siirtymään “toivotaan toivotaan” -mallista hallittuun riskienhallintaan.
NIS2:n näkökulmasta SbD on erinomainen tapa osoittaa, että yritys on toiminut oikeasuhteisesti ja asianmukaisesti.
Kuusi osa-aluetta kattavat ohjelmiston koko elinkaaren
CIS-opas nostaa esiin kuusi kriittistä osa-aluetta, jotka auttavat täyttämään myös NIS2-vaatimukset:
1. Turvallinen suunnittelu. Ohjelmiston toiminnot, rakenne ja arkkitehtuuri, jotka mahdollistavat turvallisen toteutuksen.
2. Turvallinen kehitysprosessi. Ohjelmiston komponenttien valmistusprosessi ja varmistus siitä, ettei niihin jää järjestelmää vaarantavia heikkouksia.
3. Turvalliset oletusasetukset. Prosessi, jolla luodaan turvalliset konfiguraatiot ja asetukset, jotka ovat käytössä oletuksena kaikissa asennuksissa.
4. Toimitusketjun turvallisuus. Prosessi, jolla varmistetaan, etteivät kolmansien osapuolten komponentit (kuten kirjastot) vaaranna tuotteen tai palvelun turvallisuutta.
5. Koodin eheys. Toimenpiteet, joilla suojaudutaan pahantahtoisilta muutoksilta (esim. koodin peukaloinnilta) kehityksen ja valmiin ohjelmiston toimituksen aikana.
6. Haavoittuvuuksien hallinta. Vakioidut toimintatavat, jotka tukevat haavoittuvuuksien raportointia ja nopeaa korjaamista sekä varmistaa, että opit hyödynnetään tuotteiden ja prosessien parantamiseen.
Secure by Design (SbD) on organisaation vastuulla
Turvallinen ohjelmistokehitys ei ole pelkästään ”tietoturvatiimin” tai koodareiden vastuulla. Se tulee huomioida organisaation eri tasoilla:
Johto ja tuoteomistajat: NIS2 korostaa johdon vastuuta. He päättävät resursoinnista ja hyväksyvät jäännösriskit.
Kehittäjät: Vastaavat turvallisista koodauskäytännöistä.
Hankinta: Vastaa siitä, että toimittajilta vaaditaan näyttöä turvallisesta kehityksestä jo kilpailutusvaiheessa. Käytännössä tämä tarkoittaa esimerkiksi: SBOM (Software Bill of Materials) -luettelo käytetyistä komponenteista, dokumentoitu haavoittuvuuksien hallintaprosessi sekä kuvaus käytetyistä kehitystyökaluista ja tietoturvatestauksesta.
Miten määritellä se kuuluisa ”riittävä taso”?
Secure by Design on yrityksen toimintamalli, ei jotain mitä koodataan tuotteeseen. Kun tunnustamme täydellisyyden mahdottomuuden, voimme keskittyä siihen, mikä on oikeasti merkityksellistä: hallittuun riskiin, lakisääteisten velvoitteiden täyttämiseen ja läpinäkyvään arvoa tuottavaan toimintaan.
Riittävä taso on myös organisaatiokohtainen. CIS-opas jakaa organisaatiot kolmeen kehitysryhmään (DG1–DG3) sen mukaan, minkälaisia ohjelmistoja organisaatio käyttää ja kehittää. Ryhmän DG1 yritykset käyttävät pääosin valmissovelluksia, DG2 yhdistelee räätälöityä ja kolmannen osapuolen koodia, ja DG3 investoi merkittävästi omaan ohjelmistokehitykseensä. Esimerkiksi pieni startup, joka myy omaa SaaS-tuotettaan, voi olla DG3, kun taas suuri yritys, joka pyörittää liiketoimintaansa pelkillä valmissovelluksilla, voi olla DG1. Vaatimukset ja odotettavat todistusaineistot skaalautuvat kehitysryhmän mukaisesti, mutta perusodotukset koskevat kaikkia.
CIS:n SbD-viitekehys muuttaa epämääräisen tietoturvakeskustelun faktapohjaiseksi ja mitattavaksi. Silloin päätöksenteko perustuu tietoon, mikä on olennaista myös NIS2:n näkökulmasta.
Ota yhteyttä, kun haluat keskustella turvallisesta ohjelmistokehityksestä! Voimme auttaa teitä sen toteutuksessa ja hallinnassa.