Page History

1.

Tuotetiimi on toteuttanut ohjelmiston yleisarkkitehtuurille ja pääasiallisille toiminnallisuuksille uhkamallinnuksen noudattaen liitteen 5 ohjeita soveltuvin osin. Tuoteomistaja on kirjallisesti hyväksynyt mahdolliset jäännösriskit. Tuotetiimi on tiketöinyt uhkamallinnuksen toteutuksen sekä sen tuloksena syntyneet (tietoturva)tehtävät. Tämä vaatimus voi täyttyä yhdistelemällä kertaluontoisia uhkamallinnuksia ja tämän prosessin kuvaamia toiminnallisuuskohtaisia pienemmistä uhkamallinnuksista.

2.

Henkilötietojen käsittelyyn liittyvät riskit on arvioitu, ja tuotantoon vietävä kokonaisuus on esitelty tietosuojavastaavalle. Esittely voidaan tehdä esimerkiksi arvopaketin tietosuoja- ja tietoturva-analyysiä tehtäessä.

Henkilötietojen käsittelyyn liittyvät riskit on arvioitu, tietosuojakortti on täytetty ja tarvittaessa myös tietosuojan vaikutustenarviointi on laadittu. Tarvittaessa tuotantoon vietävä kokonaisuus on esiteltävä tietosuojavastaavalle. Esittely voidaan tehdä esimerkiksi arvopaketin tietosuoja- ja tietoturva-analyysiä tehtäessä.

3.

Ohjelmistolle on suoritettu tietosuojavaikutusten arviointi (tietosuoja-asetuksen tarkoittama Data Protection Impact Assessment, DPIA), mikäli se on lakisääteisesti tarpeellista. Suoritettu tietosuojavaikutusten arviointi ja sen tulokset ovat auditoitavissa.

4.

Jos ohjelmisto käsittelee henkilötietoja, ohjelmistosta on olemassa ajantasainen kuvaus henkilötietovirroista ja niiden tallennuspaikoista, henkilötietotyyppikohtaisesti eriteltyinä. Tämä vaatimus on erillinen tietosuojavaikutusten arvioinnista ja sen tulee toteutua kaikille henkilötietoja käsitteleville ohjelmistoille.

5.

Ohjelmiston tietoturvatestaustarpeet on määritelty ja ne on dokumentoitu. Ensisijaisesti testaustarpeet dokumentoidaan tiketteinä tuotteen tehtävälistalla.

Testaus on hyväksytysti suoritettu.

6.

Ohjelmistolle on tehty säännöllinen game day. Game dayssä tunnistetaan ja havaitaan (uusia) riskejä, selvitetään ohjelmiston palautumiskyvykkyys ja koulutetaan tiimien jäseniä pilvioperointiin ja toimintaohjeiden (playbook tai runbook) noudattamiseen. Game day -konseptin omistajuus voi olla esimerkiksi pilvitiimillä.

7.

Ohjelmistosta on olemassa ajantasainen tietoturva-arkkitehtuurikuvaus, joka täyttää minimivaatimukseltaan liitteen 4 vaatimukset.

8.

Muutosoikeudet käyttöpalvelujen ylläpitoon on rajattu vain niille henkilöille, joiden on tarpeen tehdä tuotannonaikaisia toimenpiteitä. Tämä sisältää ajoympäristöjen virtuaalikoneet, käyttöjärjestelmät, orkestrointijärjestelmät, koodivarastot (repositories), automaattisen tuotantoon viennin järjestelmät ja verkon konfiguraatiot. Jos infrastruktuuri on kuvattu koodina, myös versionhallinnan katsotaan kuuluvaksi käyttöpalvelujen ylläpitoon.

9.

Käyttöpalvelujen ylläpitoon liittyvien ympäristöjen (vaatimus 8 yllä) omistajuus ja päivitysperiaatteet on vastuutettu ja kuvattu selkeästi.

10.

Käyttöpalvelut täyttävät niille erikseen asetetut kovennusvaatimukset noudatellen palvelutoimittajan ja palvelun käyttäjän vastuurajoja. Ellei kovennusvaatimuksia ole erikseen määritelty, lähteinä käytetään ensisijaisesti Center for Internet Security Benchmarks -suosituksia (https://www.cisecurity.org/cis-benchmarks/)

11.

Ohjelmiston tuottamat lokit siirretään keskitettyyn lokijärjestelmään.

12.

Ohjelmiston ajallisesti rajoitetut komponentit (kuten varmenteet) sekä salaisuuksien hallinta on dokumentoitu, ja niiden hallinta on siirretty mahdollisen tuotantoa hoitavan tahon haltuun.

12.

Ohjelmiston ajallisesti rajoitetut komponentit (kuten varmenteet) sekä salaisuuksien hallinta on dokumentoitu, ja niiden hallinta on siirretty mahdollisen tuotantoa hoitavan tahon haltuun.

13.

Julkaistavasta koodista on poistettu kommentit ja organisaation sisäiset linkit, jotka paljastavat ohjelmistokehitysprosessiin tai sovelluksessa käytettyihin ratkaisuihin liittyviä tietoja, vaikka tiedot eivät olisi luottamuksellisia tai salassa pidettäviä.

Kommentit voivat paljastaa tiedon murusia, jotka yhdistettynä muuhun tietoon antavat rikollisille arvokasta tietoa hyökkäyksen valmisteluun. Tällaista tietojen keräämistä kutsutaan avointen lähteiden tiedusteluksi (OSINT - open source intelligence).

Julkaistavan koodin kommenteissa kannattaa suosia tiedon minimoinnin periaatetta.

< 6.2 Kriteerit tuotantoon viennin vaatimuksille

7. Tietoturvallisuuden yleisperiaatteet (liite 2) >