Kollegani Aapo Kettunen kirjoitti äskettäin sovellusjakeluiden parhaista käytännöistä. Luotan hänen näkemykseensä asiassa täysin, mutta Aapon teksti sai minut ajattelemaan sovellusten päivitysten kokonaisuutta.

Kirjoituksessaan Aapo haki vastauksia muun muassa seuraaviin kysymyksiin:

  • Miten sovellusten jakelu kannattaa tehdä?
  • Minkälainen on hyvä jakeluprosessi?

Minulla on ollut etuoikeus päästä keskustelemaan aiheesta todella monen organisaation kanssa Suomessa. Toimin paljon myynnin tukena, joten sovellusten päivittämisestä on tullut vaihdettua ajatuksia eri alojen ja eri kokoisten organisaatioiden edustajien kanssa. Kokemusteni mukaan suomalaiset ovat erittäin hyvin perillä sovellusten päivittämisestä ja ymmärtävät sillä olevan merkittäviä vaikutuksia kyberturvallisuuteen.

Sovellusten elinkaari ja kyberturvallisuus

Koen kuitenkin tärkeäksi avata sovellusten elinkaaren hallintaa erityisesti kyberturvallisuuden näkökulmasta. Sovellus itsessään voi olla esimerkiksi käyttöjärjestelmä tai vaikkapa niin sanottu kolmannen osapuolen sovellus (Adobe Reader, Google Chrome, jne). Sovelluksen julkaisusta sen elinkaaren päättämiseen siihen julkaistaan X määrä päivityksiä. Päivityksiä taas voi olla montaa eri sorttia riippuen tilanteesta:

  • tietoturvapäivitys
  • bugikorjaus
  • ominaisuuspäivitys
  • ominaisuuden parannus.

Yleensä kyberturvallisuuden parantamisen kannalta halutaan priorisoida tietoturvapäivitykset, joiden tarkoituksena on paikata sovelluksesta löydetty haavoittuvuus, tai muuten vaan tehdä ennakoivia parannuksia tietoturvaan. Asiaa ei voi kuitenkaan ajatella aivan näin mustavalkoisesti. Blogissa en voi selittää kyberturvallisuuden kaikkia eri viitekehyksiä, mutta yksi käytetyimmistä tietoturvan perusperiaatteista on niin sanottu CIA-triad, joka on selitetty esimerkiksi F5-tietoturvatoimijan artikkelissa.

Tässä tietoturvan perusmallissa kaikkien kolmen eli luottamuksellisuuden, eheyden ja saatavuuden tulee toteutua, jotta homma toimii.

Hieman oiottuna ja yksinkertaistettuna: myös saatavuuden pitää toteutua sovellusten osalta. Tämä tarkoittaa sitä, että tarvittavien sovelluksien tulee olla käytettävissä ja saatavilla kun käyttäjä niitä tarvitsee. Tästä on hyvä johtaa seikkoja, jotka tähän voisivat mahdollisesti vaikuttaa:

  • bugit
  • sovelluksen muuttuminen (käyttäjien tottumukset)
  • yhteensopivuusongelmat
  • laaja versiokirjo
  • päätelaitteen uudelleenkäynnistys.

Näin ollen onkin jo helppoa ymmärtää, että haavoittuvuus ei ole ainut asia joka sovelluksen tietoturvaa voi alentaa. Kun asiaa tarkastellaan näin laajana kokonaisuutena, sovellusten päivittäminen ei ole ainut vaikuttava tekijä. Sovellusversion pitäminen ajan tasalla pienentää bugien ja haavoittuvuuksien tuomaa haittaa. Toisaalta laajaan versiokirjoon ja yhteensopivuusongelmiin tuovat ratkaisuja ympäristön vakiointi tai lukitseminen ja perusteellinen sovellusversioiden testaus.

Näitä asioita taas edesauttavat hallitut päivittämisprosessit sovelluksiin. (Tästäkin asiasta Kettunen kirjoitti blogissaan.) Hyvällä prosessilla pyritään päivittämään sovellukset hallitusti ja tarvittaessa portaittain niin, että saadaan haluttu varmuus uuden version toimimisesta. Tällöin tulee huomioida muun muassa se, että sovelluksen automaattinen päivittäminen ei ole päällä.

Sovellusten päivittämisen prosessit

Haavoittuvuuksien ja tietoturvapäivitysten hoitamiseen on rakennettu paljon erilaisia suosituksia, prosesseja ja malleja – olet varmasti kuullut päivitysten hallinnasta tai haavoittuvuuksien hallinnasta (engl. patch management, vulnerability management, change management jne). Yksi tällainen malli on Microsoftin ja monen muun tahon suosima kuuden kohdan prosessi:

  1. Hankitaan tieto sovelluksen haavoittuvuudesta ja sen korjaavasta päivityksestä.
  2. Arvioidaan haavoittuvuuden aiheuttama riski ja suunnitellaan päivittäminen.
  3. Haetaan päivitys.
  4. Kokeillaan päivitys ja sen toimivuus.
  5. Asennetaan päivitys.
  6. Varmennetaan asennusten onnistuminen.

Tämä esimerkkiprosessi saattaa vaikuttaa melko vaivalloiselta, varsinkin kun organisaatiossa on lukuisia sovelluksia ja mahdollisesti eri käyttöjärjestelmiä. jotka päivittyvät hurjaa vauhtia. Tilastojemme mukaan esimerkiksi Adobe Reader, Adobe Flash, Google Chrome ja Mozilla Firefox päivittyivät yhteensä 79 kertaa vuoden 2019 aikana. Nuo ovat paljon käytössä olevia sovelluksia, joten on täysin aiheellista olettaa useita päivityksiä per kuukausi aivan tavanomaisessa organisaatiossa. Luonnollisesti esimerkin 79 päivitystä ei tarkoita, että jokainen niistä sisältäisi korjauksen haavoittuvuuteen.

Edellä mainittujen seikkojen perusteella on kohtuullista todeta jokaisen organisaation tarvitsevan juuri itselleen sopivan prosessin sovellusten elinkaaren ja päivitysten hallintaan.

Prosessit organisaatioissa

Sopivan prosessin luominen ja ylläpitäminen voi olla toisaalta todella haasteellista, kun pitää yrittää tasapainotella tietoturvan ja käytettävyyden kanssa. Tämän lisäksi prosessin kanssa toimiminen voi olla erittäin raskasta ja työlästä. Omien kokemusteni perusteella useiden tuhansien päätelaitteiden ympäristöissäkään ei välttämättä ole täysimittaista prosessia käytössä, tai useassa asiassa oikaistaan. Pienemmissä organisaatioissa tämä on yleensä vielä heikommin toteutettu.

Muun muassa tästä syystä markkinoilla on paljon ratkaisuja, jotka automatisoivat parhaimmillaan kaikki tavanomaisen haavoittuvuuksien hallinnan osa-alueet. Yleensä ratkaisut onnistuvat aika hyvin nimenomaan haavoittuvuuksien hallinnan osalta, mutta kuten aiemmin totesimme, sovellusten elinkaaren hallinta on paljon muutakin.

Jokaisen organisaation kannattaa kuitenkin asettaa itselleen prosessi ja sopivat tavoitteet toimia. Prosessin mukaan voidaan tehdä asiat käsin manuaalisesti, automatisoida tietyt osa-alueet tai pyrkiä automatisoimaan kaikki. Tietoturvan kannalta kaikki sovelluksien haavoittuvuudet tulisi paikata mahdollisimman nopeasti kuitenkin siten, että sovellusten tai laitteiden käyttö ei esty.

Kuva 1 osoittaa kuinka haavoittuvuuden elinkaaren eri vaiheissa sen hyödyntämisen riskit kasvavat. Hyödyntämisen nouseva käyrä saadaan pidettyä aisoissa päivittämällä sovellukset nopeasti.

Kuva 1 – Haavoittuvuuden elinkaari

Eli selvästi vaikuttavia tekijöitä päivitysprosessissa ovat aika, jonka puitteissa taistellaan haavoittuvuuden hyväksikäyttämisen todennäköisyyttä vastaan ja toisaalta korjaavan päivityksen testaus. Nopealla päivittämisellä pienennetään aikaikkunaa, jona haavoittuvuus on tehokas. Testaamisella taas parannetaan taas sovelluksien ja päätelaitteen saatavuutta.

Mutta mikä on nopeaa päivittämistä? Ponemonin tekemän tutkimuksen mukaan kriittiseksi tai korkeaksi luokitellun haavoittuvuuden hyväksikäyttö huomataan keskiarvollisesti 43 päivän kuluttua korjaavan päivityksen julkaisusta. Saman tutkimuksen mukaan organisaatiot päivittävät kriittisesti haavoittuvan ohjelman keskimäärin 16 päivässä. Näistä arvoista on mahdollista vetää jotain johtopäätöksiä, kun suunnitellaan oman organisaation päivitystenhallinnan prosessia ja sen aikataulutusta.

Mikä on siis sopiva aika jossa organisaatiosi voi todeta, että uusi versio ei aiheuta mitään negatiivista omassa ympäristössä ja jossa haavoittuvuus tulisi paikata? Tämä voi olla melko abstrakti ja vaikea asia ratkaista, mutta avataan hieman mitkä tekijät vaikuttavat tähän.

  • Kuinka kauan tarvitset aikaa siihen, että uusi päivitetty versio asennetaan tai jaellaan päätelaiteympäristöösi? Heitetään tähän vaikka arvo 5d, jonka kuluessa suurin osa päätelaitteista on ehtinyt varmasti asentaa uuden sovellusversion.
  • Kuinka laajan testaamisen uusi sovellusversio ympäristössäsi vaatii? Erittäin intensiivinenkin testaaminen per ryhmä vaatii varmasti kaksi työpäivää (2d per testiporras) kun mukaan lasketaan sovelluksen toimittaminen päätelaitteelle ja testaajan aktivoituminen.
  • Kuinka paljon tarvitaan aikaa kun uusi sovellusversio on haettu ja sitä aletaan toimittamaan päätelaiteympäristön ensimmäisille ryhmille? Pitääkö asennuspakettia muokata? Tämä kohta vie arviolta käsin tehtynä 1d verran.
  • Kuinka nopeasti saat tiedon uudesta versiosta tai sovelluksen haavoittuvuudesta? Seuraatko näitä tietoja säännöllisesti vai tekeekö jokin järjestelmä sen puolestasi? Nopeahko reagointi on mielestäni pari työpäivää (2d), ei viikkoja.

Nämä prosessin osat vievät aikaa haavoittuvuuden julkistuksesta uuden version asennuksiin arviolta 10–16 työpäivää, riippuen kuinka nopeasti haavoittuvuus on havaittu ja kuinka monessa eri tasossa testataan. Uskallan sanoa, että näin ripeästi toimiminen on varmasti riittävä tahti, jotta haavoittuvuuden hyödyntämisen mahdollisuus pysyy pienenä.

Tähän aikajanaan riittää oletuksena myös riittävästi testaamista. Pystyykö organisaatiosi siihen? Ainakin tekemistä riittää, mikäli mitään näitä prosessin osia ei ole automatisoitu. Päivityksenhallinnan prosessi kuulostaa raskaalta kokonaisuudelta. Haluan kuitenkin painottaa, että organisaatiot ovat erilaisia.

Hyvänä esimerkkinä paljon ketterämmästä lähestymisestä on viime aikoina tuonut Windows Update for Business. Siinä on mahdollista lyödä päivittämisen ruutiini tauolle tai palauttaa laitteet edelliseen päivitysversioon, jos jotain kauheaa tapahtuu. Pienemmät organisaatiot toimivat hyvin usein nykyään juuri tällä tavoin.

Kolmannen osapuolen päivitykset ovat valitettavasti kuitenkin pakollinen paha, jotka ovat aivan yhtä tärkeitä kuin käyttöjärjestelmän päivitykset. Mikäli haluat kaikki edellä mainitun päivittämisen prosessin osat automatisoitua omilla ehdoillasi, suosittelen käyttämään Centero Software Manageria.


Tuukka Tiainen
IT-asiantuntija

Päätelaitteiden tietoturva-asiantuntijan tehtäväkenttää hoitavan Tuukan roolina on toimia eräänlaisena välimiehenä asiakkaan, myynnin ja kehityksen välissä. Työ sisältää muun muassa käyttöönottoja ja muuta asiakaspalvelua. Hän toimii välillä myynnin apuna teknisenä tukena asiakastapaamisissa ja osallistuu myös tuote- ja palvelukehityksen prosesseihin. Tuukan vahvuus on päätelaitehallinnan kehittäminen nimenomaan kyberturvallisuusnäkökohdista käsin.

Tutustu Centero Software Manageriin »

Lisää luettavaa aiheesta:

Patch Management -ratkaisut vertailussa – Osa 1/12 – Vertailun taustat

Aloitamme blogisarjan, joka pohjautuu Centeron vuonna 2019 tekemään patch management -työkalujen vertailuun. Blogisarjan ensimmäisessä osassa käymme läpi työkaluvertailun taustaa. Tule mukaan ja tutustu patch managementin maailmaan!

Patch Management -ratkaisut vertailussa – GFI LanGuard – Osa 8/14

GFI LanGuard on jo olemassa olevaan organisaation infrastruktuuriin implementoitava päätelaitteiden turvallisuutta skannaava ratkaisu. Tämän yksi luonnollinen osa-alue on haavoittuvuuksien havaitseminen ja paikkaaminen sekä Microsoftin, että kolmansien osapuolten sovellusten kohdalla.