DevSecOps – Tietoturvatekemisen seuraava taso – Ideologinen harha vai totta?
June 24, 2019
DevOps, ilman ”Sec”-osuutta, on käytössä varsin yleisesti palvelu- ja tuotekehityksessä tänä päivänä. Kun kyseessä on esimerkiksi digiprojekti, siihen liittyy hyvin usein jonkinasteinen ohjelmistokehitys ja sitä tehdään pääsääntöisesti hyödyntäen nykyaikaisia ketteriä kehitystapoja.
Tietoturvatietoisuus on kasvanut vuosien varrella, eikä yrityksistä löydy enää projektipäällikköä, joka ei tiedostaisi tietoturvan olevan riskikartalla kärkisijoilla. Perinteisesti tietoturva on otettu huomioon käyttäen, joko omia tai ostettuja, tietoturva-asiantuntijoita valmiin tuotteen tai palvelun testauksessa ja turvatason tarkastelussa. Usein tarkastelu on hoksattu tehdä liian myöhään tuotteen tai palvelun ollessa jo menossa tuotantoon.
DevSecOps on suhteellisen uusi käsite kehittäjien sanavarastossa. DevSecOps:ssa tietoturvakulma tuodaan mukaan tuotekehitykseen jatkuvana operaationa, jolloin tietoturvavaatimukset muuttuvat tuotteen tai palvelun natiiviksi osaksi kehitysaikana. Samaan aikaan, koko kehityshenkilöstö oppii suunnittelemaan tuotteen lähtökohtaisesti turvalliseksi – Secure-By-Design.
Kertaluontoiset tietoturvatarkastukset eivät enää riitä
Käytännössä tietoturvatekemisen sulauttaminen jatkuvaksi rutiiniksi on projekteissa tänä päivänä kuitenkin vielä lasten kengissä. Tietoturva itsessään otetaan usein vakavasti, mutta toteutus tapahtuu perinteisellä tavalla tuotteen tai palvelun ollessa jo viittä vaille valmis.
Syy tähän on monitahoinen. Kyberturvan ammattilaiset ovat hioneet prosessinsa perinteisen tavan mukaiseksi – jos asiakas tilaa kertaluontoisia tutkimuksia, niitä toki tehdään ja toimitetaan. Tämän jälkeen sitten palataan kirjoituspöydän ääreen ja aloitetaan korjaustoimenpiteet. Ideaalitilanteessa projektin loppupuolella tapahtuvat tietoturvatarkastukset olisivat vain rutiininomainen lopputarkastus jo valmiiksi tietoturvallisen tuotteen tai palvelun hyväksymiseksi tuotantoon.
Ketä vallitsevasta tilanteesta voi syyttää? Tietoturva on varsin monitahoinen asia, jossa yksi osaaja ei voi käsitellä kaikkia tietoturvan osa-alueita. Joku tietää tietosuojasta, toinen turvallisesta tavasta toteuttaa vaikkapa tiedonsiirtoratkaisu langattomasti – yksi henkilö ei näitä kaikkia voi syvällisesti hallita. Tärkeää on, että tietoturva on ylipäätään otettu keskeiseksi osa-alueeksi tuotteita ja palveluita kehitettäessä. Silti, DevSecOps-kulttuurin sisäänajo organisaatiossa tekisi projektinhallinnasta ketterämpää ja vähemmän yllätyksiä aiheuttavaa.
Security Lead mukaan seremonioihin!
Oma kokemukseni pyrkimyksestä ottaa tietoturva kiinteäksi osaksi kehitystä on kaksijakoinen. Insinöörin aivot miettivät, että miksi ihmeessä kukaan haluaisi tehdä tietoturvatutkimusta vasta lähellä tuotteen valmistumista, koska toteutuksesta löytyy varmasti korjattavaa. Hyvin suurella todennäköisyydellä projekti tulee myöhästymään tavoitteestaan, jos tuote tai palvelu palaa takaisin kehitystiimin työpöydälle korjattavaksi. Kannattaisi tehdä tietoturvatutkimuksia ja tuotemuutoksia pitkin matkaa.
Kuitenkin, projekteissa vallitseva tapa on tehdä tietoturvatutkimukset kertaluontoisina tutkimuksina. Näin ainakin siinä tapauksessa, että palvelu ostetaan ulkopuoliselta toimittajalta. Sprinttien suunnittelupalavereihin, aamupalavereihin tai katselmointipalavereihin on yllättävän hankala saada henkilöitä paikalle osaajien useiden asiakastoimeksiantojen vuoksi – tai sitten käy niin, että toimittaja laittaa armeijan henkilöitä palavereihin, mikä johtaa tarpeettomaan kustannusten kasvuun. Yhtälö ei käytännössä toimi ilman perinteisen toimintamallin murtamista.
Luotan kuitenkin siihen, että DevSecOps voi toimia. Ehkäpä valveutunut Security Lead olisi ratkaisu asiaan. Jos tällainen tietoturvan moniosaaja osallistuisi seremonioihin ja jakaisi sitten tahollaan tehtäviä spesialisteille, voisi lopputulos olla halutunlainen kasvattamatta liiaksi palavereissa istuvien määrää.
Projektit etenevät aina jonkinasteisissa vaiheissa. Projektin alkupuolella ei voida tehdä esimerkiksi penetration-testausta, jos testattavan tuotteen kehittäminen aloitetaan nollasta. Nämä kaverit tulevat mukaan myöhemmin. Taas arkkitehtuuria suunniteltaessa kannattaa heti valita tietoturvalliset komponentit käyttöön, jos ollaan tekemässä vaikkapa pilviratkaisua. Silloin pelikentältä saattaisi löytyä pilviosaajan lisäksi tiedonsiirtoon sekä autentikointiin perehtynyt tietoturva-asiantuntija.
Security Leadin tehtävä olisi huolehtia siitä, että oikeat henkilöt olisi allokoituna oikeaan aikaan projektissa.
Ratko ongelmat välittömästi – projekti ja asiakas kiittää
DevSecOps on DevOps:n seuraava askel, jonka läpi ajaminen tuotekehityksessä tuottaa väistämättä muutoksia tuotteen tai palvelun toteutussuunnitelmaan. Positiivista asiassa on se, että ollaan jatkuvasti tietoisia tietoturvan tasosta. Korjaavien liikkeiden tekeminen jatkuvasti kehitystä tehtäessä vähentää mahdollisuutta joutua yllätetyksi projektin aikana.
DevSecOps-kehitysmalli säästää myös rahaa, koska tuote tai palvelu rakennetaan vain kerran. Se siis rakennetaan tietoturvan kannalta kerralla oikein. Kahteen tai useampaan kertaan koodattu applikaatio tai markkinoilta vedetty tietoturvaton tuote kustantaa pahimmassa tapauksessa yrityksen maineen verran. Tätä tilannetta ei kukaan halua.
Projektin johtajan näkökulmasta DevSecOps toimii myös verenpainelääkkeenä laskien pulssia ja vähentäen yllätyksiä projektin aikana. Kenelläkään ei liene ole mitään sitä vastaan, jos projekti menee maaliin täysin pistein ja ajallaan!
