Ilmainen e-kirja: NIS2 haltuun hyödyntäen ISO 27001 -käytäntöjä
Lataa e-kirja

Tutustu tehtävään liittyviin vaatimuskehikkoihin tarkemmin

14.3
ISO27 Täysi

ISO 27001 (2013): Täysi

14.3.1
ISO27 Täysi

ISO 27001 (2013): Täysi

8.33
ISO27k1 Täysi

ISO 27001 (2022): Täysi

Muita saman teeman digiturvatehtäviä

Tuotanto-, testaus- ja kehitysympäristöjen erottaminen

Critical
High
Normal
Low

Kehitettävänä, testauksessa ja tuotannossa olevia ohjelmistoja ajetaan eriytetyissä teknisissä ympäristöissä, jotta kehitystyön laatu voidaan varmistaa tuotantoympäristöä mukailevassa ympäristössä ja toisaalta tuotantoympäristöä ei häiritä keskeneräisellä kehityksellä.

Käyttäjien arkaluonteisia tai henkilökohtaisia tietoja ei kopioida ja käytetä kehitysympäristössä.

14.2.6: Turvallinen kehitysympäristö
ISO27 Täysi
12.1.4: Kehitys-, testaus- ja tuotantoympäristöjen erottaminen
ISO27 Täysi
12.5: Tuotantokäytössä olevien ohjelmistojen hallinta
ISO27 Täysi
12.5.1: Ohjelmistojen asentaminen tuotantokäytössä oleviin järjestelmiin
ISO27 Täysi
PR.DS-7: The development and testing environments
NIST

Valmiin määritelmä (engl. definition of done) ja testaussäännöt

Critical
High
Normal
Low

Kehitysyksikkö ylläpitää itse kriteeristöä asioille, joiden täyttyessä tietty työtehtävä voidaan todeta valmiiksi. Kriteerit voivat sisältää mm. katselmointivaatimuksia, dokumentointivaatimuksia ja testausvaatimuksia.

Uutta koodia otetaan käyttöön vasta laajan ja ennalta määritellyt kriteerit täyttävän testauksen jälkeen. Testien olisi katettava käytettävyys, turvallisuus, vaikutukset muihin järjestelmiin ja käyttäjäystävällisyys.

14.2.9: Järjestelmän hyväksymistestaus
ISO27 Täysi
14.2.3: Sovellusten tekninen katselmointi käyttöalustan muutosten jälkeen
ISO27 Täysi
8.29: Tietoturvatestaus kehitys- ja hyväksyntävaiheissa
ISO27k1 Täysi

Sovellusturvallisuuteen liittyvien tietoturvamittarien dokumentointi

Critical
High
Normal
Low

Organisaation on dokumentoitava erityisesti sovellusturvallisuuden tasoa mittaavat tietoturvamittarit. Toteutuksessa on otettava huomioon organisaation itse määrittämät tietoturvatavoitteet sekä muut tietoturvavaatimukset.

Testausaineiston suojaaminen ja tiedon minimointi

Critical
High
Normal
Low

Testaukseen käytettävät tieto- ja muut aineistot olisi valittava huolellisesti ja niitä olisi suojattava.

Tuotantotietoa, joka sisältää henkilötietoja tai muuta luottamuksellista tietoa, ei tulisi käyttää testaustarkoituksiin.

14.3: Testiaineisto
ISO27 Täysi
14.3.1: Testiaineiston suojaaminen
ISO27 Täysi
8.33: Testauksessa käytettävät tiedot
ISO27k1 Täysi

Käyttäjien salasanatietojen salaus

Critical
High
Normal
Low

Käytämme vahvaa salausta salasanojen siirron ja tallennuksen aikana kaikissa kehittämissämme palveluissa.

9.4.2: Turvallinen kirjautuminen
ISO27 Täysi
10.1.1: Salauksen käytön periaatteet
ISO27 Täysi
14.2.5: Turvallisen järjestelmäsuunnittelun periaatteet
ISO27 Täysi
14.1.3: Sovelluspalvelutapahtumien suojaaminen
ISO27 Täysi
8.5: 5 Turvallinen todentaminen
ISO27k1 Täysi

Sovelluspalvelujen julkisen verkkoliikenteen salaus

Critical
High
Normal
Low

Julkisten verkkojen kautta siirrettävää sovelluspalveluihin kuuluvaa tietoa on suojattava vilpilliseltä ja sopimuksen vastaiselta toiminnalta ja luvattomalta paljastumiselta ja muuttamiselta.

Käytämme vahvoja salaus- ja turvallisuusprotokollia (esim. TLS, IPSEC, SSH) suojaamaan luottamuksellisia tietoja niitä siirrettäessä julkisia verkkoja pitkin kehittämiemme IT-palvelujen yhteydessä.

13.2.3: Sähköinen viestintä
ISO27 Täysi
14.1.2: Sovelluspalveluiden suojaaminen julkisissa verkoissa
ISO27 Täysi
14.1.3: Sovelluspalvelutapahtumien suojaaminen
ISO27 Täysi
14.2.5: Turvallisen järjestelmäsuunnittelun periaatteet
ISO27 Täysi
A.11.6: Encryption of PII transmitted over public data-transmission networks
ISO 27018

Koodin katselmoinnin ja julkaisemisen yleiset säännöt

Critical
High
Normal
Low

Koodin katselmointia, hyväksymistä ja julkaisua varten on määritelty yleiset säännöt ja niiden noudattamista valvotaan.

Säännöt voivat sisältää mm. seuraavia asioita:

  • luotu koodi on tarkistettu vasten OWASP-frameworkin yleisiä turvallisen kehittämisen ohjeita
  • koodi on katselmoitu vähintään kahden henkilön silmin
  • nimetty, valtuutettu käyttäjä on hyväksynyt muutokset ennen julkaisua
  • järjestelmän dokumentointi on päivitetty ennen julkaisua
  • muutosten julkaisuajankohta on valittu annettujen ohjeiden mukaisesti, jotta häiriötä liiketoimintaprosesseille syntyy mahdollisimman vähän
  • käyttäjien tarvitsemat ohjeistukset on päivitetty ennen koodin julkaisua

Säännöillä pyritään hallitsemaan uuden ohjelmakoodin julkaisemiseen liittyviä riskejä.

14.2.3: Sovellusten tekninen katselmointi käyttöalustan muutosten jälkeen
ISO27 Täysi
14.2.2: Järjestelmään tehtävien muutosten hallintamenettelyt
ISO27 Täysi
TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri
8.28: Turvallinen ohjelmointi
ISO27k1 Täysi
8.32: Muutoksenhallinta
ISO27k1 Täysi

Valtuutettujen, koodimuutoksia julkaisevien käyttäjien listaus

Critical
High
Normal
Low

Vain ennalta määritellyt, valtuutetut käyttäjät saavat julkaista muutoksia koodiin.

14.2.7: Ulkoistettu kehittäminen
ISO27 Täysi
14.2.2: Järjestelmään tehtävien muutosten hallintamenettelyt
ISO27 Täysi
12.5: Tuotantokäytössä olevien ohjelmistojen hallinta
ISO27 Täysi
12.5.1: Ohjelmistojen asentaminen tuotantokäytössä oleviin järjestelmiin
ISO27 Täysi
8.30: Ulkoistettu kehittäminen
ISO27k1 Täysi

Lähdekoodin pääsynhallinta

Critical
High
Normal
Low

Pääsyä lähdekoodeihin ja niihin liittyviin muihin suunnitelmiin valvotaan, jotta estetään mm. luvattoman koodin lisääminen sekä vältetään tahattomat muutokset. Pääsyoikeuksia jaetaan tarve tietää -periaatteella, eikä esimerkiksi tukihenkilöstölle myönnetä rajattomia pääsyoikeuksia.

Lähdekoodin valvonta voidaan toteuttaa esimerkiksi tallentamalla kaikki koodi keskitetysti asiaan dedikoituun lähdekoodin hallintajärjestelmään.

14.2.6: Turvallinen kehitysympäristö
ISO27 Täysi
9.4.5: Lähdekoodin suojaaminen pääsynhallinnalla
ISO27 Täysi
8.4: Pääsy lähdekoodiin
ISO27k1 Täysi
8.31: Kehitys-, testaus- ja tuotantoympäristöjen erottaminen
ISO27k1 Täysi

Turvallisen kehittämisen säännöt

Critical
High
Normal
Low

Kehitystyötä koskevat yleiset pelisäännöt on laadittu ja ne on hyväksytty kehitystyön johtohenkilöiden toimesta. Sääntöjen toteutumista valvotaan kaikessa organisaatiossa tehtävässä kehityksessä ja ne katselmoidaan vähintään vuosittain.

Turvallisen kehittämisen politiikka voi sisältää mm. seuraavia asioita:

  • kehitysympäristön turvallisuusvaatimukset
  • käytettyjen ohjelmointikielien turvallisen koodaamisen ohjeet
  • turvallisuusvaatimukset ominaisuuksien tai projektien suunnitteluvaiheessa
  • turvalliset ohjelmistovarastot
  • versionhallinnan turvallisuusvaatimukset
  • kehittäjältä vaaditut kyvyt välttää, löytää ja korjata haavoittuvuuksia
  • turvallisten koodausstandardien noudattaminen

Turvallisen kehittämisen sääntöjen noudattamista voidaan vaatia myös avainkumppaneilta.

14.2.1: Turvallisen kehittämisen politiikka
ISO27 Täysi
14.2.5: Turvallisen järjestelmäsuunnittelun periaatteet
ISO27 Täysi
TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri
8.25: Turvallinen kehittämisen elinkaari
ISO27k1 Täysi
8.27: Turvallisen järjestelmäarkkitehtuurin ja -suunnittelun periaatteet
ISO27k1 Täysi

Ulkoistetun kehitystoiminnan seuraamisen ja valvonnan käytännöt

Critical
High
Normal
Low

Vaikka kehitystä ulkoistetaan, meillä säilyy vastuu asianmukaisten lakien noudattamisesta ja hallintakeinojen vaikuttavuuden todentamisesta.

Olemme määritelleet toimintatavat, joiden valvomista seuraamme ja noudattamista edellytämme koko ulkoistusketjussa. Käytännöt voivat sisältää mm. seuraavia asioita:

  • tuotetun koodin katselmointi- ja hyväksymiskäytännöt
  • todistusaineisto kumppanin suorittamista testaustoimista
  • viestintäkäytännöt
  • sopimukselliset oikeudet auditoida kehitysprosessia ja hallintakeinoja
  • dokumentointivaatimukset koodin tuottamisesta
14.2.7: Ulkoistettu kehittäminen
ISO27 Täysi
DE.CM-6: External service provider activity monitoring
NIST
8.30: Ulkoistettu kehittäminen
ISO27k1 Täysi
8.28: Turvallinen ohjelmointi
ISO27k1 Täysi

Palautusstrategia

Critical
High
Normal
Low

Olemme sopineet ja kirjanneet käytännöt, joiden avulla aiempi versio ohjelmistosta voidaan palauttaa, ennen julkaisujen toteuttamista.

12.3: Varmuuskopiointi
ISO27 Täysi
12.3.1: Tietojen varmuuskopiointi
ISO27 Täysi
14.2.2: Järjestelmään tehtävien muutosten hallintamenettelyt
ISO27 Täysi
12.5: Tuotantokäytössä olevien ohjelmistojen hallinta
ISO27 Täysi
12.5.1: Ohjelmistojen asentaminen tuotantokäytössä oleviin järjestelmiin
ISO27 Täysi

Muutostenhallintamenettely tietojenkäsittelypalveluihin tehtäville merkittäville muutoksille

Critical
High
Normal
Low

Riittämätön muutosten hallinta on yleinen syy tietojenkäsittelypalvelujen toiminta- ja turvallisuushäiriöille.

Organisaation on dokumentoitava muutostenhallintaprosessi, jota on noudatettava aina tehtäessä merkittäviä tietoturvallisuuten vaikuttavia muutoksia itse kehitettyihin digipalveluihin tai muihin tietojenkäsittelypalveluihin. Prosessi sisältää vaatimukset mm. seuraaville asioille:

  • muutoksen määrittely ja dokumentointi
  • riskien arviointi ja tarvittavien hallintakeinojen määrittely
  • muutoksen muu vaikutusten arviointi
  • testaus ja laadunvarmistus
  • muutoksen julkaisun hallittu toteutus
  • muutoslokin päivittäminen
14.2.2: Järjestelmään tehtävien muutosten hallintamenettelyt
ISO27 Täysi
14.2.4: Ohjelmistopakettien muutoksia koskevat rajoitukset
ISO27 Täysi
PR.DS-6: Integrity checking
NIST
TEK-17: Muutoshallintamenettelyt
Julkri
8.32: Muutoksenhallinta
ISO27k1 Täysi

Automatisoitu turvallinen koodin käyttöönotto ja julkaisu

Critical
High
Normal
Low

Organisaation on määritettävä keinot turvalliseen ohjelmiston käyttöönottostrategiaan. Keinot on automatisoitava, jos mahdollista.

Secure Software Development Life Cycle (SSDLC) -prosessin suunnittelu

Critical
High
Normal
Low

Organisaation on määriteltävä ja otettava käyttöön Secure Software Development Life Cycle (SSDLC, ohjelmistokehityksen elinkaari) -prosessi ohjelmistokehityksessä.

SSDLC-prosessin ensimmäisen vaiheen tulee olla tietoturvavaatimusten määrittely, joka varmistaa tietoturvanäkökulmien tulevan integroiduksi kehitettäviin palveluihin heti luomisvaiheesta lähtien.

SSDLC-prosessin on suositeltavaa sisältää vähintään seuraavat vaiheet:

  • A - Koulutus
  • B - Vaatimusten kuvaaminen
  • C - Suunnittelu
  • D - Kehitys
  • E - Turvallisuustestaus
  • F - Julkaisu
  • G - Ongelmiin vastaaminen
PR.IP-2: A System Development Life Cycle
NIST

Tuntemattoman koodin ajaminen turvallisesti

Critical
High
Normal
Low

Kaikki koodi tuntemattomasta alkuperästä on ajettava ns. sandbox-ympäristössä eli eristettynä organisaation muista laitteista ja verkoista. Tällä estetään sen pääsy organisaation resursseihin ilman erityistä lupaa käyttäjältä. Tämä sisältää:

  • Muut ohjelmistot omissa sandboxeissaan
  • Tietovarastot, jotka säilyttävät esimerkiksi kuvia tai dokumentteja
  • Oheislaitteita, kuten kamera, mikrofoni ja GPS
  • Pääsy paikalliseen verkkoon.

Kriittisten ohjelmistojen toteutuksen säännöllinen tarkastaminen

Critical
High
Normal
Low

Kriittiset tietojärjestelmien tai tarjottujen digipalvujen toteutus tarkastatetaan säännöllisesti hyödyntäen ennalta määriteltyä luotettavaa standardia tai turvallisen ohjelmoinnin ohjetta.

Tarkentavia ohjeita ovat mm. VAHTI Sovelluskehityksen tietoturvaohje (VAHTI 1/2013), OWASP Application Security Verification Standard (ASVS) sekä Kyberturvallisuuskeskuksen ohje "Turvallinen tuotekehitys: kohti hyväksyntää".

TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri

Hyväksyntä tiedon omistajalta tuotantotiedon käyttämiseksi testaustarkoituksissa

Critical
High
Normal
Low

Organisaation täytyy hankkia hyväksyntä tiedon omistajalta, ja hallinnoitava mahdolliset riskit, ennen sen käyttämistä testaustarkoituksessa.

Sisäänrakennettu ja oletusarvoinen tietosuoja järjestelmäsuunnittelussa

Critical
High
Normal
Low

Organisaation on luotava toimintamallit, joiden avulla tietosuoja, oikeaoppinen henkilötietojen käsittely ja tietosuojavaatimusten huomiointi on oletusarvoisesti mukana uusien järjestelmien, digipalvelujen tai toimintaproessien suunnittelussa ja kehittämisessä niiden ensihetkistä alkaen.

Tätä kutsutaan sisäänrakennetun ja oletusarvoisen tietosuojan periatteeksi (privacy by design). Tärkeä osa tämän periaatteen soveltamista on lisäksi järjestelmien oletusasetusten konfigurointi niin, että ne minimoivat henkilötietojen käsittelyn ja noudattavat kaikkia alueellisia lakeja / määräyksiä.

Sisäänrakennettu ja oletusarvoinen tietoturva järjestelmäsuunnittelussa

Critical
High
Normal
Low

Organisaation on luotava toimintamallit, joiden avulla tietoturvallisuus ja turvallisuusvaatimusten huomiointi on oletusarviosesti mukana uusien järjestelmien, digipalvelujen tai toimintaproessien suunnittelussa ja kehittämisessä niiden ensihetkistä alkaen.

Tätä kutsutaan sisäänrakennetun ja oletusarvoisen tietoturvan periatteeksi (security by design). Tämän toimintatavan yhtenä tuloksena suunnitteluun liittyvästä dokumentaatiosta tulisi käydä selkeästi ilmi, millä toimenpiteillä tietoturvallisuudesta huolehditaan.

Tietojärjestelmän riskinarviointien käyttö erottamistarpeiden määrittämiseksi

Critical
High
Normal
Low

Organisaation IT-järjestelmät käyvät läpi riskinarvioinnin, jonka perusteella määritetään, onko tarpeen jakaa ne kehitys-, testaus- ja käyttöjärjestelmiin.

Segmentointi toteutetaan sitten riskinarvioinnin tulosten perusteella.

Testaukseen käytetyn tuotantotiedon erityiset suojauskeinot

Critical
High
Normal
Low

Tuotantotiedon käyttöä olisi vältettävä testaustarkoituksissa. Mikäli luottamuksellisia tietoja käytetään testauksessa, seuraavia suojausmenettelyjä olisi käytettävä:

  • kaikki arkaluonteiset yksityiskohdat olisi joko poistettava tai muokattava turvalliseksi (esim. henkilötietojen anonymisointi)
  • testattavissa järjestelmissä sovelletaan yhtä tiukkaa pääsynhallintaa, kuin tuotannossa 
  • tuotantotiedon kopioiminen testausympäristöön tehdään vain erillisellä valtuutuksella
  • tuotantotiedot poistetaan testausympäristöstä välittömästi testauksen valmistuttua
14.3: Testiaineisto
ISO27 Täysi
14.3.1: Testiaineiston suojaaminen
ISO27 Täysi
8.33: Testauksessa käytettävät tiedot
ISO27k1 Täysi

Kriittisen koodin tunnistaminen ja tarkastaminen

Critical
High
Normal
Low

Määrittelyä turvallisuuden kannalta kriittisestä koodista eri palvelujen suhteen pidetään yllä. Uusia kriittisen koodin osasia pyritään jatkuvasti tunnistamaan ja uudet päivitykset tarkistetaan erityisen tarkasti kriittistä koodia koskevien muutosten suhteen. Tavoitteena on pitää turvallisuusheikkouksien todennäköisyys mahdollisimman pienenä.

14.2.3: Sovellusten tekninen katselmointi käyttöalustan muutosten jälkeen
ISO27 Täysi
14.2.5: Turvallisen järjestelmäsuunnittelun periaatteet
ISO27 Täysi
14.2.9: Järjestelmän hyväksymistestaus
ISO27 Täysi
8.27: Turvallisen järjestelmäarkkitehtuurin ja -suunnittelun periaatteet
ISO27k1 Täysi

Tilapäisten kirjautumistietojen turvallinen asettaminen

Critical
High
Normal
Low

Tilapäisten tunnistautumistietojen olisi oltava yksilöllisiä, eivätkä ne saisi olla arvattavissa esimerkiksi käyttäjän tiedoista päättelemällä.

9.2.4: Käyttäjien tunnistautumistietojen hallinta
ISO27 Täysi
5.17: Tunnistautumistiedot
ISO27k1 Täysi

Julkaisulokin ylläpitäminen

Critical
High
Normal
Low

Kaikista tuotanto- tai asiakaskäytössä oleviin ohjelmistoihin tai omiin IT-palveluihin tehdyistä päivityksistä olisi pidettävä tapahtumalokia.

12.5: Tuotantokäytössä olevien ohjelmistojen hallinta
ISO27 Täysi
12.5.1: Ohjelmistojen asentaminen tuotantokäytössä oleviin järjestelmiin
ISO27 Täysi
8.19: Ohjelmistojen asentaminen tuotantokäytössä oleviin järjestelmiin
ISO27k1 Täysi

Uusien tietotekniikkajärjestelmien kehittämisvaatimusten kattavuuden varmistaminen

Critical
High
Normal
Low

Organisaatio varmistaa, että uuden järjestelmän kehittämisen vaatimusmäärittelyt kattavat seuraavat näkökohdat:

  • tietoturvavaatimukset
  • Toimittajan suositukset ja parhaat käytännöt turvallista konfigurointia ja toteutusta varten.
  • Yleiset parhaat käytännöt ja tietoturvaohjeet
  • Vikasietoiset mekanismit (suunniteltu palaamaan turvalliseen tilaan vian tai toimintahäiriön sattuessa).

Uudet kehitetyt järjestelmät tarkistetaan erittelyjen perusteella ennen tuotantokäyttöön siirtymistä.