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

Olemme dokumentoineet muutostenhallintaprosessin, jota on noudetettava aina tehtäessä merkittäviä tietoturvallisuuten vaikuttavia muutoksia kehitettyihin järjestelmiin. 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

Organisaatio on määritelly prosessin, jonka perusteella tunnistetut tekniset haavoittuvuudet käsitellään. Haavoituvuuden tunnistamisen jälkeen:

• yksilöidään haavoittuvuudeen liittyvät riskit ja tarvittavat toimenpiteet (esim. järjestelmän paikkaus tai muut hallintatehtävät)
• aikataulutetaan tarvittavat toimenpiteet
• dokumentoidaan kaikki toimenpiteet

Staattiset skannaukset koodiin ovat ensimmäinen askel riskialttiiden haavoittuvuuksien havaitsemiseksi. Kun palvelu on otettu käyttöön, se kuitenkin altistuu uudenlaisille hyökkäyksille (esim. cross-site scripting tai tunnistautumisen ongelmat). Näitä voidaan pyrkiä tunnistamaan tunkteutumistestauksella.

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ä.

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

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ä.

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ä. 

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

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ä. 

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. 

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.

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ä.

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.

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

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

Teemme säännöllisesti automatisoitua haavoittuvuusskannausta, jossa ohjelmisto etsii tietokoneista, verkoista tai sovelluksista tunnettuja haavoittuvuuksia.

Aina hankittaessa tai kehitettäessä uusia tietojärjestelmiä noudatetaan ennalta määritettyjä turvallisuussääntöjä huomioiden järjestelmän prioriteetti. Sääntöjen avulla varmistetaan, että tietojen käsittelyn turvallisuus järjestelmässä on varmistettu riittävin toimenpitein.