Lyhyesti: Haavoittuvuuksien hallinta keskisuuressa yrityksessä ja pk-yrityksessä on kevyt, toistuva kierto: tunnetaan omat järjestelmät, seurataan tiedotteita kohdennetusti, arvioidaan riski, päätetään, toteutetaan ja todennetaan. Ratkaisevia eivät ole kalliit työkalut vaan selkeät vastuut ja tärkeysjärjestys, jossa otetaan huomioon tavoitettavuus, tiedot ja hyökkäystilanne. PHP2Shell on hyvä harjoitusesimerkki, koska siinä toteutuvat kaikki vaiheet.
Satoja tiedotteita, vähän henkilöstöä
Joka viikko julkaistaan uusia tietoturva-aukkoja käyttöjärjestelmissä, ohjelmointikielissä, sovelluksissa ja lisäosissa. Konsernilla on siihen tiimi. Keskisuurella yrityksellä on usein IT-päällikkö, yksi tai kaksi ylläpitäjää ja useita ulkopuolisia palveluntarjoajia. Kukaan ei voi lukea jokaista tiedotetta, eikä tarvitsekaan.
Tarvitaan suodatin: mitkä tiedotteet koskevat meidän järjestelmiämme, mitkä niistä ovat kiireellisiä ja kuka hoitaa asian? Ilman suodatinta käy toisin kuin pitäisi. Joko kaikki sivuutetaan, kunnes jotain sattuu, tai jokainen tiedote aiheuttaa hälytystilan, ja todella kriittinen hukkuu kohinaan.
Haavoittuvuuksien hallinnan kierto
Pk-yrityksen kantava toimintatapa voidaan kuvata kuudella vaiheella:
- Kirjaa, mitä käytössä on. Ilman luetteloa ei voi vertailla. Mitä verkkosivustoja, palvelimia, PHP-versioita ja sovelluksia ylläpidätte ja missä? Miten se onnistuu, näette artikkelista Tietäkää, mitä käytössä on: kaikkien verkkosivustojen ja palvelinten luettelo.
- Seuraa tiedotteita. Tilatkaa muutama luotettava lähde: BSI:n varoitukset, käyttämienne ohjelmistojen valmistajien tiedotteet, Linux-jakelunne tietoturvasivut ja PHP:n osalta php.netin etusivu.
- Arvioi. Koskeeko tiedote meitä? Jos koskee, kuinka kiireellisesti? Lisää alempana.
- Päätä. Korjaa, suojaa väliaikaisesti, eristä järjestelmä tai kanna riski tietoisesti. Kuka saa päättää mistäkin?
- Toteuta. Asenna päivitys, ota käyttöön väliaikainen toimenpide, tilaa palveluntarjoaja.
- Todenna ja seuraa. Onko aukko todella suljettu? Milloin väliaikainen ratkaisu korvataan?
Kierto alkaa sen jälkeen alusta. Uusia järjestelmiä tulee, vanhoja poistuu ja uusia tiedotteita ilmestyy.
Vaiheessa 2 auttaa yksinkertainen sääntö: lue mieluummin muutamaa lähdettä säännöllisesti kuin monta satunnaisesti. Tyypilliseen keskisuuren yrityksen verkkoympäristöön riittävät yleensä BSI:n yhteydessä toimivan CERT-Bundin (Saksan valtion CERT) varoitukset, käytössä olevan Linux-jakelun tietoturvatiedotteet, CMS- ja verkkokauppavalmistajien sivut sekä php.netin etusivu. Sopikaa, kuka näitä lähteitä lukee, ja perustakaa niille yhteinen postilaatikko tai kanava, joka ei ole sidottu yhteen henkilöön.
Lisäksi kannattaa katsoa ulkopuolelta. Julkisesti tavoitettavien järjestelmien säännöllinen haavoittuvuusskannaus näyttää, näkyykö vanhentunutta ohjelmistoa tai turhaan avoimia palveluja. Se ei korvaa luetteloa eikä päivityksiä, mutta paljastaa järjestelmät, jotka eivät ole missään luettelossa.
Arviointi: mikä tulee ensin
CVSS-arvo, haavoittuvuuden vakavuuden standardoitu luokitus, on hyvä lähtökohta. Oman talon järjestykseen se ei kuitenkaan yksin riitä. Ratkaisevia ovat kolme muuta kysymystä:
| Kysymys | Nostaa kiireellisyyttä | Laskee kiireellisyyttä |
|---|---|---|
| Onko järjestelmä tavoitettavissa internetistä? | julkinen verkkosivusto, verkkokauppa, portaali | vain sisäinen, VPN:n takana |
| Tarvitaanko aukon hyödyntämiseen kirjautuminen? | ei, todentamaton | kyllä, vain ylläpitäjille |
| Mitä tietoja järjestelmä käsittelee? | asiakastiedot, maksut, tunnukset | julkinen sisältö ilman käyttäjätilejä |
| Onko hyökkäyksistä raportteja? | hyökkäysyrityksiä ilmoitettu | ei tiedossa olevia yrityksiä |
| Onko väliaikaista toimenpidettä? | ei | kyllä, todennetusti tehokas |
PHP2Shell näyttää, miten nämä vaikuttavat yhdessä. Molempien aukkojen CVSS v4.0 -arvo on 9,2, ne sallivat koodin suorittamisen ilman kirjautumista ja koskevat julkisesti tavoitettavia verkkopalvelimia. Median mukaan Cloudflare ja Patchstack raportoivat hyökkäysyrityksistä, ja BSI luokitteli tilanteen varoitustasolle 3. php.netin väliaikaiset toimenpiteet eivät nimenomaisesti tarjoa täydellistä suojaa. Kaikki kysymykset osoittavat samaan suuntaan: toimikaa heti. Mitä BSI tarkalleen suositteli, selviää sivulta Mitä BSI suosittelee PHP2Shellistä.
Päätä ja dokumentoi
Kaikkia aukkoja ei voi sulkea heti. Vanha järjestelmä toimii PHP 8.1:llä, johon ei enää ole virallisia päivityksiä (katso PHP 8.1 ja vanhemmat: mikä nyt pätee), ja erikoissovellus ei vielä kestä päivitystä. Silloin tarvitaan päätös, eikä se kuulu pelkästään tekniikalle.
Hyvä päätösmuistio sisältää kohdejärjestelmän, aukon, arvioinnin, valitun vaihtoehdon, väliaikaiset toimenpiteet, vastuuhenkilön ja määräpäivän uutta tarkastusta varten. Jos riski kannetaan tietoisesti, päättää johto eikä ylläpitäjä yksin. Myös OWASPin Cheat Sheet haavoittuvien riippuvuuksien käsittelystä suosittelee kirjaamaan riskin hyväksymisen nimenomaisesti johtotasolle.
Pitäkää yhtä luetteloa avoimista haavoittuvuuksista, jossa on tila, vastuuhenkilö ja määräpäivä. Taulukko riittää. Tärkeää on, että se käydään läpi säännöllisesti, esimerkiksi kuukausittaisessa kokouksessa johdon kanssa.
Mitä NIS2:lla ja palveluntarjoajilla on tekemistä asian kanssa
NIS2:n piiriin kuuluvilla yrityksillä haavoittuvuuksien käsittely kuuluu riskienhallinnan velvoitteisiin. Yksityiskohdat kuvaa sivu NIS2 ja verkkopalvelimen tietoturva. Myös ilman lakisääteistä velvoitetta dokumentoitu toimintatapa on etu, esimerkiksi asiakkaiden, vakuutusyhtiöiden ja oman johdon silmissä.
Monet vaiheet voi ulkoistaa, esimerkiksi tiedotteiden seurannan tai päivitysten asentamisen. Riskipäätökset ja kokonaiskuva kannattaa kuitenkin pitää talon sisällä. Joka antaa koko kierron kokonaan palveluntarjoajalle, ei hätätilanteessa enää edes tiedä, mitä järjestelmiä sillä on. Miten toteutus järjestetään rutiiniksi, kuvaa artikkeli Päivitysten hallinta prosessina palokunta-toiminnan sijaan.
Miten PHP SOS auttaa konkreettisesti?
- Laadimme kanssanne verkkosivustojenne ja palvelintenne luettelon, joka on perusta jokaiselle vertailulle.
- Seuraamme järjestelmiinne liittyviä tiedotteita ja toimitamme arvion selkeällä kielellä suosituksineen.
- Valmistelemme päätösmuistiot tapauksiin, joissa päivitystä ei voi tehdä heti.
- Tietoturvaseurannan avulla tarkistamme jatkuvasti, muuttuvatko järjestelmät epäilyttäviksi aukon ollessa vielä avoinna.
Yhteenveto: Haavoittuvuuksien hallinnan ei tarvitse olla suurta, mutta sen on oltava sitovaa. Joka tuntee järjestelmänsä, lukee muutamaa hyvää lähdettä ja kirjaa päätökset, reagoi seuraavaan kriittiseen tiedotteeseen nopeasti ja oikein.
Usein kysytyt kysymykset
Mitä haavoittuvuuksien hallinta on?
Toistuva toimintatapa, jonka avulla yritys saa tietää järjestelmiensä tietoturva-aukoista, arvioi ne, korjaa ne tai hyväksyy ne tietoisesti ja kirjaa tuloksen. Kyse ei ole työkalusta vaan vastuista ja päätöksistä.
Riittääkö CVSS-arvo tärkeysjärjestyksen määrittämiseen?
Se on hyvä lähtökohta, mutta ei riitä. Lisäksi ratkaisevaa on, onko kohdejärjestelmä tavoitettavissa internetistä, mitä tietoja se käsittelee ja onko hyökkäyksiä jo havaittu. Korkean arvon haavoittuvuus sisäisessä testijärjestelmässä voi odottaa, verkkokaupassa ei.
Tarvitseeko pieni yritys siihen oman työkalun?
Alussa ei. Ajan tasalla pidetty järjestelmäluettelo, tilatut tietoturvatiedotteet ja taulukko avoimista kohdista riittävät. Haavoittuvuusskannerit kannattavat, kun järjestelmien määrä kasvaa tai tarkastukset on todistettava säännöllisesti.
Saako haavoittuvuuden jättää tarkoituksella korjaamatta?
Kyllä, jos riski on arvioitu, päätöksen on tehnyt vastuullinen johto ja se on kirjattu kirjallisesti, mieluiten väliaikaisine toimenpiteineen ja määräpäivineen uutta tarkastusta varten.