Useimmat organisaatiot kuulostavat edelleen varmoilta puhuessaan kyberturvallisuusvalmiudesta. Toimintaperiaatteet on hyväksytty, työkalut otettu käyttöön, ja vuosittaiset simulaatioharjoitukset antavat vaikutelman koordinoinnista. Kuitenkin kun samoja tiimejä testataan realistisissa harjoituksissa, päätöksenteon tarkkuus heikkenee jyrkästi ja tilanteen hallinta kestää usein päiviä, ei tunteja
IT-johtajille ja SOC-päälliköille juuri tämä kuilu luottamuksen ja todellisuuden välillä on todellinen riski. Ongelma on yksinkertainen: simulaatioharjoitukset (TTX) ja tekniset testit (TTP-toistot, purple teaming, red teaming) toteutetaan yleensä rinnakkain, eri vastuuhenkilöiden johdolla, eri tavoitteilla ja ilman yhteistä tietopohjaa. Tämän vuoksi kaikki joutuvat luottamaan oletuksiin, kun tapahtumia on käsiteltävä NIS2-direktiivin, GDPR-asetuksen, sopimusten ja asiakkaiden asettamien tiukkojen määräaikojen puitteissa.
Damovon hyökkäyssuuntautunut kyberturvallisuusneuvontatiimi (Lares) on kehittänyt kuusivaiheisen vastustajan integrointimenetelmän, jossa TTX-harjoitukset ja todellisten hyökkäysten TTP-toistot yhdistetään tarkoituksellisesti yhdeksi suljetuksi kierrokseksi. Tavoite on selkeä: korvata olettamus ”uskomme, että huomaamme sen” todisteilla, jotka osoittavat, miten organisaatiosi todellisuudessa havaitsee, eskaloida ja raportoi kriittiset hyökkäykset.
Valmistautumisvaje: kun oletukset kohtaavat todellisuuden
Teoriassa useimmat organisaatiot uskovat pystyvänsä havaitsemaan vakavat tietoturvaloukkaukset, rajoittamaan niiden vaikutukset ja palauttamaan järjestelmät ennalleen. Riippumattomissa vertailututkimuksissa päätöksenteon tarkkuus realistisissa harjoituksissa jää kuitenkin vain murto-osaan johtajien odotuksista, ja loukkausten hallintaan kuluva aika ylittää keskimäärin 24 tuntia. Tämä on vakava ongelma eurooppalaisessa toimintaympäristössä, jossa loukkausten raportointiaika alkaa nykyään tunteina, ei päivinä.
Perinteiset pöytäharjoitukset ovat osa ongelmaa. Ne paljastavat puutteita ihmisissä ja prosesseissa – sekavat eskalointireitit, epäselvä vastuu, puuttuvat valvontatoimenpiteet – mutta ne perustuvat teknisiin oletuksiin, joita ei ole koskaan todennettu. Osallistujat väittävät varmoin mielin, että ”palomuuri estää sen”, ”EDR antaa varmasti hälytyksen” tai ”SOC huomaisi tämän kymmenen minuutin kuluessa”, ja harjoitus etenee.
Toisaalta monet purple team haavoittuvuuksien tunnistamiseen keskittyvät ohjelmat keskittyvät edelleen pelkästään viitekehyksen kattavuuteen. Tiimit pelaavat ”MITRE ATT&CK -bingoa” ja käyvät läpi mahdollisimman monta tekniikkaa ilman, että ne liitetään tiettyihin liiketoimintariskeihin, päätöksentekotilanteisiin tai raportointivelvoitteisiin.
Tuloksena on näennäinen valmius, jossa kumpikaan ratkaisu ei vastaa IT- ja SOC-johtajille tärkeintä kysymystä: ”Pystymmekö havaitsemaan tämän hyökkäyksen tässä ympäristössä, reagoimaan siihen ja osoittamaan, että toimimme oikein ja ajoissa?”
Miksi TTX yksinään ei riitä IT- ja SOC-johtajille
Toiminnallisesta näkökulmasta perinteisissä pöytämallisissa ohjelmissa on kolme merkittävää puutetta.
- Ei telemetriaa: Tabletopit tuottavat muistiinpanoja ja toimia, eivät lokitiedostoja, hälytyksiä tai ajastustietoja, joita voidaan käyttää havaitsemistekniikassa.
- Tarkistamattomat oletukset: Insinöörit joutuvat arvaamaan, miten EDR-, SIEM-, identiteetti-, OT- ja pilvipalveluiden hallintatoiminnot toimisivat, koska kukaan ei todellisuudessa toteuta hyökkäystä.
- Ei yhteyttä työkalujen kehityssuunnitelmaan: Ilman konkreettista näyttöä on vaikea priorisoida lokitietojen muutoksia, sääntöjen hienosäätöä tai arkkitehtuurityötä, jotka parantaisivat vastausta merkittävästi.
Tilannetta kiristävät vielä sääntelyn asettamat määräajat. NIS2-direktiivin mukainen tietoturvaloukkausten ilmoittaminen voi edellyttää varhaisvaroitusta 24 tunnin kuluessa ja tarkempia päivityksiä 72 tunnin kuluessa, kun taas GDPR-asetus asettaa oman 72 tunnin ilmoitusvelvollisuuden henkilötietojen tietoturvaloukkausten osalta. Jos TTX-harjoitusten tulokset eivät perustu siihen, mitä työkalut todellisuudessa havaitsevat ja kuinka nopeasti ne havaitsevat sen, johtajat ottavat käytännössä riskin näiden määräaikojen suhteen.
Esittelyssä Damovon 6-vaiheinen vastakkainasettelun integrointimenetelmä
Tämän aukon paikkaamiseksi Damovon hyökkäyssuuntautunut kyberturvallisuusneuvontatiimi (Lares) käyttää kuusivaiheista vastustajan näkökulmasta toteutettavaa integrointimenetelmää, joka lähtee liikkeelle yhdestä realistisesta uhkaskenaariosta ja etenee pöytäkeskustelusta aina todellisten hyökkäystaktiikoiden (TTP) toistamiseen ja uudelleentestaukseen asti.
Yleisellä tasolla nämä kuusi vaihetta ovat:
- Aloita uhasta, joka on yrityksellesi todella tärkeä.
- Laadi taulukko, johon kirjataan kaikki oletukset – ja kaikki aikataulut.
- Muunna tarina vastakkainasettelun TTP-ohjeistoksi.
- Toista TTP:t omassa ympäristössäsi.
- Tarkista telemetriatiedot pöytämallin oletusten kanssa.
- Korjaa, hienosäädä ja varmista parannus.
Jokainen vaihe on suunniteltu siten, että IT-johtajat, SOC-päälliköt sekä riskienhallinta-, lakiasiain- ja viestintäosastot toimivat samojen lähtökohtien ja todisteiden pohjalta sen sijaan, että ne toimisivat erillisten tehtävien ja esitysmateriaalien varassa.
Vaihe 1: Aloita uhasta, joka on yrityksellesi todella tärkeä
Kaikki alkaa uskottavasta skenaariosta, joka voisi todella aiheuttaa häiriöitä organisaatiossasi – ei pelkästään abstraktista ”jossain verkossa olevasta kiristysohjelmasta”. Skenaario rakentuu seuraavista osista:
- Sisäinen kyberuhkatiedustelu ja tapahtumahistoria.
- Alakohtainen tiedonjako (esimerkiksi ISAC-verkostot) ja ajantasaiset uhkaraportit.
- Oikeudellisen osaston, riskienhallinnan ja hankintaosaston näkemykset kriittisistä toimittajista ja kolmansien osapuolten aiheuttamista riskeistä.
Esimerkkejä ovat esimerkiksi keskeisen SaaS-palveluntarjoajan tietoturvaloukkaus, joka johtaa pilvipalvelun käyttöoikeuksien laajentumiseen liikevaihdon kannalta kriittisessä liiketoimintayksikössä, kohdennettu tietojenkalastelu, joka johtaa tunnistetietojen vaarantumiseen sekä hybridi-AD-ympäristössä että pilvipalveluiden käyttäjäryhmissä, tai tietojen vuotaminen asiakaspalvelutiimien käyttämien, yrityksen hyväksymien yhteistyötyökalujen kautta.
Jos yrityksesi tekniset johtajat tai sovellusvastaavat eivät usko, että tällainen tilanne voisi toteutua, he menettävät kiinnostuksensa; tämä ensimmäinen vaihe varmistaa, että he tunnistavat omat järjestelmänsä ja vastuualueensa tarinassa.
Vaihe 2: Suorita pöytäharjoitus, jossa kartoitetaan kaikki oletukset
Kun skenaario on valmis, seuraava askel on kohdennettu pöytäharjoitus, johon osallistuvat IT-, turvallisuus-, operatiiviset, lakiasiain- ja viestintäosastot. Tavoitteena on asettaa organisaatio paineen alle tilanteessa, jossa useat sääntelyyn ja sopimuksiin liittyvät määräajat kuluvat rinnakkain, eikä pelkästään käydä läpi yleistä toimintasuunnitelmaa.
Tähän sisältyvät NIS2-direktiivin varhaisvaroitus- ja ilmoitusmääräajat, GDPR-asetuksen 72 tunnin ilmoitusvelvollisuus tietoturvaloukkauksista sekä mahdolliset alakohtaiset tai sopimuksiin perustuvat ilmoituslausekkeet. Ohjaajat kiinnittävät nämä tiedot skenaarioon ja kysyvät jokaisessa vaiheessa, kuka vastaa luokittelusta, kuka on yhteydessä keneen ja milloin ilmoitukset aloitetaan, vaikka syy loukkaukseen olisi vielä epäselvä.
IT- ja SOC-johtajien kannalta tärkeintä on, että jokaisesta teknisestä toteamuksesta muodostuu selkeä oletus: ”saisimme tiedon tunnin kuluessa”, ”SIEM-järjestelmä korreloisi nämä tapahtumat”, ”IAM-analytiikka merkitsisi käyttäytymisen” tai ”voisimme eristää vaikutuksen kohteeksi joutuneet järjestelmät ennen viranomaisten ilmoittamista”. Nämä oletukset kirjataan ylös aikaleimoineen; niistä tulee hypoteeseja, joita vaiheissa 3 ja 4 testataan.
Vaihe 3: Muunna tarina vastustajan toimintamalliksi
Kun pohjatyö on valmis, Damovon hyökkäysinsinöörit muuntavat tarinan konkreettiseksi, käytännönläheiseksi TTP-ohjeistoksi. Ohjeiston laajuus on tiiviisti sovitettu skenaarioon sen sijaan, että pyrittäisiin harjoittelemaan jokaista tekniikkaa yleisen viitekehyksen puitteissa.
Esimerkiksi pilvipohjaisen tunnistetietojen vaarantumistilanteen varalle ohjeisto voi sisältää seuraavaa:
- Pilvipohjaisen tunnistautumispalveluntarjoajan tai SaaS-alustan tunnistetietojen varastamista ja tunnistetietojen uudelleenkäyttöä koskevat erityiset hyökkäysreitit.
- ”Maasta eläminen” -tekniikat, joissa hyödynnetään olemassa olevia hallintatyökaluja, skriptitoimintoja ja hyväksyttyjä palveluita.
- Tietojen vuotoreitit hyväksyttyjen pilvitallennuspalveluiden, sähköpostijärjestelmien tai yhteistyösovellusten kautta.
Tämän vaiheen aikana IT-arkkitehtuuritiimi ja SOC-tiimi ovat mukana prosessissa, jotta toimintasuunnitelma vastaa todellisia valvontamenetelmiä, lokitietojen keräysmahdollisuuksia ja muutoksenhallinnan rajoituksia. Näin vältetään tilanne, jossa testit keskittyvät hyökkäyksiin, joille ympäristösi ei ole alttiina, tai valvontamenetelmiin, joita tuotantoympäristössä ei tosiasiassa käytetä.
Vaihe 4: Toista TTP:t omassa ympäristössäsi
Seuraavaksi toteutetaan hallittu purple team , jossa hyödynnetään laadittua pelisuunnitelmaa tuotantoympäristössä tai tuotantoympäristöä vastaavassa ympäristössä. Tässä vaiheessa pöytäharjoituksen oletukset korvataan työkaluista ja tiimeistä havaittavalla käyttäytymisellä.
Tässä vaiheessa Damovon hyökkäyssuuntautunut kyberturvallisuusneuvontatiimi (Lares) tekee yhteistyötä asiakkaan SOC- ja IT-tiimien kanssa kolmen keskeisen tuloksen saavuttamiseksi:
- Toteutustilanne: mitkä hyökkäysvaiheet onnistuivat, mitkä estettiin ja mitkä havaittiin vain osittain.
- Telemetrian kattavuus: tapahtumat ja hälytykset EDR/XDR-, SIEM- ja identiteettialustoilta, pilvilokeista ja verkkovalvonnasta sekä näkyvyyden aukot, joissa odotetut tiedot puuttuvat tai viivästyvät.
- Aikataulut: todellinen keskimääräinen havaitsemisaika (MTTD) ja keskimääräinen reagointiaika (MTTR) eri tiimeissä ja tasoilla.
Lares kuvailee tätä organisaation hermojärjestelmän testaamiseksi: kaikkea sitä, mikä sijaitsee hyökkääjän näppäinpainallusten ja organisaation hallintapaneelien välissä. SOC-päälliköille tämä on hetki, jolloin havaitsemissäännöt ja toimintamenettelyt pääsevät vihdoin koetukselle juuri niissä tilanteissa, joista organisaatiossa keskusteltiin vaiheessa 2.
Vaihe 5: Vertaa telemetriatietoja teoreettisiin oletuksiin
Viidennessä vaiheessa menetelmä paljastaa todellisen valmiusvajeen. Pöytäharjoituksen aikataulu ja päätökset asetetaan rinnakkain TTP-tallenteen tuottaman aineiston kanssa.
Tyypillisiä löydöksiä ovat:
- Johto oletti, että ”havaitsemme tämän 30 minuutin kuluessa”; telemetriatiedot osoittavat, että ensimmäinen merkityksellinen hälytys saapui vasta 90 minuutin kuluttua, koska pilvipalvelun lokit viivästyivät tai olivat puutteellisia.
- Esitysmateriaalissa todettiin, että ”SIEM-järjestelmä korreloi nämä tapahtumat”; todellisuudessa yksittäiset lokit olivat kyllä olemassa, mutta korrelaatiosäännöt eivät koskaan lauenneet, joten toiminta hukkuu taustakohinaan.
- Suunnitelman mukaan IAM:n tai UEBA:n oli tarkoitus ilmoittaa epätavallisesta tunnuksen käytöstä; toistotestissä hälytystä ei syntynyt, koska analytiikkatoimintoja ei ollut otettu käyttöön kyseisen palveluntarjoajan tai asiakkaan osalta.
Tämän pohjalta Damovo auttaa mittaamaan esimerkiksi seuraavia mittareita: oletusten tarkkuusaste (kuinka suuri osuus TTX-teknisistä oletuksista osoittautui oikeiksi), havaitsemistarkkuus (testattujen käyttäytymismallien signaali-kohinasuhde) sekä korjaustoimenpiteiden validointi (kuinka monta havaittua puutetta on onnistuttu korjaamaan uusintatesteissä). Nämä mittarit tarjoavat IT-johtajille ja SOC-vastaaville huomattavasti konkreettisempaa raportointiainesta kuin yleiset ”kypsyysaste”-pisteet.
Vaihe 6: Korjaa, hienosäädä ja varmista parannus
Viimeisessä vaiheessa kaikki tämä tieto muutetaan mitattavaksi edistymiseksi. Damovo tekee yhteistyötä tiimienne kanssa korjaustoimenpiteiden priorisoimiseksi riskien, sääntelyvaatimusten ja toteutuksen vaativuuden perusteella, minkä jälkeen muutokset vahvistetaan kohdennetuilla uusintatesteillä.
Yleisiä parannuksia ovat muun muassa:
- Lokitietojen aukkojen korjaaminen ja telemetriatietojen yhdenmukaistaminen pilvi-, SaaS-, verkko- ja tunnistusalustojen välillä.
- SIEM-korrelaatiosääntöjen, EDR/XDR-käytäntöjen ja IAM-analyysien hienosäätö tai luominen, jotka tunnistavat nimenomaan toistuvat käyttäytymismallit.
- Tapahtumien luokittelua, eskalointia ja viestintää koskevien menettelyohjeiden mukauttaminen, jotta pöytäharjoituksessa ilmenneet pullonkaulat saadaan poistettua.
TTP-ohjeiston asiaankuuluvat osat suoritetaan tämän jälkeen uudelleen, jotta voidaan varmistaa, että MTTD ja MTTR ovat parantuneet ja että aiemmin huomaamatta jäänyt toiminta havaitaan nyt luotettavasti. IT-johdolle tämä tarjoaa kunkin skenaarion osalta vertailun ennen ja jälkeen: tässä on se, mitä oletimme, mitä havaitsimme, mitä muutimme ja kuinka paljon nopeammin ja luotettavammin voimme nyt reagoida.
Miltä tämä näyttää käytännössä: pilvipohjaisen tunnistetiedon vaarantuminen
Kuvitellaan tilanne, josta monet organisaatiot ovat nykyään huolissaan: kriittisen SaaS-palveluntarjoajan tietoturvaloukkaus, joka johtaa käyttöoikeuksien laajentumiseen pilvipalvelussa.
- Vaihe 1: Uhkatiedot osoittavat, että identiteetin tarjoajaan kohdistuu aktiivinen toimitusketjuriski.
- Vaiheessa 2 skenaariossa oletetaan, että IAM-analytiikka havaitsee poikkeavan tunnuksen käytön ja SOC tunnistaa henkilöllisyyden viidentoista minuutin kuluessa, samalla kun NIS2-varhaisvaroitus- ja GDPR-raportointiajat ovat jo käynnissä.
- Vaihe 3: Insinöörit laativat TTP-ohjeiston, joka keskittyy pilvipalveluiden tunnistetietojen varastamiseen ja tunnistetietojen uudelleenkäyttöön ja joka on räätälöity juuri teidän ympäristöönne.
- Vaihe 4: purple team tunnuksen. EDR ei havaitse lainkaan pilvipalveluun kohdistuvaa liikennettä, eikä SIEM-sääntöjä laukea, koska pilvipalvelun lokit on määritetty väärin.
- Vaiheessa 5 käy selväksi, että oletus 15 minuutin eristämisestä oli olemassa olevan telemetriatiedon perusteella täysin epärealistinen; hälytystä ei annettu lainkaan.
- Vaihe 6: Lokitiedot on korjattu, IAM-korrelaatiohakut on otettu käyttöön ja skenaario suoritetaan uudelleen. Tällä kertaa SOC havaitsee ja eristää tunnistetiedot 12 minuutissa, jolloin oletuksesta tulee todistettu kyky.
Tällainen konkreettinen, todisteisiin perustuva kuvaus helpottaa seurantajärjestelmien kehittämistyön, lokitietojen keräämiseen tehtävien investointien sekä prosessimuutosten perustelemista sekä sisäisille sidosryhmille että sääntelyviranomaisille.
Miten Damovo voi auttaa
Laresin tarjoaman Damovo Security Services -palvelun avulla organisaatiot voivat ottaa tämän kuusivaiheisen Adversarial Integration -menetelmän käyttöön omissa ympäristöissään osana jatkuvaa validointiohjelmaa, ei pelkästään kertaluonteisena hankkeena.
Damovo voi auttaa teitä yhteistyössä IT- ja SOC-tiimienne kanssa seuraavissa asioissa:
- Suunnittele realistisia, uhkatekijöihin perustuvia skenaarioita, jotka vastaavat toimintaympäristöäsi ja sääntelyyn liittyviä riskejäsi.
- Suorita testattavia oletuksia ja päätöslokeja tuottavia testauskäsikirjoituksia yleisten toimintaluetteloiden sijaan.
- Suorita kohdennettu TTP-toistokoe, jotta voidaan varmistaa tunnistuksen ja reagoinnin toimivuus kyseisissä tilanteissa.
- Määritä valmiusvaje mittareilla, joita hallitukset, tilintarkastajat ja sääntelyviranomaiset pystyvät ymmärtämään.
Luo toistettava korjaus- ja uudelleentestausprosessi, joka parantaa suorituskykyä ajan myötä.
Tee seuraavasta pöytäkattauksestasi todistusaineistoa
Jos olet suunnittelemassa seuraavaa pöytäharjoitustasi, nyt on oikea hetki tehdä siitä muutakin kuin pelkkä työpaja. Yhdistämällä pöytäharjoituksen ja TTP-tallenteen katselun jäsenneltyyn, kuusivaiheiseen sykliin voit siirtyä oletuksista ja diaesityksistä kohti reaaliaikaista dataa, aikatauluja ja todistettuja parannuksia.
Seuraava vaihe: keskustele Damovo-tilitiimisi kanssa tai ota suoraan yhteyttä Lares-tiimiin selvittääksesi, kuinka voimme auttaa sinua ottamaan käyttöön 6-vaiheisen Adversarial Integration Methodology -menetelmän organisaatiossasi.