Tunkeutumistestauksella tulisi olla selkeästi määritellyt tavoitteet ja laajuus. Tavoitteisiin voi kuulua esimerkiksi jatkuvuussuunnitelmien ja -valmiuksien testaaminen, tietoturvakontrollien arviointi tai tietoturvaheikkouksien tunnistaminen. Laajuus voidaan määritellä seuraavasti:
Elintärkeitä järjestelmiä tai komponentteja, jotka voidaan jättää testauksen ulkopuolelle, ovat esimerkiksi ne, jotka ovat välttämättömiä organisaation kriittisten palvelujen ylläpitämiseksi tai jotka eivät kestä tunkeutumistestin aiheuttamaa rasitusta.
Suunnitteluvaiheessa on tärkeää ottaa asianomaiset sidosryhmät mukaan etukäteen. Tämä tarkoittaa usein sitä, että ulkopuolisille järjestelmänvalvontatoimittajille on ilmoitettava asiasta ennen testausta, vaikka käyttäjille tai järjestelmänhallintahenkilöstölle ei välttämättä ole tarpeen ilmoittaa asiasta.
Tunkeutumistestaus olisi suoritettava säännöllisesti, vähintään vuosittain. Se olisi suoritettava sekä organisaation verkkoalueen ulkopuolelta että sen sisältä. Ulkopuolelta tapahtuva testaus simuloi ulkoista hyökkäystä (black box ja white box), kun taas sisäpuolelta tapahtuva testaus simuloi mahdollisia uhkia, jotka tulevat vaarantuneilta asiakkailta/palvelimilta tai haitallisilta sisäpiiriläisiltä (grey box).
Tunkeutumistestien tulokset on aina dokumentoitava.
Organisaatiolla on prosessi uhkaperusteisen tunkeutumistestauksen (TLPT) säännöllistä suorittamista varten.
TLPT-prosessi täyttää seuraavat vaatimukset:
Organisaatio toteuttaa uhkatiedustelua keräämällä tietoa toimintaansa liittyvistä tietoturvauhkista ja niiltä suojautumisesta. Tavoitteena on kasvattaa tietoisuutta uhkaympäristöstä, jotta omaa suojaustasoa voidaan paremmin arvioida ja riittävät hallintakeinot toteuttaa.
Uhkatiedustelutiedon keräämisessä on huomioitava kaikki kolme tasoa:
Uhkatiedusteluun liittyvien periaatteiden tulisi sisältää:
Organisaatio on määritelly prosessin, jonka perusteella tunnistetut tekniset haavoittuvuudet käsitellään.
Osa haavoittuvuuksista voidaan korjata suoraan, mutta merkittäviä vaikutuksia omaavat haavoittuvuudet tulisi dokumentoida myös tietoturvahäiriöinä. Merkittäviä vaikutuksia omaavan haavoituvuuden tunnistamisen jälkeen:
Organisaatiolla on prosessi, jolla käsitellään muiden osapuolten, kuten tavallisten käyttäjien tai "white-hat"-hakkerien, paljastamia haavoittuvuuksia.
Tyypillisesti tämä hoidetaan haavoittuvuuksien paljastamisohjelmien (Vulnerability Disclosure Programs, VDP) tai virallisten bugipalkkio-ohjelmien avulla. Näiden ohjelmien avulla käyttäjät voivat ilmoittaa haavoittuvuuksista organisaatiolle.
Organisaatio kehittää haavoittuvuuksia varten yksityiskohtaisen vakavuusluokitusjärjestelmän, määrittelee vakavuustasojen kriteerit, sisällyttää nämä luokitukset kehitystyönkulkuihin, asettaa turvallisuusstandardit, käyttää automaattisia arviointityökaluja, ottaa käyttöön priorisointiprosessin ja tarkastelee järjestelmää vuosittain haavoittuvuuksien tehokkaan hallinnan varmistamiseksi.
Organisaatio perustaa erityisen tiimin ja standardoidun prosessin tietoturva-aukkojen perimmäisten syiden analysointia varten, jolla varmistetaan perusteellinen tiedonkeruu, syiden tunnistaminen, yhteistyö kehitystiimien kanssa ratkaisujen löytämiseksi, koulutus toistumisen estämiseksi ja tietoturvakäytäntöjen jatkuva parantaminen.
Organisaatio tekee kuukausittain automaattisia haavoittuvuusskannauksia kaikille ulkoisesti altistuville tieto-omaisuuksille käyttäen kehittyneitä työkaluja perusteelliseen analyysiin ja nopeaan reagointiin löydösten perusteella, ja samalla se päivittää säännöllisesti skannausprotokollia, jotta voidaan vastata uusiin uhkiin ja ylläpitää tietoturvallista valppautta.
Organisaatio on ottanut käyttöön kattavan strategian sisäisten resurssien automatisoituja haavoittuvuusskannauksia varten, sekä suorittanut todennettuja sekä ei-todennettuja skannauksia. Skannaukset ovat kattavia, ja tuloksia analysoidaan säännöllisesti. Työkaluja ja tekniikoita parannetaan jatkuvasti havaintojen perusteella tietoturvariskien käsittelemiseksi.
Tunkeutumistestauksen jälkeen, organisaation tulee:
Organisaatiolla tulisi olla dokumentoidut prosessit ja mallit havaittujen haavoittuvuuksien raportointia varten.
Haavoittuvuuksien havaitsemisraportit olisi toimitettava välittömästi toimivaltaiselle tietoverkkotapahtumia ehkäisevälle laitokselle ja viimeistään viiden päivän kuluessa haavoittuvuuden havaitsemisesta.
Havaintoraportin olisi sisällettävä seuraavat tiedot:
Organisaatio on määritellyt prosessit havaittujen haavoittuvuuksien korjaamiseksi.
Näihin prosesseihin olisi sisällyttävä ainakin seuraavat:
Organisaatio toteuttaa tarvittavat toimet haavoittuvuuden torjumiseksi toimivaltaisen tietoverkkotapahtumia ehkäisevän laitoksen asettamassa määräajassa, kuitenkin viimeistään 90 päivän kuluessa tiedon saamisesta, ja ilmoittaa toimivaltaiselle tietoverkkotapahtumia ehkäisevälle laitokselle haavoittuvuuden torjunnan edistymisestä.
Jos haavoittuvuutta ei objektiivisista syistä ole mahdollista poistaa asetetussa määräajassa, tietoverkkohäiriöiden torjuntalaitos voi organisaation pyynnöstä pidentää haavoittuvuuden poistamiselle asetettua määräaikaa, kuitenkin enintään 180 päivää haavoittuvuuden havaitsemisraportin toimittamisesta, ilmoittamalla siitä haavoittuvuuden havaitsemisraportissa sen toimittajalle.
Organisaation on käytettävä haavoittuvuuksien skannaustyökaluja pääasiallisena työkaluna säännöllisessä haavoittuvuuksien skannausprosessissa.
Lisäksi organisaation olisi käytettävä hyökkäystyökaluja skannausvälineellä löydettyjen haavoittuvuuksien testaamiseen.
Tunkeutumistestien tulokset ja raportit on toimitettava relevanteille sidosryhmille. Näistä testeistä on laadittava dokumentti, jossa on vähintään yhteenveto, luettelo havainnoista ja parannusehdotukset.
Tunkeutumistestauksella tulisi olla selkeästi määritellyt tavoitteet ja laajuus. Tavoitteisiin voi kuulua esimerkiksi jatkuvuussuunnitelmien ja -valmiuksien testaaminen, tietoturvakontrollien arviointi tai tietoturvaheikkouksien tunnistaminen. Laajuus voidaan määritellä seuraavasti:
Elintärkeitä järjestelmiä tai komponentteja, jotka voidaan jättää testauksen ulkopuolelle, ovat esimerkiksi ne, jotka ovat välttämättömiä organisaation kriittisten palvelujen ylläpitämiseksi tai jotka eivät kestä tunkeutumistestin aiheuttamaa rasitusta.
Suunnitteluvaiheessa on tärkeää ottaa asianomaiset sidosryhmät mukaan etukäteen. Tämä tarkoittaa usein sitä, että ulkopuolisille järjestelmänvalvontatoimittajille on ilmoitettava asiasta ennen testausta, vaikka käyttäjille tai järjestelmänhallintahenkilöstölle ei välttämättä ole tarpeen ilmoittaa asiasta.
Tunkeutumistestaus olisi suoritettava säännöllisesti, vähintään vuosittain. Se olisi suoritettava sekä organisaation verkkoalueen ulkopuolelta että sen sisältä. Ulkopuolelta tapahtuva testaus simuloi ulkoista hyökkäystä (black box ja white box), kun taas sisäpuolelta tapahtuva testaus simuloi mahdollisia uhkia, jotka tulevat vaarantuneilta asiakkailta/palvelimilta tai haitallisilta sisäpiiriläisiltä (grey box).
Tunkeutumistestien tulokset on aina dokumentoitava.
Tunkeutumistestauksella tulisi olla selkeästi määritellyt tavoitteet ja laajuus. Tavoitteisiin voi kuulua esimerkiksi jatkuvuussuunnitelmien ja -valmiuksien testaaminen, tietoturvakontrollien arviointi tai tietoturvaheikkouksien tunnistaminen. Laajuus voidaan määritellä seuraavasti:
Elintärkeitä järjestelmiä tai komponentteja, jotka voidaan jättää testauksen ulkopuolelle, ovat esimerkiksi ne, jotka ovat välttämättömiä organisaation kriittisten palvelujen ylläpitämiseksi tai jotka eivät kestä tunkeutumistestin aiheuttamaa rasitusta.
Suunnitteluvaiheessa on tärkeää ottaa asianomaiset sidosryhmät mukaan etukäteen. Tämä tarkoittaa usein sitä, että ulkopuolisille järjestelmänvalvontatoimittajille on ilmoitettava asiasta ennen testausta, vaikka käyttäjille tai järjestelmänhallintahenkilöstölle ei välttämättä ole tarpeen ilmoittaa asiasta.
Tunkeutumistestaus olisi suoritettava säännöllisesti, vähintään vuosittain. Se olisi suoritettava sekä organisaation verkkoalueen ulkopuolelta että sen sisältä. Ulkopuolelta tapahtuva testaus simuloi ulkoista hyökkäystä (black box ja white box), kun taas sisäpuolelta tapahtuva testaus simuloi mahdollisia uhkia, jotka tulevat vaarantuneilta asiakkailta/palvelimilta tai haitallisilta sisäpiiriläisiltä (grey box).
Tunkeutumistestien tulokset on aina dokumentoitava.
Organisaatiolla olisi oltava määriteltynä ja toteutettuna asianmukainen korjaustenhallintamenettely. Tähän olisi sisällyttävä korjausten testaus ja asennus.
Olisi toteutettava toimenpiteitä korjausten hallintaan liittyvien riskien minimoimiseksi ja korjausten onnistuneen asennuksen todentamiseksi.
Korjausten hallinnan olisi mahdollisuuksien mukaan oltava automatisoitua (esimerkiksi käyttöjärjestelmän päivitykset).
Korjaustenhallintaprosessissa olisi otettava huomioon kehysten asettamat vaatimukset tai muut vaatimukset, joita niiden on noudatettava.
Organisaatio suorittaa uhkavetoisen penetraatiotestauksen. Jokaisen testin on katettava useita asiaankuuluvan talousyksikön kriittisiä tai tärkeitä toimintoja.
Määritä TLPT:n suhteellinen soveltamisala oikein seuraavasti:
Tämän arvioinnin tulos määrittää TLPT:n tarkan soveltamisalan, ja toimivaltaisten viranomaisten on validoitava se.
Uhkavetoisessa penetraatiotestauksessa käytettävän testausorganisaation tulee täyttää vähintään seuraavat vaatimukset:
Jos käytät sisäisiä testaajia yllä olevan luettelon kanssa, niiden tulee olla:
Testaajan kanssa tehdyissä sopimuksissa tulosten hallinta ja mahdollinen tietojenkäsittely eivät aiheuta riskejä organisaatiolle.
Organisaation häiriönsietokykyvyn testausohjelmassa on varauduttu tarjoamaan kaikki tarvittava tukeva asiantuntijatyö valituille häiriönsietokykytestaustoimille. Tähän voi sisältyä esimerkiksi suorituskykytestausta, päästä päähän -testausta, tunkeutumistestausta tai lähdekoodin tarkistuksia.
Tähän liittyviin häiriönsietokyvyn testaustoimiin voi kuulua esimerkiksi haavoittuvuusskannauksia, muiden skannausohjelmistojen käyttöä, verkkoturvallisuuden arviointeja, fyysisen turvallisuuden tarkastuksia tai muunlaisia puuteanalyysejä.
Kovettaminen on käytäntö, jolla vähennetään järjestelmän haavoittuvuutta vähentämällä sen hyökkäyspintaa.
Virtuaalikoneita määritettäessä organisaation on varmistettava, että koneet on kovennettu esimerkiksi käyttämällä / sallimalla vain tarvittavia portteja, protokollia ja palveluita. Kaikissa virtuaalikoneissa on oltava myös tekniset suojatoimenpiteet, kuten haittaohjelmien torjunta ja lokikirjaus.
Haavoittuvuuksien hallinnan prosessi testataan säännöllisesti organisaation määrittelemän aikavälin mukaan, jotta varmistetaan sen ajantasaisuus, toimivuus ja tehokkuus.
Organisaatio seuraa tiedotteita käytössä olevien tietojärjestelmien teknisistä haavoittuvuuksista. Kun relevantteja teknisiä haavoittuvuuksia havaitaan, organisaatio ryhtyy toimiin suunnitellun toimintamallin mukaisesti.
Organisaatio toteuttaa uhkatiedustelua analysoimalla ja hyödyntämällä kerättyä tietoa toimintaansa liittyvistä tietoturvauhkista ja niiltä suojautumisesta.
Kerätyn uhkatiedustelutiedon analysoinnissa ja hyödyntämisessä on huomioitava seuraavat asiat:
Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään vuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:
"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään puolivuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:
"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Kovennusten voimassaolosta ja vaikuttavuudesta huolehditaan koko tietojärjestelmän elinkaaren ajan.
Organisaatiolla on oltava selkeä toimintamalli havaittujen teknisten haavoittuvuuksien priorisointiin. Toimintamallin ei pitäisi olla täysin omaa keksintöä, vaan tukeutua yleisesti hyväksyttyihin käytäntöihin.
Haavoittuvuudet tulisi priorisoida niiden aiheuttamien riskin, liittyvän omaisuuden tärkeyden, mahdollisen organisationaalisen vaikutuksen sekä kiireellisyyden (huomioiden CVSS-arvo) perusteella.
Organisaation on määriteltävä seuratut mittarit haavoittuvuuksien tunnistamiseen sekä korjaamiseen liittyen. Mittareita on seurattava määritetyin aikavälein.
Organisaation on kehitettävä prosessi teknisten haavoittuvuuksien käsittelyn automatisoinnille.
Eristetään ympäristöt, joissa seuraukset voivat olla erittäin vahingollisia.
Ohjelmistojen hallinnoimattomat asennukset tietokoneille voivat johtaa haavoittuvuuksiin ja tietoturvahäiriöihin.
Organisaation olisi määriteltävä, minkä tyyppisiä ohjelmistoja tai päivityksiä kukin käyttäjä voi asentaa. Ohjeet voivat sisältää mm. seuraavia reunaviivoja:
Tietojärjestelmien toiminta voi olla riippuvaista tietyistä avainresursseista, kuten palvelinkapasiteetista, tallennustilasta, tietojenkäsittelykapasiteetista, valvontakapasiteetista tai tietyistä avainhenkilöistä.
Etenkin osalla näistä resursseista voi tietyissä tilanitessa olla pitkät toimitusajat tai korkeat kustannukset, jolloin tuleviin kapasiteettiongelmiin niiden kanssa on kiinnitettävä erityistä huomiota.
Tarkkailemme tärkeimpien järjestelmäresurssien käyttöä ja tunnistamme suuntaukset, turvallisuutta mahdollisesti uhkaavat pullonkaulat ja riippuvuudet tärkeistä henkilöistä.
Organisaatio tekee säännöllisesti haavoittuvuusskannausta, jossa etsitään tietokoneista, työasemista, mobiililaitteista, verkoista tai sovelluksista tunnettuja haavoittuvuuksia. Skannausta on tärkeää tehdä myös merkittävien muutosten jälkeen.
On huomioitava, että haavoittuvaa lähdekoodia voi löytyä niin käyttöjärjestelmäohjelmistoista, palvelinsovelluksista, loppukäyttäjäsovelluksista, kuin esimerkiksi laiteohjelmistotason (firmware) sovelluksista sekä ajureista, BIOS:ista ja erillisistä hallintaliittymistä (esim. iLo, iDrac). Ohjelmistovirheiden lisäksi haavoittuvuuksia aiheutuu konfiguraatiovirheistä ja vanhoista käytänteistä, esimerkiksi vanhentuneiden salausalgoritmien käytöstä.
Olemme määritelleet säännöt , joiden perusteella tunnistettuun haavoittuvuuteen reagoidaan. Säännöt voivat sisältää mm. seuraavat asiat:
Riskialttiisiin järjestelmiin liittyvät haavoittuvuudet saavat aina korkean vakavuuden ja ne käsitellään ensimmäisinä.
Ohjelmistoille ja muulle teknologialle on tietoisesti yksilöity tietolähteet, joita käyttämällä tunnistetaan meille relevantteja teknisiä haavoittuvuuksia ja ylläpidetään tietoa niistä (esim. viranomaiset tai laite- ja ohjelmistovalmistajat). Tietolähteitä arvioidaan ja päivitetään löydettäessä uusia hyödyllisiä lähteitä.
Haavoittuvuuksia voi löytyä suoraan hyödyntämistämme toimittajien järjestelmistä tai monien järjestelmiemme hyödyntämistä open source -komponenteista. On tärkeää seurata useita lähteitä, jotta oleellisista asioista ollaan kärryillä.
Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasolla IV toteutetaan seuraavat toimenpiteet:
Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasoilla III-II toteutetaan seuraavat toimenpiteet:
Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
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.
Tietojärjestelmien toiminta voi olla riippuvaista tietyistä avainresursseista, kuten palvelinkapasiteetista, tallennustilasta, tietojenkäsittelykapasiteetista, valvontakapasiteetistatai tietyistä avainhenkilöistä.
Organisaatio on määritellyt avainresurssit sekä tavat näiden avainresurssien käytön seurantaan. Resursseille määritetään lisäksi normaalitaso, jota hyödynnetään arvioidessa riskiä saatavuuden vaarantumisesta kapasitettiongelmien vuoksi.
Organisaation on huomioitava uhkatiedustelussa tehdyt löydökset tietoturvariskien hallintaprosessissa. Uhkatiedustelussa voidaan havaita esimerkiksi tietyntyyppisten hyökkäysten yleistymistä tai uusien teknologioiden kehittymistä, joiden perusteella tiettyjen tietoturvariskien arvioita on päivitettävä, joka voi johtaa tarpeeseen pienentää riskejä käsittelysuunnitelmien kautta.
Organisaation on jaettava uhkatiedustelutietoa muiden organisaatioiden kanssa molemminsuuntaisesti uhkatietoisuuden parantamiseksi.
Teknisten haavoittuvuuksien hallintaprosessia seurataan ja arvioidaan säännöllisesti, jotta voidaan varmistaa sen tehokkuus ja vaikuttavuus.
Digiturvamallissa kaikki vaatimuskehikkojen vaatimukset kohdistetaan universaaleihin tietoturvatehtäviin, jotta voitte muodostaa yksittäisen suunnitelman, joka täyttää ison kasan vaatimuksia.
.png)
Paranna osaamistasi viikoittaisten webinaarien, videokurssien, artikkeleiden ja blogien avulla.
