6 vinkkiä turvallisen ohjelmiston tekoon



Turvallisen ohjelmiston tuottaminen poikkeaa tavallisesta ohjelmistokehityksestä yhtä paljon kuin kassakaapin valmistaminen Ikean vaatekaapin kasaamisesta. Vaikka tehtävä on päällisin puolin sama, yhteisiä nimittäjiä ei juuri ole.

Suuri osa turvallisen ohjelmiston kehittämisen nyrkkisäännöistä ovat tuttuja muutenkin: hyvin suunniteltu on puoliksi tehty, kokeneet kehittäjät tekevät vähemmän virheitä ja käytössä koetut perinteiset työkalut sopivat uusia trendituotteita paremmin turvatuotteiden tekoon. Lisäksi turvallisella kehittämisellä ei ole juuri merkitystä, ellei tuotteen perään katsota koko sen elinkaaren ajan.

Seuraavat neuvot eivät sen sijaan ole niin itsestäänselviä, vaikka kehittäminen olisi muuten hyvin näpeissä:

1. Älä tee tietoturvaa väkisin

Parhaat softaideat eivät edellytä kovin hurjaa luottamusta tuotteen turvallisuuteen. Monet uudet tuotteet on tehty niin, että vaikein turvaosuus on suosiolla jätetty toiseen palveluun, jolloin itse tehty osio voi jäädä vaatimattomammalle turvatasolle. Tällaisia hyviä ulkopuolisia tunnistautumis- tai maksamisratkaisuja ovat esimerkiksi:

2. Älä jätä kynttilää vakan alle

Nosta turva-asiat etualalle, jos et voi niitä välttää. Jos juuri turvallisuus on ostajalle yksi tärkeistä valintakriteereistä, nosta turvan hyvä taso esiin kaikessa toiminnassa. Toisaalta tuotteet, jotka ovat selvästi turvallisempia kuin niiden asiakkaat haluavat, jäävät markkinoilla niiden tuotteiden jalkoihin, joille on osattu valita oikea turvataso. Hyviä esimerkkejä onnistuneista turvallisista tuotteista ovat:

  • Skype (turvallinen puhelu Internetissä),
  • PayPal (turvallinen luottokorttimaksaminen),
  • sekä toki erilaiset tietoturvaihmisille tehdyt tuotteet, kuten suomalaiset F-Securen, SSH:n ja Stonesoftin tuotteet.

3. Myy säästöjä, älä turvaa

Parhaat turvatuotteet tekevät halvasta ratkaisusta turvallisen ja säästävät roppakaupalla rahaa. Internetin yli tehdyt VPN-yhteydet ovat tuhansia kertoja halvempia kuin vanhat kiinteät yhteydet toimistojen välillä. Jos ratkaistava ongelma on riittävän arvokas, turvaosion voi tehdä huolella.

4. Tee valtakunnansalaisuuksille kassakaappi

Jos tärkeää tietoa on käsiteltävä, se pitää tehdä niin pienessä osassa ohjelmistoa kuin mahdollista. Esimerkiksi sosiaaliturvatunnusten käsittely- ja tallennuskoodia ei pidä levitellä ympäri ohjelmistoa, vaan se pitää säilyttää ainoastaan harvoissa ja rajatuissa kohdissa.

5. Käytä Abloy-lukkoja

Älä tee itse salausta tai muita vaativimpia tietoturvan osia vaan hanki ne valmiina ja testattuina ratkaisuina. Ohjelmiston turvallisuuden pitää perustua valmiisiin ja varmasti toimiviin komponentteihin, sillä eihän arvokiinteistöillekään suunnitella uusia lukkoja. Hyviä turvaohjelmistoja saa sekä kaupallisina tuotteina että avoimen  lähdekoodin ratkaisuina.

6. Oven kolmas lukko on usein turha

Tietoturva-asioissa joutuu aina valitsemaan mitä tehdään ja mitä jätetään tekemättä. Vain poikkeuksellisissa sotilassovelluksissa voidaan tehdä kaikki asiantuntijoiden kaipaamat turvatoimet. Liika panostus yhteen turvan osa-alueeseen on usein merkki väärästä resurssien suuntaamisesta.

Tietoturvallisen ohjelmiston tekeminen vaatii pitkällistä syventymistä. Suosittelen seuraamaan alan ajattelijoiden tajunnanvirtaa Twitterin kautta, he puolestaan nostavat esiin sekä alan uusimpia trendejä että vanhoja klassikoita omassa virrassaan. Itse seuraan Twitterissä muun muassa seuraavia tietoturvan kovia luita:

Tietoturvallisen ohjelmiston rakentaminen on yhtä vaikeaa kuin menestyselokuvan tuottaminen. Harvat siinä onnistuvat, mutta onnistujat palkitaan ruhtinaallisesti.

2 kommenttia artikkeliin ”6 vinkkiä turvallisen ohjelmiston tekoon

  1. Kiitos Petri mielenkiintoisesta artikkelista.

    Jäin miettimään, vastaako tietoturvallisen ohjelmiston kehittäminen todella menestyselokuvan tuottamista, vai olisiko se kuitenkin normaali osa nykyaikaista ohjelmistokehitystä?

    Pohdin myös onko hyvin suunniteltu puoliksi tehty, vai täysin tekemättä? Itse pyrkisin validoimaan tietoturvan hypoteesit mahdollisimman nopeasti ja turvallisesti todellista vastaavassa käyttöympäristössä, jossa tuntemattomia (emergenttejä) muuttujia on mahdollista havaita toisin kuin suunnittelupöydän ääressä.

    Mahtavan menestyksekästä alkanutta vuotta!

  2. Hyvä blogipostaus Petri!

    Nykyisin kai ehkä ennemmin tulisi puhua palvelusta kuin ohjelmistosta. Valtaosa ohjelmistoistahan alkaa sisältää erilaisia palveluelementtejä tai olla varsinaisia palveluja, joissa ohjelmisto toteuttaa toki ratkaisevaa osuutta.

    Tietoturvahan tulisi ottaa huomioon jo projektin alkaessa kartoittamalla tärkeät tietovarannot ja prosessit, joita sitten pystyttäisiin suojaamaan tehokkaasti suunnittelemalla se tietoturva ihan alusta pitäen ohjelmistoon, ja arvioimalla niihin kohdistuvia uhkia. Pidin Larin kommentista tavattomasti. Oikealla asialla ollaan.

    Niin kuin Petri totesitkin suuri osa ohjelmistoista ja palveluista ei kaipaa erityista tietoturvatoiminnallisuutta, mutta se päätös kriittisyydestä tulisi tehdä niiden vaikutusten perusteella mitä ohjelmiston tietoturvan pettäessä voi aiheutua. Näin ei tulisi laitettua sitä kolmatta lukkoakaan.

    Osa palveluista voi joutua täyttämään vaativiakin vaatimuksenmukaisuusvaatimuksia, jollainen esimerkiksi on luottokorttimaksamiseen liittyvät PCI-vaatimukset. Nämä vaatimukset tulisi tunnistaa jo silloin kun päätetään ohjelmistoprojektin aloittamisesta, sillä niiden kustannusvaikutukset voivat olla ohjelmiston koko elinkaaren aikana merkittävät – myös tuotannossa. PCI on tästä hyvä esimerkki.

    Vaikutuksia arvioitaessa tulisi miettiä suoria taloudellisia menetyksiä sekä mahdollisia vaikutuksia yrityksen maineeseen ja muuhun toimintaan.

    Hieno oivallus on antaa osa ratkaisuista siihen erikoistuneiden tahojen toimitettavaksi tai palveltavaksi. Tätähän voi myös soveltaa ohjelmistokehityksessä ja käyttää tietoturvan ammattilaisia apuna ohjelmiston tietoturvallisuuden suunnittelussa ja toteuttamisessa, ja sen toteuttamisen jälkeen tietturvallisuuden varmistamisessa tietoturvatestauksella. Tietoturvatestaushan yleisemmin mielletään tietoturvallisuudeksi, vaikka sen tarkoitus on varmentaa jo toteutetun ohjelman tietoturvallisuus.

    Tietoturvaratkaisuja todellakin on jo nykyään kaikkiin tavanomaisiin tarpeisiin, ja vain todella harvoin tulisi ryhtyä itse toteuttamaan omaa lukkoa.

    Salaisuuksien säilyttämisessä olisi hyvä myös miettiä, tarvitaanko todella kaikkea järjestelmään kerättäväksi ajateltua tietoa? Voidaanko osa järjestelmän tiedoista poistaa vaivattomasti kun niitä ei enää tarvita? Monessa järjestelmässä varmaan on suuri määrä käyttäjiä, jotka eivät ole viimeiseen puoleen vuoteen käyttäneet palvelua. Mikäli käyttäjän elinkaarenhallintaa ei olla etukäteen mietitty, käyttäjäkannan perkaaminen voi olla hankala tehtävä vuosien jälkeen, mikäli siihen jostain syystä päädytään.

    Tuotannossa olevan ohjelmiston tietoturvallisuudesta tulisi myös huolehtia. On olemassa palveluja, joiden avulla voidaan valvoa eri tavoin, että myös ohjelmistokehityksen jälkeen tuotannossa oleva sovellus täyttää tietoturvakriteerit. Ohjelmiston tietoturvaaminen ei siis jää ohjelmistokehitykseen, ja ohjelmistokehittäjillä tulisikin olla valmiudet reagoida tietoturvapoikkeamiin myös ohjelmiston tuotantovaiheessa korjaten ja parantaen ohjelmiston tietoturvaa tukisopimuksen SLAn puitteissa.

    On huomattavaa, että niin kuin ohjelmiston tukipalvelut yleisestikin, niin tietoturvan tukeminen on pitkäjänteistä työtä ja parhaiten siihen pystytään vaikuttamaan aloittamana tietoturvallisuuden suunnittelu jo projektin alkutaipaleella.

    Tämä kaikki tulisi ottaa huomioon myös silloin, kun ohjelmisto tai palvelu ostetaan kolmannelta osapuolelta. Hankinnan aikana tehtävä tietoturvallisuuteen tulisi kiinnittää yhtä paljon huomiota kun siinä tapauksessa, että ohjelmisto tehtäisiin itse. Nyt vain ostajan tulisi pystyä artikuloimaan selkeästi se tietoturvan taso, jota itse on hakemassa, ja varmistuttava siitä, että tämä taso tulee valvotusti toteutettua. Tässäkin tapauksessa alan ammattilaisesta varmasti on hyötyä niin ostajalle kuin toimittajallekin.

    Kommentti venähti valitettavan pitkäksi – ja tarkoitus olikin enemmän taustoittaa tätä kirjoitusta, joka on iskevästi kirjoitettu – toisin kuin tämä kommentti. 🙂

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *