Tietoturvatapahtumat ovat tapahtumia tai toimintoja, jotka viittaavat mahdolliseen tietoturvarikkomukseen tai uhkaan organisaation tietojärjestelmissä. Ne voivat olla mitä tahansa epäilyttävästä kirjautumisyrityksestä vakavaan tietomurtoon. Tietoturvatapahtumien tunnistaminen ja niiden asianmukainen käsittely ovat olennaisia osia yritysten ja organisaatioiden tietoturvapolitiikkaa. Tietoturvatapahtumien seuranta ja analysointi auttavat organisaatioita tunnistamaan ja torjumaan uhat ennen kuin ne voivat aiheuttaa merkittävää vahinkoa.

Tapahtumia tulee monenlaisista lähteistä, kuten käyttöjärjestelmien, tietoturvatuotteiden (palomuuri, antivirus, ids/ips, jne), sovellusten, palvelinten, tietokantojen yms. lokeista.

Lähtökohtaisesti kaikki tapahtumat, jossa liikkuu tietoa jota halutaan suojata, kannattaa tallentaa ja säilyttää. Tämä johtuu siitä, että kun jonain päivänä tietoturvaloukkaus osuu kohdallesi, pystyt selvittämään tarkalleen mitä on tapahtunut ja arvioimaan vahingon laajuuden.

Ajatellaan samaa skenaariota näiden tietojen kanssa ja ilman niitä.

Skenaario: Sinulla on 1000 yritysasiakasta. Rikollinen murtautuu palveluusi ja varastaa 200 riviä tietoa yhteensä kuudelta eri asiakkaalta.

Jos sinulla on hyvät lokit: Joudut ilmoittamaan 

 yritysasiakkaalle että heidän tietojaan on vuotanut ja voit kertoa tarkalleen mitä tietoja on vuotanut ja kuinka paljon.

Jos sinulla ei ole hyviä lokeja, etkä tiedä että kenen asiakkaiden tietoja on viety ja kuinka paljon, joudut ilmoittamaan jokaiselle 

asiakkaalle että heidän tietojaan on saatettu viedä ja et tiedä kuinka paljon.

Tietoturvahälytys kannattaa tehdä silloin kun havaitaan uhkaava tilanne. Tällaisia hälytyksiä ei saisi tulla liikaa jotta vältytään hälytysväsymykseltä, mutta toisaalta ei myöskään liian vähän koska muuten hyökkäykset eivät välttämättä jää haaviin. Tasapaino on tärkeää, ja oikeiden lokien kerääminen sekä tehokkaan säännöstön rakentaminen vaativat sekä teknistä osaamista että kokonaisvaltaista ymmärrystä suojattavasta ympäristöstä.

Jokainen ympäristö on uniikki, mutta tässä on jotain melko yleispäteviä esimerkkejä tilanteista joista kannattaa tehdä hälytys.

HTTP-viestit taustajärjestelmään joita ei olisi pitänyt pystyä lähettämään käyttöliittymän kautta

Tämä on yksi parhaista sekä valitettavasti vähiten hyödynnetyistä tavoista havaita oikeita hyökkäysyrityksiä suoraan suojattavasta sovelluksesta käsin. Menetelmä on seuraava: 

Tee (esimerkiksi) pääsynhallintaan ja syötteen validointiin liittyvät kontrollit 

 palvelimen että selaimen päähän. Tällöin tavallisessa käytössä palvelimen päässä olevia syötteenvalidointi/pääsynhallintakontrolleja ei pitäisi tarvita, koska asiat on tarkitettu jo selaimen päässä.

Jos kyseisiin kontrolleihin tulee osumia palvelimen päässä, se tarkoittaa että joku on (burpilla, hyökkäystyökalulla, ym.) mennyt käyttöliittymän ohi ja lähettänyt HTTP-viestejä suoraan.

Tämä lähestymistapa mahdollistaa myös automaattisen uhkan torjunnan suoraan sovelluksessa. Esimerkiksi sovellus voi blokata häiriökäyttäytyvän IP-osoitteen vaikka 10 epäilyttävän HTTP-viestin läpi. Yritäpäs sellainen sovellus skannata burpilla :)

Hälyttäminen egress-palomuurisääntöjen osumista on mainio keino havaita erittäin vakava tilanne jossa hyökkääjä on jo päässyt mahdollisesti ajamaan jopa mielivaltaista koodia suojattavassa ympäristössä, mutta komentokanavan muodostaminen / tiedon vuotoyritys on jäänyt egress -palomuurisääntöön kiinni.

Tämä lähestymistapa edellyttää toki että tietoverkon turvakontrollit ovat sillä tasolla että ulospäin lähtevä liikenne on ylipäätään blokattu. Jos on, niin tätä hälytystä kannattaa ehdottomasti hyödyntää.

WAF (sovelluspalomuurin) lokit oikealla host-otsakkeella

Jos suojattavan sovelluksen edessä on WAF-tuote (niin kuin kannattaa olla), joka automaattisesti tunnistaa ja yrittää estää selkeästä haitallisia HTTP-viestejä saavuttamasta suojattavaa sovellusta, sen lokit voivat olla hälyttämisen arvoisia. Tähän liittyy kuitenkin tärkeä 

, nimittäin WAF-tuotteiden haaviin jää Internetistä tulevaa melua päivittäin. Melu kuitenkin kohdistuu tyypillisesti IP-osoitteisiin, joten ongelma on helppo ratkaista. Tee hälytys vain silloin, kun host-header vastaa sovelluksen omaa URL-osoitetta. Tällöin vain kohdennetut hyökkäykset jäävät haaviin, ja melu saa jäädä omaan arvoonsa.

Sovelluksen virheilmoitukset jotka indikoivat injektiohaavoittuuutta

Jotkut sovelluslokit ovat sellaisia että ne viestivät tilanteesta jossa sovelluksessa saattaa hyvinkin olla vakava haavoittuvuus ja että hyökkääjä on hyvinkin saattanut juuri äsken löytää sen.

Otetaan SQL-injektio esimerkkinä. Voi olla että kehittäjä on tehnyt toiminnon jossa SQL:ää rakennetaan turvattomasti, mutta sovelluksessa on selaimen puolinen kontrolli joka rakaa syötteen turvalliseen muotoon. Tällöin virhe ei koskaan paljastu normaalissa käytössä.

Mitä sitten kun sovelluksen virhelokiin ilmestyy "SQL Syntax Error: Near ...WHERE...". Tämä voi hyvin olla merkki siitä, että hyökkääjä on juuri kokeillut laittaa Burpilla hipsun johonkin parametriin ja haavoittuvuus on paljastunut. Tästä ei välttämättä mene montaa minuuttia ennen kuin sqlmap on ajettu ja tietokanta on vaihtanut omistajaa.

Palvelinympäristön haittaohjelmasuojauksen hälytykset

Erityisesti palvelinympäristö kannattaa varustaa HIDS/HIPS (host-based intrusion detection / prevention system) -tuotteella kuten Falco kubernetes/muulle konttiteknologialle tai vaikkapa OSSEC Linux-palvelimille. Nämä tuotteet osaavat havainnoida poikkeamia kuten epäilyttäviä tietoverkkoyhteyksiä, tiedostoja, prosesseja tai kirjautumisia ja tehdä niistä hälytyksiä, sekä mahdollisesti torjuakin uhkia reaaliaikaisesti tuotteilla kuten fail2ban tai OSSEC/Falco active response skriptit.

Työasemien haittaohjelmasuojauksen hälytykset

Tämä saattaa olla itsestään selvä, mutta kun työntekijän työasemalta tulee hälytys niin saattaa hyvinkin olla kiire laittamaan työntekijän työasema lukkoon. EDR (endpoint detection and response) -tuotteilla on mahdollista keskitetysti havainnoida hälytyksiä ja esimerkisi eristää saastunut työasema väliaikaisesti Internetistä.

Tehokkaan tietoturvavalvonnan mahdollistaminen vaatii luovuutta, teknistä osaamista ja kokonaisvaltaista ymmärrystä suojattavasta kohteesta. Suuressa yrityksessä tämä kokonaisuus jakautuu väkisinkin usean ihmisen ja todennäköisesti usean eri bisnesyksikön välille, jolloin kommunikointi yrityksen sisällä on kriittistä.

Suurimmilla yrityksillä on SOC (security operations center) jonka tehtävä on korreloida tietoturvatapahtumia koko yrityksen valtavasta tapahtumamassasta ja etsiä patterneja jotka indikoivat uhkia. Tekemällä aktiivista yhteistyötä esimerkiksi eri yksiköiden kehittäjien kanssa jotta ensinnäkin sovelluksiin ja niiden toimintaympäristöihin saadaan oikeat lokit syntymään ja toisekseen saadaan välitettyä SOC:iin tieto siitä että mitkä hälytykset ovat indikaattoreita oikeista uhista, saadaan yrityksen havainnointikyvykkyys erittäin hyväksi.

## Mitä ovat tietoturvatapahtumat?

Tietoturvatapahtumat ovat tapahtumia tai toimintoja, jotka viittaavat mahdolliseen tietoturvarikkomukseen tai uhkaan organisaation tietojärjestelmissä. Ne voivat olla mitä tahansa epäilyttävästä kirjautumisyrityksestä vakavaan tietomurtoon. Tietoturvatapahtumien tunnistaminen ja niiden asianmukainen käsittely ovat olennaisia osia yritysten ja organisaatioiden tietoturvapolitiikkaa. Tietoturvatapahtumien seuranta ja analysointi auttavat organisaatioita tunnistamaan ja torjumaan uhat ennen kuin ne voivat aiheuttaa merkittävää vahinkoa.

Tapahtumia tulee monenlaisista lähteistä, kuten käyttöjärjestelmien, tietoturvatuotteiden (palomuuri, antivirus, ids/ips, jne), sovellusten, palvelinten, tietokantojen yms. lokeista.

---

## Mitä kannattaa kerätä?

Lähtökohtaisesti kaikki tapahtumat, jossa liikkuu tietoa jota halutaan suojata, kannattaa tallentaa ja säilyttää. Tämä johtuu siitä, että kun jonain päivänä tietoturvaloukkaus osuu kohdallesi, pystyt selvittämään tarkalleen mitä on tapahtunut ja arvioimaan vahingon laajuuden.

Ajatellaan samaa skenaariota näiden tietojen kanssa ja ilman niitä.

Skenaario: Sinulla on 1000 yritysasiakasta. Rikollinen murtautuu palveluusi ja varastaa 200 riviä tietoa yhteensä kuudelta eri asiakkaalta.

- Jos sinulla on hyvät lokit: Joudut ilmoittamaan **kuudelle** yritysasiakkaalle että heidän tietojaan on vuotanut ja voit kertoa tarkalleen mitä tietoja on vuotanut ja kuinka paljon.
- Jos sinulla ei ole hyviä lokeja, etkä tiedä että kenen asiakkaiden tietoja on viety ja kuinka paljon, joudut ilmoittamaan jokaiselle **tuhannelle **asiakkaalle että heidän tietojaan on saatettu viedä ja et tiedä kuinka paljon.

---

## Mistä kannattaa tehdä hälytys?

Tietoturvahälytys kannattaa tehdä silloin kun havaitaan uhkaava tilanne. Tällaisia hälytyksiä ei saisi tulla liikaa jotta vältytään hälytysväsymykseltä, mutta toisaalta ei myöskään liian vähän koska muuten hyökkäykset eivät välttämättä jää haaviin. Tasapaino on tärkeää, ja oikeiden lokien kerääminen sekä tehokkaan säännöstön rakentaminen vaativat sekä teknistä osaamista että kokonaisvaltaista ymmärrystä suojattavasta ympäristöstä.

Jokainen ympäristö on uniikki, mutta tässä on jotain melko yleispäteviä esimerkkejä tilanteista joista kannattaa tehdä hälytys.

### HTTP-viestit taustajärjestelmään joita ei olisi pitänyt pystyä lähettämään käyttöliittymän kautta

Tämä on yksi parhaista sekä valitettavasti vähiten hyödynnetyistä tavoista havaita oikeita hyökkäysyrityksiä suoraan suojattavasta sovelluksesta käsin. Menetelmä on seuraava: 

- Tee (esimerkiksi) pääsynhallintaan ja syötteen validointiin liittyvät kontrollit **sekä** palvelimen että selaimen päähän. Tällöin tavallisessa käytössä palvelimen päässä olevia syötteenvalidointi/pääsynhallintakontrolleja ei pitäisi tarvita, koska asiat on tarkitettu jo selaimen päässä.
- Jos kyseisiin kontrolleihin tulee osumia palvelimen päässä, se tarkoittaa että joku on (burpilla, hyökkäystyökalulla, ym.) mennyt käyttöliittymän ohi ja lähettänyt HTTP-viestejä suoraan.
- Jos näin käy, tee heti hälytys.
- Tämä lähestymistapa mahdollistaa myös automaattisen uhkan torjunnan suoraan sovelluksessa. Esimerkiksi sovellus voi blokata häiriökäyttäytyvän IP-osoitteen vaikka 10 epäilyttävän HTTP-viestin läpi. Yritäpäs sellainen sovellus skannata burpilla :)

### Osumat egress -palomuurisääntöihin

Hälyttäminen egress-palomuurisääntöjen osumista on mainio keino havaita erittäin vakava tilanne jossa hyökkääjä on jo päässyt mahdollisesti ajamaan jopa mielivaltaista koodia suojattavassa ympäristössä, mutta komentokanavan muodostaminen / tiedon vuotoyritys on jäänyt egress -palomuurisääntöön kiinni.

Tämä lähestymistapa edellyttää toki että tietoverkon turvakontrollit ovat sillä tasolla että ulospäin lähtevä liikenne on ylipäätään blokattu. Jos on, niin tätä hälytystä kannattaa ehdottomasti hyödyntää.

### WAF (sovelluspalomuurin) lokit oikealla host-otsakkeella

Jos suojattavan sovelluksen edessä on WAF-tuote (niin kuin kannattaa olla), joka automaattisesti tunnistaa ja yrittää estää selkeästä haitallisia HTTP-viestejä saavuttamasta suojattavaa sovellusta, sen lokit voivat olla hälyttämisen arvoisia. Tähän liittyy kuitenkin tärkeä *mutta*, nimittäin WAF-tuotteiden haaviin jää Internetistä tulevaa melua päivittäin. Melu kuitenkin kohdistuu tyypillisesti IP-osoitteisiin, joten ongelma on helppo ratkaista. Tee hälytys vain silloin, kun host-header vastaa sovelluksen omaa URL-osoitetta. Tällöin vain kohdennetut hyökkäykset jäävät haaviin, ja melu saa jäädä omaan arvoonsa.

### Sovelluksen virheilmoitukset jotka indikoivat injektiohaavoittuuutta

Jotkut sovelluslokit ovat sellaisia että ne viestivät tilanteesta jossa sovelluksessa saattaa hyvinkin olla vakava haavoittuvuus ja että hyökkääjä on hyvinkin saattanut juuri äsken löytää sen.

Otetaan SQL-injektio esimerkkinä. Voi olla että kehittäjä on tehnyt toiminnon jossa SQL:ää rakennetaan turvattomasti, mutta sovelluksessa on selaimen puolinen kontrolli joka rakaa syötteen turvalliseen muotoon. Tällöin virhe ei koskaan paljastu normaalissa käytössä.

Mitä sitten kun sovelluksen virhelokiin ilmestyy "SQL Syntax Error: Near ...WHERE...". Tämä voi hyvin olla merkki siitä, että hyökkääjä on juuri kokeillut laittaa Burpilla hipsun johonkin parametriin ja haavoittuvuus on paljastunut. Tästä ei välttämättä mene montaa minuuttia ennen kuin sqlmap on ajettu ja tietokanta on vaihtanut omistajaa.

### Palvelinympäristön haittaohjelmasuojauksen hälytykset

Erityisesti palvelinympäristö kannattaa varustaa HIDS/HIPS (host-based intrusion detection / prevention system) -tuotteella kuten Falco kubernetes/muulle konttiteknologialle tai vaikkapa OSSEC Linux-palvelimille. Nämä tuotteet osaavat havainnoida poikkeamia kuten epäilyttäviä tietoverkkoyhteyksiä, tiedostoja, prosesseja tai kirjautumisia ja tehdä niistä hälytyksiä, sekä mahdollisesti torjuakin uhkia reaaliaikaisesti tuotteilla kuten fail2ban tai OSSEC/Falco active response skriptit.

### Työasemien haittaohjelmasuojauksen hälytykset

Tämä saattaa olla itsestään selvä, mutta kun työntekijän työasemalta tulee hälytys niin saattaa hyvinkin olla kiire laittamaan työntekijän työasema lukkoon. EDR (endpoint detection and response) -tuotteilla on mahdollista keskitetysti havainnoida hälytyksiä ja esimerkisi eristää saastunut työasema väliaikaisesti Internetistä.

---

## Summa summarum

Tehokkaan tietoturvavalvonnan mahdollistaminen vaatii luovuutta, teknistä osaamista ja kokonaisvaltaista ymmärrystä suojattavasta kohteesta. Suuressa yrityksessä tämä kokonaisuus jakautuu väkisinkin usean ihmisen ja todennäköisesti usean eri bisnesyksikön välille, jolloin kommunikointi yrityksen sisällä on kriittistä.

Suurimmilla yrityksillä on SOC (security operations center) jonka tehtävä on korreloida tietoturvatapahtumia koko yrityksen valtavasta tapahtumamassasta ja etsiä patterneja jotka indikoivat uhkia. Tekemällä aktiivista yhteistyötä esimerkiksi eri yksiköiden kehittäjien kanssa jotta ensinnäkin sovelluksiin ja niiden toimintaympäristöihin saadaan oikeat lokit syntymään ja toisekseen saadaan välitettyä SOC:iin tieto siitä että mitkä hälytykset ovat indikaattoreita oikeista uhista, saadaan yrityksen havainnointikyvykkyys erittäin hyväksi.


Mitä ovat tietoturvatapahtumat? Mitä kannattaa kerätä ja milloin kannattaa tehdä hälytys?

Tällä kurssilla käymme läpi organisaation tietoturvavalvontaan liittyviä käsitteitä.

Tällä kurssilla käymme läpi organisaation tietoturvavalvontaan liittyviä asioita.

Mitä ovat tietoturvatapahtumat? Mitä kannattaa kerätä ja milloin kannattaa tehdä hälytys?

Mitä ovat tietoturvatapahtumat?

Hakkeroinnin oppiminen alkaa tästä