Roskapostin Torjuntakeinot Suomalaisissa IT-Alan Yrityksissä

Roskapostin torjuntakeinot suomalaisissa IT-alan yrityksissä

Markus Pyhäranta

Opinnäytetyö Tietojenkäsittelyn koulutusohjelma 2019 Tiivistelmä

Tekijä(t) Markus Pyhäranta Koulutusohjelma Tietojenkäsittelyn koulutusohjelma Raportin/Opinnäytetyön nimi Sivu- ja liitesi- Roskapostin torjuntakeinot suomalaisissa IT-alan yrityksissä vumäärä 135 + 82

Tutkimus toteutettiin huhti-elokuussa 2019 ja siinä tutkittiin suomalaisten IT-alan yritysten käyttämiä roskapostin torjuntakeinoja. Päämääränä oli ymmärtää paremmin roskapostitusta ilmiönä sekä siihen vastauksena kehitettyjä teknologioita. Yksi tavoitteista oli kerätä kyselylomakkeen avulla laaja näyte yritysten käyttämistä roskapostin torjuntakeinoista. Tu- losten pohjalta kehitettiin vertailuarvo kullekin yrityskoolle, jota voidaan käyttää organisaatioiden sähköpostipalveluiden kehittämiseen.

Opinnäytetyön tietoperustassa käsitellään sähköpostin toimintaa tutkimusosion aihepiirin ymmärtämiseen vaadittavalla tarkkuudella. Tietoperustassa kerrotaan sähköpostiviestin ra- kenteesta, sähköposti-infrastruktuurin komponenteista, roskapostista ja sen aiheuttamista turvallisuusuhista. Lopuksi esitetään yleisesti käytettyjä roskapostin torjuntakeinoja.

Tietoperustan jälkeen esitellään tutkimuksessa käytetyt aineistot ja tutkimusmenetelmät. Roskapostin torjuntaa käsiteltiin yritysten sähköpostipalvelimien ylläpitäjien näkökulmasta. 310 yritykselle lähetettiin tutkimuksessa kyselylomake, jolla kartoitettiin käytettyjä sähkö- postipalveluratkaisuja, tyytyväisyyttä palvelujen roskapostin torjuntaan ja yritysten käyttä- miä torjuntaratkaisuja. Lopulta tutkimukseen vastasi 74 suomalaista IT-alan yritystä, mikä vastasi lähes 25 % lomakkeen kaikista vastaanottajista.

Hypoteesina oli, että yritykset ovat siirtäneet sähköpostipalvelunsa laajalti pilvipalvelupohjaisiksi, mitä tutkimustulokset tukivat. Noin 75 % kaikista vastaajista käytti pilvipalvelupohjaista sähköpostipalvelua. Enemmistö käytti Office 365 -palvelua yrityssähköpostiinsa ja kuvasi palvelutyytyväisyyttään keskiarvolla 4,1 asteikolla 1-5. Tyytyväisyys oli tunnetuista sähköpostipalveluista suurinta G Suite -palvelua käyttäneillä, jotka kuvasivat palvelutyyty- väisyyttään keskiarvolla 4,3. Tyypillinen vastaaja torjui roskapostia sen lähteen ja sisällön perusteella kolmella eri tekniikalla sähköpostipalveluunsa kuuluvien oletustekniikoiden ohella. Lisäksi vastaaja varmisti sähköpostin ja lähettäjän todennuksen sekä palvelun oletustekniikoilla että kahdella muulla menetelmällä. Tulokset jaettiin omiin kappaleisiinsa yrityskokojen perusteella, jotta tietojen vertailu samankokoisten yritysten välillä olisi helpompaa.

Opinnäytetyö päättyy pohdintaosioon, jossa käsitellään tutkimustulosten merkitystä, tulosten luotettavuutta ja tutkimuksen onnistumista. Yrityksille esitetään myös suosituksia tutkimustulosten pohjalta. Lopuksi tarkastellaan opinnäytetyön tekijän oppimista ja kehitystä opinnäytetyöprojektin aikana.

Asiasanat roskaposti, torjuntakeinot, suodatus, todennus, sähköposti, kyselytutkimus

Sisällys

1 Johdanto ...... 1 1.1 Tutkimuksen tavoite ...... 1 1.2 Tutkimuksen rajaus ...... 2 1.3 Tutkimuskysymykset ja hypoteesit ...... 2 2 Käsitteet ja käännökset ...... 4 3 Sähköpostin toiminta ...... 5 3.1 Sähköpostiviestin rakenne ...... 5 3.1.1 Kirjekuori ...... 6 3.1.2 Otsaketiedot ...... 6 3.1.3 Sisältöosa ...... 9 3.2 Sähköpostin käyttäjäohjelma ...... 9 3.3 Sähköpostin siirto-ohjelma ja SMTP-protokolla ...... 9 3.4 Sähköpostin toimitusohjelma ...... 12 3.4.1 POP3 ...... 12 3.4.2 IMAP ...... 13 3.4.3 MAPI ja EAS ...... 13 4 Roskaposti ...... 14 4.1 Sisäänpäin suuntautuva roskaposti ...... 15 4.2 Ulospäin suuntautuva roskaposti ...... 15 4.3 Roskapostityypit ja roskapostitusmenetelmät ...... 15 5 Roskapostintorjunta sisällön tai lähteen perusteella ...... 18 5.1 SMTP-liikenteen suodatus ...... 18 5.1.1 Sisäänpäin suuntautuvassa liikenteessä ...... 18 5.1.2 Ulospäin suuntautuvassa liikenteessä ...... 19 5.2 DNS-pohjainen mustalistaus (DNSBL) ...... 20 5.3 Harmaalistaus ...... 22 5.4 Nolisting ...... 23 5.5 Sähköpostin sisällönsuodatus ...... 25 5.6 Bayesilainen suodatus ...... 26 5.7 Fyysiset roskapostisuodattimet ...... 28 5.8 Pilvipalvelupohjainen roskapostisuodatus ...... 28 5.8.1 Office 365 ...... 29 5.8.2 G Suite ...... 31 5.8.3 D-Fence ...... 32 6 Lähettäjän ja viestin todentaminen sähköpostiliikenteessä ...... 34 6.1 Sender Policy Framework (SPF) ...... 34 6.1.1 SPF-tietueen tunnisteet ...... 35

6.1.2 SPF-tarkistus ...... 36 6.2 Sender ID ...... 38 6.3 DomainKeys Identified Mail (DKIM) ...... 39 6.3.1 DKIM-tietueen tunnisteet ...... 40 6.3.2 DKIM-allekirjoituksen tunnisteet ...... 41 6.3.3 DKIM-tarkistus ...... 42 6.4 Domain-based Message Authentication, Reporting & Conformance (DMARC) ... 44 6.4.1 DMARC-tietueen tunnisteet ...... 45 6.4.2 DMARC-tarkistus ...... 46 6.4.3 DMARC-tekniikan käyttöönoton hyvät käytänteet ...... 48 6.5 Authenticated Received Chain (ARC) ...... 49 6.5.1 ARC-sarjojen otsakekentät ...... 49 6.5.2 ARC-tarkistus ...... 50 7 Aiemmat tutkimukset ...... 53 8 Aineisto ja tutkimusmenetelmät ...... 55 8.1 Aineiston keruu ...... 55 8.2 Aineiston käsittely ...... 57 9 Tulokset ...... 59 9.1 Mikroyritykset (1-9 henkilöä) ...... 59 9.1.1 Sähköpostipalveluiden käyttöosuudet mikroyrityksissä ...... 60 9.1.2 Palvelukohtainen tyytyväisyys mikroyrityksissä ...... 61 9.1.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyttömäärät mikroyrityksissä ...... 62 9.1.4 Todennukseen pyrkivien tekniikoiden käyttömäärät mikroyrityksissä...... 63 9.1.5 Muut torjuntatekniikat mikroyrityksissä ...... 64 9.2 Pienet yritykset (10-49 henkilöä) ...... 65 9.2.1 Sähköpostipalveluiden käyttöosuudet pienissä yrityksissä ...... 66 9.2.2 Palvelukohtainen tyytyväisyys pienissä yrityksissä ...... 66 9.2.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyttömäärät pienissä yrityksissä ...... 67 9.2.4 Todennukseen pyrkivien tekniikoiden käyttömäärät pienissä yrityksissä .. 68 9.2.5 Muut torjuntatekniikat pienissä yrityksissä ...... 69 9.3 Keskisuuret yritykset (50-249 henkilöä) ...... 71 9.3.1 Sähköpostipalveluiden käyttöosuudet keskisuurissa yrityksissä ...... 72 9.3.2 Palvelukohtainen tyytyväisyys keskisuurissa yrityksissä...... 73 9.3.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyttömäärät keskisuurissa yrityksissä ...... 74 9.3.4 Todennukseen pyrkivien tekniikoiden käyttömäärät keskisuurissa yrityksissä ...... 75

9.3.5 Muut torjuntatekniikat keskisuurissa yrityksissä ...... 76 9.4 Suuryritykset (250 henkilöä tai enemmän) ...... 77 9.4.1 Sähköpostipalveluiden käyttöosuudet suuryrityksissä ...... 78 9.4.2 Palvelukohtainen tyytyväisyys suuryrityksissä ...... 79 9.4.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyttömäärät suuryrityksissä ...... 80 9.4.4 Todennukseen pyrkivien tekniikoiden käyttömäärät suuryrityksissä ...... 81 9.4.5 Muut torjuntatekniikat suuryrityksissä ...... 82 9.5 Kaikki yritykset ...... 83 9.5.1 Sähköpostipalveluiden käyttöosuudet kaikissa yrityksissä ...... 84 9.5.2 Palvelukohtainen tyytyväisyys kaikissa yrityksissä ...... 85 9.5.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyttömäärät kaikissa yrityksissä ...... 86 9.5.4 Todennukseen pyrkivien tekniikoiden käyttömäärät kaikissa yrityksissä ... 87 9.5.5 Muut torjuntatekniikat kaikissa yrityksissä ...... 88 9.5.6 Muuta tietoa kaikkien yritysten vastauksista ...... 88 10 Pohdinta ...... 94 10.1 Tulosten arviointi ja tulkinta ...... 94 10.1.1 Mikroyritykset (1-9 henkilöä) ...... 94 10.1.2 Pienet yritykset (10-49 henkilöä) ...... 96 10.1.3 Keskisuuret yritykset (50-249 henkilöä) ...... 98 10.1.4 Suuryritykset (250 henkilöä tai enemmän) ...... 100 10.1.5 Kaikki yritykset ...... 102 10.2 Tulosten luotettavuus ja tutkimuksen onnistuminen ...... 106 10.3 Suositukset yrityksille ...... 111 10.4 Tulosten hyödyntämismahdollisuudet ...... 113 10.5 Oma oppiminen ...... 115 Lähteet ...... 119 Liitteet ...... 136 Liite 1. Käsitteet, termit ja lyhenteet ...... 136 Liite 2. SMTP-liikenteen suodatus Postfix-siirto-ohjelmassa ...... 149 Liite 3. Vapaaehtoiset DKIM-tunnisteet ...... 152 Liite 4. Vapaaehtoiset DMARC-tunnisteet ...... 154 Liite 5. Ensimmäisessä kyselyerässä IT-henkilöstölle kohdistettu viesti ...... 155 Liite 6. Ensimmäisessä kyselyerässä asiakaspalveluun tai tukeen lähetetty viesti ..... 156 Liite 7. Toisessa kyselyerässä IT-henkilöstölle kohdistettu viesti ...... 157 Liite 8. Toisessa kyselyerässä asiakaspalveluun tai tukeen lähetetty viesti ...... 158 Liite 9. Tutkimuksen kyselylomake ...... 159 Liite 10. D-Fence-sähköpostiturvayhtiön perustajan sähköpostihaastattelu ...... 165

Liite 11. Tutkimustulosten tulkinta...... 169 Liite 12. Kyselyvastaukset: Mikroyritykset (1-9 henkilöä) ...... 180 Liite 13. Kyselyvastaukset: Pienet yritykset (10-49 henkilöä) ...... 188 Liite 14. Kyselyvastaukset: Keskisuuret yritykset (50-249 henkilöä) ...... 197 Liite 15. Kyselyvastaukset: Suuryritykset (250 henkilöä tai enemmän) ...... 201 Liite 16. Kyselyvastaukset: Kaikki yritykset ...... 205

1 Johdanto

Sähköposti mahdollistaa kommunikoinnin suurelle määrälle ihmisiä samanaikaisesti, minkä vuoksi sillä on aina ollut suuri rooli organisaatioiden sisäisessä ja ulkoisessa vies- tinnässä. Koska sähköposti soveltuu hyvin myös luvattomaan suoramarkkinointiin sekä haittaohjelmien levitykseen, sen yleistyminen on johtanut laajaan väärinkäyttöön. Ilmiö on ristitty roskapostiksi ja reaktio siihen on ollut yksimielisesti negatiivista heti ensim- mäisestä lähetetystä roskapostista lähtien (Templeton 2019).

Roskapostiongelmaan on vuosien varrella vastattu kehittämällä useita viestin lähteeseen ja sisältöön tai lähettäjän todennukseen perustuvia tarkistusmenetelmiä ja torjuntatekniikoita. Tekniikoiden laajamittainen käyttö on kuitenkin luonut uuden ongelman väärien po- sitiivisten tarkistustulosten muodossa (Pivotal Veracity 2005, 6). Tämä on johtanut siihen, että sähköpostiviestejä joutuu roskapostikansioon väärin perustein suodattimien tarkistus- sääntöjen kiristyessä. Täydellistä ratkaisua ongelmaan ei ole, sillä kyseessä on roskapostittajien ja sähköpostiylläpitäjien välisestä kilpavarustelusta. Uusiin roskapostitrendeihin reagoidaan entistä kehittyneemmillä torjuntakeinoilla, mikä pakottaa roskapostittajia kehit- tämään ohjelmistojaan ohittamaan roskapostisuodattimien puolustukset. Ongelma pysyy ajankohtaisena niin kauan, kun roskapostituksen hyödyt ovat roskapostittajille haittapuolia suuremmat (Weidmann 2019, 20).

1.1 Tutkimuksen tavoite

Opinnäytetyön päämääränä on ymmärtää paremmin roskapostitusta ilmiönä ja siihen vastauksena kehitettyjä teknologioita, joita melkein kaikkien organisaatioiden tietohallinnoissa hyödynnetään. Yksi tutkimuksen tavoitteista oli kerätä kyselylomakkeen avulla laaja näyte suomalaisten IT-alan yritysten käyttämistä roskapostin torjuntakeinoista. Tulosten pohjalta kehitettiin vertailuarvo, johon yritykset voivat verrata omia käytäntöjään ja kehittää organi- saationsa sisäisiä ICT-palveluita. Tätä vertailuarvoa kutsutaan tutkimuksen tuloksissa yritysten tyypillisimmäksi vastaukseksi. Samalla kyselytutkimuksessa kartoitettiin yritysten käyttämiä sähköpostipalveluratkaisuja ja vastaajien tyytyväisyyttä käyttämiinsä palveluihin, mikä auttaa ymmärtämään alan ajankohtaista kehityssuuntaa.

Tietoperustassa käsitellään sähköposti-infrastruktuurin ja roskapostin torjuntakeinojen toimintaa laajuudella, joka antaa lukijalle hyvät lähtökohdat aihepiirin ymmärtämiseen. Vaikka opinnäytetyön pääpaino on kyselytutkimuksen tuloksissa, tietoperustan hyödynnet- tävyysarvo on pidetty tasolla, joka mahdollistaa torjuntatekniikoiden käyttöönoton.

1.2 Tutkimuksen rajaus

Tutkimus keskittyi suomalaisiin IT-alan yrityksiin. Edellytyksenä oli, että yritykset oli rekis- teröity Suomessa ja että niiden liiketoiminnan pääpaino keskittyi Suomen markkinoille, vaikka toimipisteitä olisi myös ulkomailla. Yritysten kotimaisuus ja toimiala tarkistetiin tutkimuksen potentiaalisten osallistujien kartoituksen yhteydessä. Tutkimuksen osallistujat luo- kiteltiin yrityskoon perusteella, ja tarkoituksena oli kerätä mahdollisimman laaja näyte erilaisia alan osaajia.

Roskapostin torjuntaa käsiteltiin yritysten sähköpostipalvelimien ylläpitäjien näkökulmasta. Tästä syystä siinä ei huomioitu sähköpostiohjelmissa loppukäyttäjien toimesta tapahtuvaa suodatusta. Loppukäyttäjät on yleisesti nostettu yhdeksi suurimmiksi organisaatioiden kohtaamista tietoturvariskeistä (Jalkanen 2019, 60-61) ja viestien todennus ei yleensä ole- kaan yksiselitteistä. Täten ei ole järkevää luottaa käyttäjien kykyyn arvioida sähköposti- viestien tai niiden lähettäjien aitoutta. Tutkimuksessa keskityttiin keinoihin, joilla vastuu roskapostin torjunnasta siirretään kokonaan pois loppukäyttäjältä. Tällaisia torjuntakeinoja ovat erilaiset sähköpostipalvelimilla suoritettavat tarkistukset, jolloin roskapostin torjunta tapahtuu jo ennen loppukäyttäjän sähköpostilaatikkoon päätymistä. On myös kehitetty tekniikoita, joilla yritys voi suojata ulospäin suuntauvan sähköpostinsa todennuksen ja estää toimialuenimensä käyttämisen sähköpostiosoitteiden väärentämisyrityksiin nimipalvelun tasolla. Kaikki loppukäyttäjän huomiota tai työtä edellyttävät torjuntakeinot katsottiin siis tutkimuksen rajauksen ulkopuolelle.

1.3 Tutkimuskysymykset ja hypoteesit

Opinnäytetyössä selvitetään vastaukset seuraaviin tutkimuskysymyksiin: − Mitä sähköpostipalveluratkaisuja yritykset käyttävät? − Kuinka tyytyväisiä yritykset ovat käyttämiinsä ratkaisuihin roskapostin torjunnan näkökulmasta? − Millaisin torjuntatekniikoin yritykset torjuvat roskapostia yrityksen toimialueelle suuntautuvassa sähköpostiliikenteessä? − Millaisin tekniikoin yritykset suojaavat toimialuenimensä väärinkäytöltä ja yrityksen ulospäin suuntautuvan sähköpostiliikenteen? − Mitä suosituksia yrityksille voidaan antaa tutkimustulosten pohjalta? − Mitä sähköpostipalveluratkaisuja erikokoisten yritysten suositellaan käyttävän? − Millaisin tekniikoin yritysten tulisi torjua roskapostia?

Hypoteesina on, että yritykset siirtävät ja ovat siirtäneet sähköpostipalveluitaan yhä enem- missä määrin pilvipalvelupohjaisiksi. Tällöin yritysten käyttämät roskapostin torjuntakeinot toimivat samalla pilvipalvelupohjaisesti ja niiden toteutus on laajasti palveluntarjoajan vastuulla. Tämä voi vaikuttaa tutkimukseen osallistuvien vastaajien kykyyn erotella käyttämi- ään torjuntatekniikoita yritysten sähköpostiympäristöjen ylläpidon helpottuessa. On siis

2 mahdollista, että kehitys on heikentänyt IT-henkilöstön asiantuntemusta roskapostitorjunnan saralla, mikä voi näkyä tutkimuksen tulosten tarkkuudessa.

Pilvipalveluihin suuntautuva kehitys on näkynyt koko IT-alan palvelutarjonnan alalla laajalti. Amazon, Google ja Microsoft ovat jo pitkään kilpailleet pilvipalvelujen markkinaosuuk- sista omilla pilvialustoillaan, ja kilvan odotetaan kiihtyvän tulevaisuudessa (De Leon 2019). Lisäksi esimerkiksi Microsoft on jo uudistanut tunnetun Windows 10 -käyttöjärjes- telmän ja Office 365 -pilvipalvelun yhden kattavan pilvipalvelupohjaisen kokonaisuuden alle, joka yhdistelee niihin myös uusimpia tietoturva- ja tietosuojaominaisuuksia (Microsoft 2019i). Nämä uudet Microsoft 365 -lisenssit tulevat tulevaisuudessa laajasti korvaamaan yritysten paikalliset Windows-ympäristöt ja erilliset Office 365 -tilaukset. Näistä syistä olisi odotettavaa, että tutkimuksessa havaittaisiin yritysten sähköpostipalveluratkaisujen nou- dattavan samaa kehitystä.

2 Käsitteet ja käännökset

Kaikkien opinnäytetyössä esiintyvien käsitteiden ja lyhenteiden määritelmät löytyvät opin- näytetyöraportin liitteestä 1. Suuri osa käsitteistä määritellään osana työn tietoperustaa. Tekstissä esiintyy silti myös käsitteitä, joita ei avata tietoperustassa tarkemmin. Sellaisia ovat pääasiassa lyhenteet ja termit, jotka tulkitaan alalla yleistiedoksi.

Opinnäytetyössä on käännetty englanninkielisiä termejä, joilla ei ole vakiintuneita suomen- noksia. Käännetyt termit on esitetty taulukossa 1.

Taulukko 1. Opinnäytetyön aihepiirin englanninkielisten termien suomennokset Käännös Alkuperäinen termi ARC-vahvistaja ARC validator ARC-sinetöijä ARC sealer ARC-sarja ARC set ARC-ketju ARC chain avoin välityspalvelin open relay karsija qualifier kirjekuori envelope kohdennettu verkkourkinta spear phishing laajennettu SMTP-kanavointi pipelining mekanismi mechanism määrite modifier otsaketiedot header osoitteiden väärentäminen email spoofing sisältöosa body sähköpostin käyttäjäohjelma mail user agent (MUA) sähköpostin siirto-ohjelma mail transfer agent (MTA) sähköpostin toimitusohjelma mail delivery agent (MDA) tapaustunniste instance tag sähköpostiosoitteiden kohdentaminen email appending täytäntöönpanosääntö enforcement rule valitsin selector vastaavuus alignment vastaavuustila alignment mode yhdyskäytävä gateway

3 Sähköpostin toiminta

Sähköpostin toiminta koostuu useasta osasta, ja sen infrastruktuuria kuvataan usein kolmella tai useammalla komponentilla (IETF 2009). Tässä opinnäytetyössä tarkastellaan sähköpostia pelkistetysti kuvan 1 esittämien kolmen komponentin näkökulmasta, joita ovat sähköpostin käyttäjäohjelma (MUA), sähköpostin siirto-ohjelma (MTA) ja sähköpostin toimitusohjelma (MDA).

+------+ +------+ +------+ +------+ +------+ | |SMTP| |SMTP| |SMTP| |IMAP| | | |--->| MTA |--->| |--->| MDA |<-->| | | | | | | | | | | | | MUA | +------+ | MTA | +------+ | MUA | | | | | | | | | | | | |<-->| MDA |<---| |<---| MTA |<---| | | |IMAP| |SMTP| |SMTP| |SMTP| | +------+ +------+ +------+ +------+ +------+

Kuva 1. Sähköposti-infrastruktuurin komponentit ja sähköpostiviestien kulku yleisesti käy- tetyillä protokollilla (mukaillen IETF 2009)

Kuvassa 1 on esitetty sähköpostiviestien kulku kahden käyttäjän välillä. Sähköpostiviestit lähetetään käyttäjän toimesta sähköpostin käyttäjäohjelmasta. Sähköpostin siirto-ohjelmalla konfiguroitu sähköpostipalvelin vastaanottaa viestin ja välittää sen edelleen lopullisen vastaanottajan palvelimelle. Viestien lähetyksessä käytetään SMTP-protokollaa. Ku- van 1 esimerkissä viesti kulkee välillisen sähköpostipalvelimen kautta ennen päätymistään lopullisen vastaanottajapalvelimen sähköpostin toimitusohjelmalle. Vastaanottajan käyttä- jäohjelma noutaa sitten saapuneet viestit toimitusohjelmalta IMAP-protokollalla. Vastaan- ottaja vastaa viestiin, jolloin viestin matkalla käytettyjen protokollien ja komponenttien jär- jestys on käänteinen alkuperäiseen verrattuna. Komponenttien ja protokollien tarkemmat roolit kuvataan opinnäytetyön luvuissa 3.2-3.4.

3.1 Sähköpostiviestin rakenne

Sähköpostiviesti on jaettavissa kolmeen osaan: viestin kirjekuoreen, jolla ohjataan viestin käsittelyä SMTP-liikenteessä, viestin otsaketietoihin, jotka sisältävät kaiken oleellisen tiedon viestin toimittamiseksi, ja sisältöosaan, joka sisältää viestin sisällön, kuten tekstin ja kuvat. (IETF 2008a, 4-9.)

3.1.1 Kirjekuori

Tietoa, jota käytetään sähköpostiliikenteessä protokollatasolla, kutsutaan sähköpostivies- tin kirjekuoreksi. Kirjekuori sisällytetään viestiin SMTP-protokollassa, josta kerrotaan laajemmin opinnäytetyön tietoperustan luvussa 3.3 ja se ohjaa viestin käsittelyaktiviteetteja SMTP-asiakasohjelman ja SMTP-palvelimen välisessä lähetyskanavassa (IETF 2009, 25). Se koostuu viestin lähettäjän osoitteesta, johon virheraportit tulisi lähettää virhetilan- teissa, yhden tai useamman vastaanottajan sähköpostiosoitteista ja vaihtoehtoisista protokollan laajennusmateriaaleista. (IETF 2008b, 11-12.)

3.1.2 Otsaketiedot

Sähköpostiviestin otsaketiedot ovat hyödyllisiä selvitettäessä mahdollisia ongelmia sähkö- postiliikenteessä. Ne sisältävät viestin reitittämiseen liittyviä tietokenttiä, joista vain osa on suoraan näkyvissä loppukäyttäjälle sähköpostiohjelmassa. Viestin otsaketiedot ovat silti luettavissa riippuen käytetystä sähköpostiohjelmasta.

Kuva 2. Viestin otsaketietojen tarkastelu Outlook-sähköpostiohjelmassa

Kuvassa 2 otsaketiedoista nähdään muun muassa viestin otsikko sekä lähettäjän ja vastaanottajan osoitteet, jotka ovat normaalisti näkyvissä loppukäyttäjälle helposti. Lisäksi ne sisältävät muita tietoja, joita loppukäyttäjät eivät tyypillisesti näe. Esimerkiksi opinnäyte- työssä käsitellyt roskapostin torjuntatekniikat usein merkitsevät testiensä tulokset viestin otsaketietoihin, jolloin niistä voidaan selvittää, miksi sähköposti päätyi roskapostikansioon. On huomioitava, että kaikki tiedot ovat väärennettävissä organisaation omien sähköposti- palvelimien luomia ”Received”-kenttiä lukuun ottamatta (Media Temple 2019). Erilaisia otsaketietoja on useita, ja tässä luvussa kuvataan niistä yleisimmät.

From: Viestin lähettäjäkenttä. Yksilöi viestin lähettäjän sähköpostiosoitteen. Jos osoitteita on useampi kuin yksi, otsaketietoihin lisätään myös ”Sender”- kenttä. (IETF 2008a, 22.)

Sender: Yksilöi sen lähettäjän sähköpostiosoitteen, josta viesti lopulta lähe- tettiin. Sisällytetään otsaketietoihin ainoastaan, jos ”From”-kentässä on useampi kuin yksi sähköpostiosoite. Tämä ei kuitenkaan ole tyypillistä ja voi jossain tapauksissa viitata mahdolliseen roskapostitukseen. (IETF, 2008a, 22.)

Reply-to: Kenttä, jossa määritellään, mihin sähköpostiosoitteeseen viestin alkuperäinen kirjoittaja haluaa vastaukset. Kun ”Reply-to”-kenttää ei ole otsaketiedoissa, vastauksien pitäisi oletuksena mennä ”From”-kentässä määri- tettyyn sähköpostiosoitteeseen tai -osoitteisiin. (IETF 2008a, 22-23.)

Return-Path: Kenttä, joka lisätään SMTP-palvelimella viestin viimeisessä lä- hetysvaiheessa. Se määrittää sen sähköpostiosoitteen, johon lähetetään pa- lautusviestit viesteistä, joita ei voitu syystä tai toisesta toimittaa. Tästä syystä ”Return-Path”-kenttä tulee olla otsaketiedoissa vain kerran. ”Return-Path”- kentän määrittämä sähköpostiosoite vastaa SMTP-protokollan ”MAIL FROM”-osoitteen kanssa, josta kerrotaan tarkemmin opinnäytetyön luvussa 3.3. (IETF 2008b, 57-59.)

Date: Kenttä, joka kertoo päivämäärän ja kellonajan, jolloin viesti lähetettiin lähettäjän sähköpostiohjelmasta. Pitää sisällään myös lähettäjän aika- vyöhykkeen. Esimerkiksi: ”Date: Sun, 14 Apr 2019 17:14:21 +0300”, jossa ”+0300” viittaa UTC+03:00 -aikavyöhykkeeseen. (IETF 2008a, 14-16.)

To: Kenttä, joka määrittää viestin vastaanottajan tai vastaanottajien sähkö- postiosoitteet eroteltuna puolipisteillä (IETF 2008a, 23-24).

Cc: Kopiokenttä, johon sisällytetään muut vastaanottajaosoitteet, joille viesti on lähetetty mutta joille viestin sisältöä ei ole suoranaisesti kohdistettu (IETF 2008a, 23-24).

Bcc: Piilokopiokenttä, jota ei lopulta sisällytetä otsaketietoihin, kun se saapuu vastaanottajan asiakasohjelmaan. Viestin vastaanottajat eivät näe ken- tän muita vastaanottajaosoitteita. (IETF 2008a, 23-24.)

Message-ID: Tunniste, joka yksilöi sähköpostin ja sen version muista vies- teistä. Tunnisteen yksilöllisyys generoidaan ja taataan sen käyttäjäohjelman toimesta, joka viestin tuotti. Sama tunniste säilyy vain yhden viestiversion

7 ajan, ja jokaiselle uudelle versiolle luodaan uusi yksilöivä tunniste. (IETF 2008a, 25.)

Subject: Viestin otsikko, joka kuvaa lyhyesti viestin aiheen (IETF 2008a, 27- 28).

Received: Kenttä, johon on merkitty, mikä SMTP-palvelin on vastaanottanut viestin ja miltä palvelimelta. Sisältää myös muita yhteyteen liittyviä tietoja, kuten kuljetuksessa käytetyn salausprotokollan version ja yksilöllisen ID-tunnisteen. Tyypillisesti kenttiä on useita, sillä sähköpostit kulkevat monen palvelimen läpi. Kun SMTP-palvelimet lähettävät viestin eteenpäin, niiden tulee RFC 5321 -standardin mukaisesti merkitä uusi ”Received”-kenttä muutta- matta aiempia kenttiä. Alla olevassa esimerkissä 1 smtp01.example.com - palvelin vastaanotti viestin smtp02.mapy.fi -palvelimelta. (IETF 2008b, 29.)

Received: from smtp02.mapy.fi (52.133.46.154) by smtp01.example.com (52.133.41.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.16; Sun, 14 Apr 2019 18:33:47 +0000

Esimerkki 1. Tyypillinen ”Received”-kenttä sähköpostiviestin otsaketiedoissa

Esimerkin ensimmäiseltä riviltä nähdään viestin lähettäneen palvelimen nimi ja sen yksilöivä IP-osoite. Toinen rivi näyttää viestin vastaanottaneen palvelimen nimen ja sen yksilöivän IP-osoitteen. Kolmas rivi kuvaa palvelinyhtey- den käyttämän salausprotokollan version ja käytetyn salausalgoritmin. Vii- meisellä rivillä näkyy yhteyden ID ja aikaleima, jolloin vastaanottava palvelin sai viestin.

”Received”-kentät ovat tärkeitä vikatilanteiden arvioinnissa. Organisaation oma sähköpostipalvelin on listan ensimmäisenä, joten kentät tulisi lukea al- haalta ylöspäin seuraten postin alkuperäistä kulkua. (Media Temple 2019.)

X-kentät: Muut virallisesti määrittelemättömät otsakkeet merkitään alkavaksi ”X”-merkinnällä. X-kentät sisältävät merkintöjä ja tunnisteita kaikilta sähkö- postipalvelimilta ja -päätteiltä, joiden läpi posti on kulkenut. Esimerkiksi tiedot roskapostisuodatuksen tuloksista merkataan usein X-kenttään. (Return Path 2019a.)

Lisäksi on muita vähemmän yleisiä tai tärkeitä otsaketietoja, jotka on kuvattu tarkemmin kansainvälisen internet-standardeja kehittävän IETF-organisaation standardeissa RFC 5322 ja -5321 (IETF 2008a; IETF 2008b). Sellaiset otsaketiedot ovat monesti käytetyistä palvelinohjelmistoista riippuvia, eikä niitä siten käsitellä tässä opinnäytetyössä.

3.1.3 Sisältöosa

Sähköpostin sisältöosa sisältää viestin sisällön, kuten tekstin. Alun perin runko koostui ainoastaan riveistä US-ASCII merkintöjä, mutta uudemmat standardit mahdollistivat moni- puolisimmat merkit, kuten UTF-8 merkistöstandardin (IETF 2008a, 9). Myöhemmin määri- teltiin MIME, joka salli sähköpostien välittämisen erilaisia merkistöjä käyttäen (IETF 1997, 1-3). MIME:n myötä viesteihin on pystytty sisällyttämään myös liitteitä ja erilaisia mediatiedostoja, kuten kuvia (IETF 1996a, 3).

3.2 Sähköpostin käyttäjäohjelma

Sähköpostin käyttäjäohjelmat ovat sähköpostin lähteitä ja kohteita (IETF 2009, 29-30). Käyttäjäohjelma on käyttöliittymä, jonka kautta loppukäyttäjät lukevat ja kirjoittavat sähkö- postiviestejä (GitLab 2018). Yleisesti puhutaan sähköpostiohjelmasta, kuten Outlookista tai Mozilla Thunderbirdistä. Käyttäjäohjelma välittää viestin sähköpostin siirto-ohjelmalle, kun käyttäjä lähettää sen sähköpostiohjelmastaan (IETF 2008b, 12). Sähköpostin käyttä- jäohjelman ollessa vastaanottajana se noutaa sille osoitetut sähköpostiviestit sähköpostin toimitusohjelmalta, josta kerrotaan tarkemmin opinnäytetyön luvussa 3.4 (IETF 2009, 33- 34).

3.3 Sähköpostin siirto-ohjelma ja SMTP-protokolla

Sähköpostin siirto-ohjelma välittää sähköpostiviestejä reitittämällä niitä yhdeltä palvelimelta toiselle, kunnes ne päätyvät vastaanottajan sähköpostipalvelimen toimitusohjelmalle. Se on verrattavissa reitittimeen IP-verkoissa, sillä sen tarkoituksena on arvioida op- timaalinen reititys seuraavalle komponentille. Täysin vertauskelpoisia ne eivät kuitenkaan ole, sillä sähköpostin siirto-ohjelmalla varustetut palvelimet säilyttävät niiden kautta kulke- neet viestit mahdollistaakseen viestien palauttamisen palvelun vikatilanteiden aikana. (IETF 2009, 32-33.)

Reititys perustuu pääasiassa nimipalvelun MX-tietueisiin, jotka määrittelevät, minkä säh- köpostin siirto-ohjelmalla varustellun palvelimen kautta saavutetaan tietty toimialue (IETF 2009, 33). Tietueille annetaan prioriteetti, jonka perusteella sähköpostit reititetään palvelimelle, jolle on annettu MX-tietueessa prioriteetiksi alin arvo (DreamHost 2019). Esimerkin

2 mukaisesti lihavoitu palvelin ”smtp01.mapy.fi” vastaa ensisijaisesti mapy.fi -toimialueelle osoitettujen sähköpostiviestien vastaanottamisesta, koska sillä on suurempi prioriteetti alemman arvon ”0” vuoksi.

Domain TTL Class Type Priority Host mapy.fi. 3600 IN MX 0 smtp01.mapy.fi mapy.fi. 3600 IN MX 10 smtp02.mapy.fi

Esimerkki 2. Reititys MX-tietueiden prioriteettiarvojen perusteella

Sähköpostin siirto-ohjelmiin sisältyy sekä asiakasohjelman että palvelimen toiminnalli- suuksia. Ne eivät muuta viestin kirjekuoren sähköpostiosoitteita tai muotoile uudelleen sähköpostin sisältöosaa. Datatyyppien muuttaminen kuuluu siirto-ohjelmien toimintaan, mutta sisältöosan muokkaaminen ei. Sähköpostin siirto-ohjelmat lisäävät viestin otsaketietoihin ”Return-Path”- ja ”Received”-rivejä varmistaakseen sähköpostin jäljityksen alkupe- räiselle lähettäjälle. (IETF 2009, 32-33.)

Siirto-ohjelmien palvelimien välinen yhteys perustuu SMTP-protokollaan, joka pystyy siir- tämään sähköpostia useiden verkkojen ylitse ja niiden välillä. SMTP-asiakasohjelma aloittaa yhteyden SMTP-palvelimen välille luomalla kaksisuuntaisen lähetyskanavan. Sen vastuulla on siirtää sähköpostiviestit SMTP-palvelimille sekä tarvittaessa raportoida vikatilan- teesta, jossa viestejä ei kyetty lähettämään (IETF 2008b, 7). Luotettavuuden takaamiseksi SMTP-protokolla kykenee lähettämään sähköpostin tarvittaessa uudelleen väliaikaisen siirtovirheen jälkeen. (IETF 2009, 32-33.)

SMTP-asiakasohjelma löytää sopivan SMTP-palvelimen IP-osoitteen jäljittämällä viestin vastaanottajan toimialuenimen joko välissä olevaan sähköpostipalvelimeen tai viestin lopulliseen kohteeseen. Jos kyseinen SMTP-palvelin on sähköpostin lopullinen kohde, se ottaa SMTP-asiakasohjelman roolin vastaanotettuaan viestin. Jos taas kyseessä on vain välissä olevan palvelin, se toimii yhdyskäytävänä ja välittää viestin eteenpäin. (IETF 2008b, 7-9.)

SMTP-yhteys muodostuu sarjasta komentoja ja vastauksia kuvan 3 esittämällä tavalla. SMTP-komennot generoidaan SMTP-asiakasohjelmalla ja lähetetään SMTP-palvelimelle. Vastaukset kyseisiin komentoihin lähetetään taas palvelimelta asiakasohjelmalle. Sähkö- postin kuljettaminen voi tapahtua joko yksittäisellä yhteydellä lähettäjän ja vastaanottajan

10 välillä tai useamman välissä olevan palvelimen kautta. Yhteys alkaa kättelyllä, jonka jäl- keen palvelin antaa vastauksen, jossa se ilmaisee kykynsä vastaanottaa tai olla vastaan- ottamatta sähköpostiviestiä. (IETF 2008b, 7-9.)

Kun lähetyskanava on luotu ja yhteyden kättelyvaihe SMTP-asiakasohjelman ja SMTP- palvelimen välillä on käyty, asiakasohjelma lähettää palvelimelle HELO- tai EHLO-komennon, jolla se todistaa identiteettinsä (kuva 3, vaihe 1). EHLO on uudempi ja alun perin RFC 2821 -standardissa esitetty komento laajennettuun SMTP-protokollaan. Oletuksena SMTP-palvelimet lähettävät ensin EHLO-komennon, mutta niiden tulee kyetä hyväksyä myös vanhempi HELO-komento. (IETF 2001, 29-30.)

SMTP-palvelimen vastattua EHLO-viestiin (kuva 3, vaihe 2) asiakasohjelma aloittaa säh- köpostiviestin siirron. Siirtovaiheeseen kuuluu useita SMTP-komentoja, jotka määrittelevät viestin lähettäjän ”MAIL FROM”-osoitteen, vastaanottajan ”RCPT TO”-osoitteen, otsaketiedot ja muun sisältöosan (kuva 3, vaiheet 3, 5, 7 ja 9). SMTP-palvelin vastaa kuhunkin komentoon ja hyväksyy viestin (kuva 3, vaiheet 4, 6, 8, 10). Siirrettyään viestin SMTP- asiakasohjelma joko ehdottaa yhteyden katkaisemista ”QUIT”-komennolla (kuva 3, vaihe 11) tai aloittaa toisten sähköpostiviestien lähetyksen. (IETF 2008b, 18-30.)

Kuva 3. SMTP-yhteyden komennot ja vastaukset (mukaillen AfterNerd 2019)

Sähköpostin siirtovaiheessa käytettyjä ”MAIL FROM”- ja ”RCPT TO”-komentoja ei tule se- koittaa viestin otsaketietojen ”From”- ja ”To”-kenttiin. SMTP-yhteyden ”MAIL FROM”-komento kertoo lähettäjän sähköpostiosoitteen, mutta se voi poiketa ”From”-kentästä, joka esitetään loppukäyttäjän sähköpostiohjelmassa. Molempien tiedot ovat väärennettävissä, joten lähettäjän aitous on kyseenalaistettava (Xeams 2017). Roskapostittajat käyttävät usein väärennettyä ”MAIL FROM”-komentoa läpäistäkseen alkeellisimmat todentamistar- kistukset ja väärentävät ”From”-kentän, jolloin loppukäyttäjä luulee saaneensa sähköposti- viestin luotettavalta lähettäjältä (IETF 1999a, 13).

3.4 Sähköpostin toimitusohjelma

Sähköpostit päätyvät lopulta siirto-ohjelmalta sähköpostin toimitusohjelmalle SMTP-protokollalla. Sähköpostin toimitusohjelma vastaa sähköpostiviestien toimittamisesta loppukäyt- täjän sähköpostitilin postilaatikkoon (IETF 2009, 33-34). Toimitusohjelma vastaa myös sähköpostiviestien luokittelusta kansioihin sekä roskapostisuodatuksesta tietyissä palve- linkonfiguraatioissa. (GitLab 2018.)

Sähköpostiviestin siirto toimitusohjelmalta sähköpostin käyttäjäohjelmalle tapahtuu esimerkiksi POP3- tai IMAP-protokollalla (IETF 2009, 33-34). Lisäksi on muita protokollia, joita käytetään pääasiassa Microsoftin sähköpostipalveluissa.

3.4.1 POP3

POP3 on protokolla, jota sähköpostin käyttäjäohjelmat käyttävät loppukäyttäjälle osoitettujen sähköpostiviestien noutamiseksi toimitusohjelman sisältävältä sähköpostipalvelimelta. POP3-protokollaa ei ole tarkoitettu IMAP-protokollan kaltaiseksi laajaksi ja dynaamiseksi protokollaksi. Tyypillisesti sähköpostiviestit poistetaan sähköpostipalvelimelta heti, kun käyttäjä on noutanut ne sieltä paikalliselle tietokoneelleen käyttämällä POP3-protokollaa. Viestejä ei siis säilytetä sähköpostipalvelimella, eivätkä ne ole luettavissa muilta laitteilta lukuun ottamatta sitä, jolle ne on ladattu (Office 2019a). (IETF 1996b, 2.)

POP3 ei tue IMAP-protokollan tavoin uusien saapuneiden sähköpostiviestien lataamista jo olemassa olevan yhteyden kautta taikka useampia kansioita sähköpostipalvelimella (IETF 1996b, 16-17).

3.4.2 IMAP

IMAP-protokollaa käytetään POP3:n tavoin, eli käyttäjälle osoitettujen viestien noutamiseksi sähköpostin toimitusohjelmalta. IMAP mahdollistaa sähköpostiviestien lukemisen miltä tahansa laitteelta. Viestejä ei tallenneta ainoastaan paikalliselle tietokoneelle vaan ensisijaisesti sähköpostipalvelimelle (Office 2019a). Sähköpostiviesteistä ladataan myös kopiot paikalliseen välimuistiin, jolloin ne ovat saatavissa silloin, kun yhteys sähköpostipal- velimelle on poikki. IMAP-protokollaa käytettäessä viestit voidaan poistaa palvelimelta sähköpostiohjelman kautta. IMAP mahdollistaa myös postilaatikkojen uudelleennimeämi- sen, viestien luokittelun sekä viestien ja niiden sisällön etsimisen hakutoimintoa käyttäen. Jos sähköpostin käyttäjäohjelman ja toimitusohjelman välinen yhteys katkeaa, uudet saapuneet viestit synkronoidaan automaattisesti sähköpostiohjelmaan, kun yhteys komponenttien välillä muodostetaan uudelleen. (IETF 2003, 1.)

3.4.3 MAPI ja EAS

MAPI on protokolla, jota käytetään Microsoftin Exchange-palvelimen ja siihen perustuvien palveluiden, kuten Office 365:n, kanssa. MAPI:n ensimmäinen versio mahdollisti Win- dows-pohjaisilla tietokoneilla suoritettavien sähköpostiohjelmien kommunikoinnin Win- dows-pohjaisten sähköpostipalvelimien välillä ainoastaan saman lähiverkon sisällä. Sit- temmin protokolla on päivitetty toimimaan HTTP-protokollan yli (GSX 2019). Käyttäjän sähköpostiviestit säilytetään IMAP-protokollan tavoin sähköpostipalvelimella, ja viestien paikalliset kopiot säilyvät käyttäjän tietokoneella. MAPI mahdollistaa sähköpostiviestien ohella muun muassa kalenterien ja kontaktien synkronoinnin sähköpostin toimitusohjelman ja käyttäjäohjelman välillä. (Jain 2017.)

EAS on sähköpostiohjelman ja -palvelimen väliseen synkronointiin kehitetty protokolla. EAS on suunnattu mobiililaitteiden Outlook-sähköpostiohjelman kanssa käytettäväksi (Microsoft 2019b). Molemmat protokollat ovat siis ensisijaisesti Microsoftin Exchange-, Of- fice 365- ja Outlook-tuotteiden ja -palveluiden käyttämiä protokollia, jotka käyttäytyvät IMAP-protokollan tavoin vastaavassa käyttötarkoituksessa.

4 Roskaposti

Roskapostia on kaikki sellaiset sähköpostiviestit, jotka eivät ole vastaanottavan organisaation toivomaa. IETF-organisaatio katsoi roskapostin vakavaksi uhaksi internetille jo vuonna 1999 RFC 2505 -standardissa, jossa esitettiin yleisiä roskapostin torjuntasuosituk- sia SMTP-protokollaa käyttäville sähköpostin siirto-ohjelmille. (IETF 1999a, 2.)

Roskapostin vaikutukset ovat laajoja, sillä ne vaikuttavat lopullisen vastaanottajan ohella myös internetpalveluntarjoajaan. Vastaanottajat saavat suuria määriä sähköpostia, jolla ei ole sisällöltään mitään tekemistä heidän kanssaan (IETF 1999a, 2). Tyypillinen käyttötar- koitus on markkinointi. Sähköpostien automatisoitu käyttäminen suoramarkkinointiin ilman vastaanottajan hyväksyntää on kielletty Suomessa sähköisen viestinnän tietosuojalailla (Finlex 516/2004, 26 §). Useat roskapostit ovat myös sisällöltään haitallisia levittäen haittaohjelmia tai pyrkien kalastelemaan henkilötietoja ja verkkotunnuksia. Roskapostien suodatus kuluttaa vastaanottajan kaistanleveyttä ja sähköpostipalvelimen resursseja. (Chris- tina, Karpagavalli & Suganya 2010.)

Merkittävä ongelma roskapostien torjunnassa on aitojen sähköpostiviestien erotteleminen roskapostista (Christina 2010). Tietyt torjuntatekniikat, kuten bayesilainen suodatus, pyrki- vät erottamaan haitalliset viestit halutusta sähköpostiliikenteestä koneoppimista hyödyn- täen. Uusista tehokkaista torjuntamenetelmistä huolimatta aitoja sähköpostiviestejä luokitellaan organisaatioiden sähköpostijärjestelmien vuoksi roskapostiksi kohtuullisen sään- nöllisesti. Syitä voivat olla tietyt samanlaisuudet aiempien roskapostiviestien kanssa tai vaikka päivittämätön SPF-tietue lähettäjän osalta. Näistä syistä monet palveluntarjoajat, kuten Microsoft, antavat käyttäjille mahdollisuuden raportoida väärät positiiviset tarkistus- tulokset roskapostisuodattimien tarkkuuksien parantamiseksi (Microsoft 2019c).

Suomalainen sähköpostiturvayhtiö D-Fence arvioi roskapostin määräksi noin 70 % asiak- kaidensa sähköpostiliikenteestä vuonna 2019 (Oravala 29.5.2019). Tietoturvayhtiö Kas- perskyn mukaan roskapostin osuus käyttäjiensä sähköpostiliikenteestä oli taas noin 52 % vuonna 2018. Merkittävin roskapostin mukana levitetty haittaohjelma oli tuolloin Microsoft Office -tuoteperheeseen kohdistuvaa CVE-2017-11882 -haavoittuvuutta hyödyntävä haittaohjelma (Kaspersky 2019a). Ohjelma latasi tietokoneen taustalla etäkäytön mahdollista- van troijalaisen, jolla hyökkääjä sai tietokoneen haltuunsa käyttäjän tietämättä (Zscaler 2017). IT-alan yrityksiin kohdistuvan tietojenkalastelun osuus oli prosentin luokkaa koko roskapostiliikenteestä, ja suomalaisiin yksityishenkilöihin kohdistuva roskaposti vaikutti noin kahdeksaan prosenttiin Kasperskyn palveluita käyttävistä suomalaisista. (Kaspersky 2019a.)

4.1 Sisäänpäin suuntautuva roskaposti

Kaikki yrityksen toimialueelle suuntautuva ei-toivottu sähköposti on sisäänpäin suuntautuvaa roskapostia. Tällöin roskapostin kohteena ovat yrityksen työntekijät, eli sähköposti- viestin kirjekuoren ”RCPT TO” määrittelemät vastaanottajaosoitteet päättyvät organisaation toimialuenimeen tai johonkin organisaation omistamaan verkkotunnukseen.

Erilaisia roskapostin torjuntakeinoja kohdistetaan ensisijaisesti sisäänpäin suuntautuvaan roskapostiin. Yritykselle kohdistetut sähköpostit, jotka saapuvat yrityksen sähköpostipalve- limelle, tarkistetaan ja suodatetaan. Sisäänpäin suuntautuvan roskapostin suurimmat ongelmat ovat niiden käsittelemiseen kulutettu aika, haitallinen sisältö ja yrityksen sähköpos- tipalvelimien resurssien tuhlaaminen. (Christina 2010.)

4.2 Ulospäin suuntautuva roskaposti

Ulospäin suuntautuvaa roskapostia on kaikki sellainen ei-toivottu sähköpostiliikenne, joka lähetetään yrityksen toimialueen sisältä sen sähköpostipalvelimen kautta julkiseen verk- koon. Tässä opinnäytetyössä ulospäin suuntautuvaksi roskapostiksi katsotaan myös säh- köpostiviestit, jotka on lähetetty muille vastaanottajille tietyn yrityksen toimialuenimeä käyttäen muttei kyseisen yrityksen itsensä toimesta. Tällöin puhutaan sähköpostiosoittei- den väärentämisestä, joka on tunnettu ongelma nykyisessä sähköposti-infrastruktuurissa (IETF 2014, 5).

Vaikka ulospäin suuntautuvalle sähköpostiliikenteelle ei tehdä tyypillisesti yhtä mittavia tarkistuksia kuin sisäänpäin suuntautuvalle liikenteelle, on ulospäin suuntautuva roskaposti silti haitallista. Se on vaarallista erityisesti yrityksen maineen kannalta. Roskapostit- tajat voivat lähettää haitallisia viestejä yrityksen toimialuenimeä käyttäen tai toimialuever- kon sisältä haavoittuvien tietokoneiden tai käyttäjätilien kautta. Toiminta johtaa yrityksen maineen pilaantumiseen, vaikkei se olisikaan yrityksen tarkoituksenmukaista toimintaa (Schryen 2007, 19). Yrityksen toimialuenimen käyttäminen lisää myös riskiä sille, että yritys joutuu tunnetuille DNS-pohjaisille mustalistoille. Mustalistoilta irtautuminen voi olla erit- täin vaikeaa IETF:n suosituksista huolimatta (IETF 2012, 11).

4.3 Roskapostityypit ja roskapostitusmenetelmät

Roskapostittajilla on hyvin erilaisia motiiveja, mutta yksi yleisimmistä syistä roskapostitukseen on mainonta ja suoramarkkinointi. Vaikeimmin torjuttavaa roskapostia on tällä het- kellä D-Fencen mukaan mainsleaze-roskaposti (Oravala 29.5.2019). Termillä viitataan täysin asianmukaisten ja virallisten yritysten lähettämään markkinointisähköpostiin, jonka

15 alkuperää ei yritetä peitellä. Sellaista roskapostia on vaikea torjua, sillä sen osuus kyseisten virallisten yritysten lähettämästä sähköpostista on kohtuullisen pientä, minkä vuoksi yritysten palvelimia harvemmin laitetaan esimerkiksi DNS-pohjaisille mustalistoille. Torju- minen on siten hankalaa ilman, että myös aitoja sähköpostiviestejä merkitään virheellisesti roskapostiksi. Yritykset myös pyrkivät vahvasti todistamaan, että käyttäjät ovat antaneet suostumuksensa suoramarkkinoinnille. (MainSleaze 2013.)

Sähköpostiosoitteiden kohdentaminen viittaa taas käytäntöön, jossa väärinkäytetään yksi- tyishenkilöiden henkilötietoja suoramarkkinoinnin kohdistamiseksi sähköpostiosoittee- seen, jonka uskotaan olevan jonkun tietyn henkilön hallussa. Henkilö ei ole itse antanut sähköpostiosoitettaan markkinoijille. Käytäntö rikkoo Euroopan Unionin GDPR-tietosuoja- asetusta, sillä käyttäjä ei ole antanut suostumustaan, eikä sitä ole kysytty. (MAAWG 2019.)

Uudenaikaset roskapostinsuodattimet pystyvät tunnistamaan ja estämään roskaposteja niiden sisällön perusteella. Tästä syystä roskapostittajat ovat myös sisällyttäneet roskapostiviestien sisällön kuviin, mikä tekee sähköpostin sisältöosan tarkistuksesta hyödytöntä (Fumera, Pillai & Roli. 2006, 1). Tällaisen kuvapohjaisen roskapostituksen takia työkalui- hin, kuten SpamAssassin-roskapostisuodattimeen, on sittemmin kehitetty lisäosia, jotka pyrkivät analysoimaan kuvien sisällön (Wiki Apache 2009).

Backscatter on roskapostia, jota syntyy erilaisten automaattisten vastausten ja palautus- viestien myötä, joita sähköpostipalvelimet lähettävät (Bhowmick & Hazarika 2016, 5). Tyy- pillisiä vastauksia ovat tilausvahvistukset sekä DNR- ja DSN-viestit, jotka ilmoittavat viestin lähettäjää sähköpostin toimituksessa tapahtuneesta virheestä, sekä automaattiset poissaolovastaukset (IETF 2004, 2-3). Backscatter-roskapostittajat väärentävät sähköpos- tiviestin kirjekuoren ”MAIL FROM”-kentän, jolloin viestin vastaanottavat sähköpostipalveli- met lähettävät esimerkiksi DSN-viestit kentässä määriteltyyn osoitteeseen. Osoite ei kuitenkaan kuulu roskapostittajalle vaan asiasta täysin tietämättömälle kolmannelle taholle. Tämän tyylistä roskapostia on vaikea torjua, koska se perustuu aitoihin palautusviesteihin. (Bhowmick & Hazarika 2016, 5.)

Sähköpostipalvelimien ylläpitäjien tulisikin välttää turhia palautusviestejä. Jos roskapostittajat käyttävät oikean yrityksen sähköpostipalvelimia backscatterin tuottamiseen, se voi johtaa toimialuenimen joutumiselle mustalistalle (Bhowmick & Hazarika 2016, 5). IETF:n suosituksia automaattisten vastausten konfiguroinnista turvallisesti löytyy RFC 3834 -stan- dardista (IETF 2004).

SMTP on vanha protokolla, jonka kehittämisen aikana ei huomioitu roskapostitusta, mikä on mahdollistanut lukuisia tietoturvaongelmia. Sähköposti-infrastruktuurin yksi suurim- mista ongelmista on, että sähköpostiosoitteiden väärentäminen toisen yrityksen toimialuenimen käyttämistä varten on hyvin yksinkertaista ja mahdollistaa monenlaisia hyökkäyksiä (IETF 2014, 5).

Tyypillisiä hyökkäyksiä ovat backscatterin ohella erilaiset tietojenkalasteluyritykset, joissa hyödynnetään sosiaalista manipulointia (Bhowmick & Hazarika 2016, 7). Viranomaiset ovat julkaisseet paljon varoituksia esimerkiksi Office 365 -palveluun kohdistuvista tietojen- kalasteluyrityksistä (Kyberturvallisuuskeskus 2018). Hyökkääjä voi muun muassa esiintyä saman yrityksen toimitusjohtajana ja pyytää talousjohtajaa maksamaan olemattomia las- kuja. Tällöin puhutaan kohdennetusta verkkourkinnasta, joka kohdistetaan tiettyyn yritykseen ja monesti vielä tiettyyn yrityksen työntekijään. Alalle on jo vakiintunut termi toimitusjohtajahuijaus, jolla viitataan juuri kyseiseen ilmiöön (Viestintävirasto 2016). Suomalainen sähköpostiturvayhtiö D-Fence arvioi jatkuvasti paranevat toimitusjohtajahuijaukset tämän hetken ajankohtaisimmaksi ja suurimmaksi uhaksi (Oravala 29.5.2019).

Hyökkääjien motivaationa voivat olla taloudelliset edut tai haittaohjelman levittäminen tie- tojenkeruuta varten (Kaspersky 2019b). Monet muut tietojenkalasteluyritykset pyrkivät usein ohjaamaan käyttäjän roskapostissa osoitettuun verkko-osoitteeseen, joka on naami- oitu muistuttamaan jonkin oikean palvelun verkkosivustoa. Tarkoituksena on saada käyt- täjä kirjautumaan sivustolle käyttäjätunnusten ja salasanojen kalastelua varten. (Kurittu 2019.)

Joskus hyökkäyksen tarkoituksena voi olla vain huonon maineen tuottaminen tietylle yritykselle. Niin kutsutuissa joe job -hyökkäyksissä on kyse siitä, että hyökkääjä lähettää roskapostia toisen yrityksen nimissä tarkoituksenaan aiheuttaa huonoa mainetta ja mahdollisesti taloudellisia tappioita. Hyökkäys perustuu lähettäjän sähköpostiosoitteen väärentä- miseen, jolloin roskapostin vastaanottaja luulee viestin tulleen hyökkäyksen kohteena ole- valta yritykseltä. (Schryen 2007, 19.)

Joe job- ja muiden sähköpostiosoitteiden väärentämiseen perustuvien hyökkäyksien vuoksi on kehitetty useita tekniikoita, joiden tarkoituksena on auttaa vastaanottajia todentamaan viestin lähettäjän aitous. Näitä tekniikoita käsitellään opinnäytetyön luvussa 6.

5 Roskapostintorjunta sisällön tai lähteen perusteella

Tässä luvussa käsitellään erilaisia tekniikoita ja käytäntöjä, joilla voidaan torjua roskapostia niiden lähteen tai sisällön perusteella. Tarkoituksena on kyetä tunnistamaan sähköpos- tiviestin mahdollisesti haitallinen lähettäjä tai sisältö ennen viestin toimittamista loppukäyt- täjän postilaatikkoon. Haitallista sisältöä ovat esimerkiksi haittaohjelmat ja mainosten kal- taiset roskapostiviestit, jotka eivät ole organisaatiossa toivottua. Eri tekniikoita voidaan käyttää sellaisinaan, tai niitä voidaan yhdistää fyysisiin tai pilvipalvelupohjaisiin roskaposti- suodattimiin.

Viestin lähteen perusteella tapahtuva suodatus toteutetaan SMTP-yhteyden aikana. Lä- hettäjä voi olla ennalta tunnettu roskapostittaja, tai sitten vastaanottava palvelin vain yksi- löi sen sellaiseksi lähettävän sähköpostipalvelimen ominaisuuksien perusteella. Suoda- tusta tehdään sekä ulos- että sisäänpäin suuntautuvassa sähköpostiliikenteessä. Saapu- van sähköpostin suodatus suojelee organisaatiota haitalliselta sisällöltä, joka voi kuluttaa organisaation resursseja tarpeettomasti. Lähtevän sähköpostin suodatuksella pyritään taas suojelemaan organisaation mainetta sekä vastaanottajien toimialueita vastaavilta uhilta.

5.1 SMTP-liikenteen suodatus

On järkevää testata lähettäjän toimialuenimen olemassaolo ennen muiden, kuten sisäl- töön perustuvien, tarkistuksien suorittamista. Testaus kannattaa tehdä sekä lähettäjän ”MAIL FROM”-osoitteelle että HELO/EHLO-komennon isäntänimelle. Vastaavat tarkistukset tehdään aina roskapostitorjunnan alkuvaiheissa, jotta roskapostin vastaanottaminen voidaan estää, ennen kuin palvelinresursseja käytetään turhaan vaativimpiin tarkistuksiin.

Tässä opinnäytetyössä käytetään esimerkkeinä tunnetun Postfix-siirto-ohjelman konfigu- raatioparametreja, jotka on kuvattu opinnäytetyön liitteessä 2. Pilvipohjaisissa sähköposti- palveluissa SMTP-liikenteen suodatusta ei tyypillisesti päästä muuttamaan asiakkaan toimesta. Vapaan ohjelmiston Postfix sopii siten parhaiten osoittamaan tekniikan käyttöönot- toa palvelinpäässä.

5.1.1 Sisäänpäin suuntautuvassa liikenteessä

Sähköpostin siirto-ohjelmaksi asennetun palvelimen tulee kyetä hylkäämään sähköpostia tietyiltä lähettäjiltä. SMTP-liikenne voidaan estää esimerkiksi lähettävän palvelimen IP- osoitteen tai sen PTR-tietueen osoittaman isäntänimen perusteella (IETF 1999a). PTR-

18 tietue on vastakohta A-tietueelle, eli siinä tietty IP-osoite osoitetaan sitä vastaavaan isän- tänimeen. Tällöin vastaanottava palvelin voi tehdä käänteisen nimipalvelukyselyn ja selvit- tää lähettävän palvelimen isäntänimen sen IP-osoitteen perusteella. (EmailTalk 2019.)

PTR-tietueita hyödynnetään pääasiassa sähköpostipalvelimilla roskapostin torjunnassa. Roskapostittajien käyttämillä palvelimilla ei tyypillisesti ole oikein konfiguroitua PTR-tietuetta. Toisin kuin A-tietue, PTR-tietue määritellään kyseisen IP-osoitteen omistaman inter- netpalveluntarjoajan päässä. Roskapostittajat eivät siten voi luoda itselleen PTR-tietuetta. (EmailTalk 2019.)

Sähköpostin siirto-ohjelmat tarkistavat, että lähettäjältä löytyvät oikeat nimipalvelutietueet ja että lähettäjän PTR- ja A-tietuet vastaavat toistensa kanssa. Lähettäjän toimialueen nimipalvelusta kannattaa myös yleensä tarkistaa MX-tietue. Postfix-siirto-ohjelmasta löytyy useita konfigurointiparametreja, joilla tarkistuksia voidaan tehdä. Hyödyllisiä tarkistuksia on kuvattu opinnäytetyön liitteessä 2.

Lisäksi SMTP-yhteyden HELO/EHLO-komennoissa esiintyvä IP-osoite tai isäntänimi tulisi tarkistaa. Isäntänimen pitäisi olla FQDN-nimi ja IP-osoitteen tulee olla julkisesta osoiteavaruudesta. Yhteydenotot hylätään, jos ne eivät sisällä HELO/EHLO-komentoa. Muita hyödyllisiä tarkistuksia Postfixissä ovat esimerkiksi vastaanottajaosoitteelle tehtävät tarkistukset, joilla voidaan estää sähköpostin vastaanottaminen osoitteille, joille sähköpostin toi- mittaminen ei lopulta olisikaan mahdollista (liite 2). Tämä voi suojata muun muassa backscatter-viestien tulvalta (Postfix 2019c).

Yksi tapa suojata omaa toimialuetta massapostitukselta on samanaikaisten yhteysmää- rien rajoittaminen. Sähköpostin siirto-ohjelma siis rajoittaa, kuinka monta yhteydenottoa lähettävä sähköpostipalvelin voi tehdä tietyn ajan sisällä. (Postfix 2019d.)

5.1.2 Ulospäin suuntautuvassa liikenteessä

Sähköpostipalvelinta ei tulisi koskaan ylläpitää avoimena välityspalvelimena. Muuten se hyväksyy sähköpostia mistä tahansa lähteestä ja välittää sen eteenpäin, jolloin organisaation oma palvelin hoitaa roskapostituksen haitallisen tahon puolesta. Riskinä on yrityksen maineen pilaantuminen ja toimialuenimen joutuminen DNS-pohjaisille mustalistoille. (IETF 1999a, 8.)

Siirto-ohjelmaksi asennetun palvelimen pitäisi todentaa sähköpostin edelleenvälityksen luvallisuus SMTP-yhteyden ”RCPT TO”-osoitteesta, lähettävän palvelimen FQDN-isän- tänimestä ja sen IP-osoitteesta. HELO/EHLO-komennoissa määriteltyä isäntänimeä tai yhteyden ”MAIL FROM”-osoitetta ei käytetä todennukseen, sillä ne ovat helposti väären- nettävissä. Suosituksena on, että sähköpostipalvelin tarkistaa ensin ”RCPT TO”-osoitteen toimialuenimen. Jos se on yksi organisaation toimialuenimistä, paikallinen osoite, tai kuuluu toimialueeseen, jolle edelleenvälitys on sallittu, niin sähköpostiviestin edelleenvälitys hyväksytään. Toinen vaihtoehto on, että lähettävän palvelimen IP-osoite tai FQDN-isäntä- nimi on todennettu luotettavaksi nimipalvelun kautta. Muissa tapauksissa edelleenvälitys estetään. Esimerkiksi Postfix-siirto-ohjelmassa on parametri, joka estää tuntemattomia tahoja käyttämästä sähköpostipalvelinta avoimena välityspalvelimena. Parametrin toiminta ja esivaatimukset on kuvattu opinnäytetyön liitteessä 2. (IETF 1999a, 9.)

Kaikki käyttäjiltä ulospäin suuntautuva posti pitäisi aina myös todentaa, jotta tiedetään, että se on lähtöisin omalta toimialueelta. Lähtevä sähköposti siis estetään, ellei käyttäjä ole ensin todentanut identiteettiään. Todennus tapahtuu tyypillisesti SMTP-protokollan todennuksen mahdollistavalla SASL-lisäosalla (IETF 2007a). Postfix-palvelinohjelmisto ei itsessään toteuta käyttäjien todennusta, vaan se hyödyntää jo olemassa olevia työkaluja, jotka ovat integroitavissa siihen (Cyrus 2019; Dovecot 2014; Postfix 2019e).

Samanaikaisten yhteysmäärien rajoittaminen soveltuu myös lähtevään liikenteeseen. Tuolloin tarkoituksena on estää toimialueen sisäisten laitteiden luvaton käyttö massaposti- tukseen, sekä toimialuenimen maineen suojeleminen, jotta sitä ei tulkita väärin roskapos- tittajaksi luvanvaraisissakin tilanteissa. Rajoitukset voidaan toteuttaa toimialuetasolla tai käyttäjäkohtaisesti. Suosituin tapa toteutukselle vaikuttaisi olevan lisäosien, kuten PolicyD ja Postfwd, käyttäminen (PolicyD 2019 & Postfwd 2019). Postfixin omasta konfiguraatiosta löytyy silti parametreja, joilla lähtevää liikennettä voidaan rajoittaa (Steam.io 2013). Kysei- set parametrit on kuvattu opinnäytetyön liitteessä 2.

5.2 DNS-pohjainen mustalistaus (DNSBL)

DNS-pohjainen mustalistaus on vanha konsepti, joka perustuu listoihin tunnetuista IP- osoitteista tai toimialuenimistä, joita on käytetty roskapostien lähettämiseen. Sähköposti- palvelimet voivat käyttää listoja suodattaakseen tiettyjen lähettäjien viestit muusta sähkö- postiliikenteestä (DNSBL 2019). Lähettäjän perusteella SMTP-yhteys lähettävään palvelimeen voidaan katkaista kokonaan, tai sitten heidän viesteilleen otetaan käyttöön ennalta määritelty suodatuskäytäntö (BarracudaCentral 2019).

DNSBL voidaan esimerkiksi ottaa käyttöön laajasti käytetyssä Postfix-siirto-ohjelmassa lisäämällä sen main.cf-konfiguraatiotiedostoon rivi ”reject_rbl_client ” parametrin ”smtpd_recipient_restrictions” alle (Postfix 2019a). Lisätty rivi ja käytetty zen.spamhaus.org-mustalista näkyvät alla olevassa esimerkissä 3 lihavoituna. smtpd_recipient_restrictions = ... reject_unauth_destination reject_rbl_client zen.spamhaus.org permit

Esimerkki 3. DNS-pohjaisen mustalistan käyttöönotto Postfix-siirto-ohjelmassa

Sähköpostipalvelimet tarkistavat yleensä DNSBL-listat jokaisessa saapuvassa SMTP-yh- teydessä. Listoja voi olla samalla palvelimella käytössä useampia, jolloin niiden DNS-ky- selyt tehdään konfiguraation määrittelemässä järjestyksessä ylhäältä alaspäin. Jos lähet- täjä löytyy yhdeltäkään listalta, yhteys katkaistaan, eikä viestiä vastaanoteta. Viestille saa- tetaan tietyissä sähköpostipalvelinkonfiguraatioissa antaa pisteytys DNSBL-tarkistusten perusteella, mikä ei välttämättä yksinään nosta pisteytystä tarpeeksi korkealle, jotta viesti hylättäisiin puhtaasti sen perusteella. Tarkistus voidaan tehdä myös vasta viestin vastaanottamisen jälkeen. Tällöin tarkistus tehdään tyypillisesti viestin otsaketietojen ”Received”- kenttien IP-osoitteista. Jälkimmäinen tapa katsotaan yleisesti epäkäytännöllisemmäksi kuin yhteyden katkaiseminen tarvittaessa jo ennen viestin lähetystä. (IETF 2010, 8-9.)

DNS-kysely tapahtuu käytännössä siten, että lähettävän palvelimen IP-osoite muutetaan käänteiseksi. Tällöin esimerkkiosoite 1.2.3.4 muuttuisi muotoon 4.3.2.1. Muunnos tehdään siksi, että roskapostittajien IP-osoitteet säilötään DNSBL-listoihin käänteisenä. Käänteinen osoite liitetään DNSBL-listan nimen kanssa esimerkiksi muotoon ”4.3.2.1.zen.spamhaus.org”. Kyseistä nimeä etsitään sitten nimipalvelusta FQDN-nimenä A-tietueen muodossa. Jokaisella DNSBL-listan osoitteella tulee olla toimiva A-tietue. Vastauksena saadaan nimeä vastaava IP-osoite, joka antaa tiedon siitä, löytyykö etsittävä osoite listalta. Nimi voidaan sitten halutessa tarkistaa myös TXT-tekstitietueesta, joihin listoja ylläpitävät tahot merkitsevät syyn, jonka vuoksi kyseinen lähettäjä on alun perin lisätty listalle. (IETF 2010, 3-4.)

Lähettäjän ”4.3.2.1.zen.spamhaus.org” DNS-tietueet saattaisivat näyttää esimerkiksi tältä:

4.3.2.1.zen.spamhaus.org A 127.0.0.2 4.3.2.1.zen.spamhaus.org TXT "Dynamic Address"

Esimerkki 4. DNS-pohjaisen mustalistan määrittämät DNS-tietueet haetulle osoitteelle

Esimerkissä 4 nimen A-tietue viittaa osoitteeseen 127.0.0.2, joka yleisesti tarkoittaa sitä, että kyseisen lähettäjän osoite on mustalistalla. Kysely voi myös palauttaa toisen osoitteen 127.0.0.0/8-osoiteavaruudesta, kunhan se ei ole 127.0.0.1 eli localhost-osoite. Toi- sella osoitteella voidaan esimerkiksi viitata lähettäjän mustalistaukseen, mikä on ollut seurausta jostain tunnetusta syystä, kuten avoimen välityspalvelimen ylläpitämisestä. (IETF 2010, 3-5.)

DNSBL-listat voivat olla julkisia tai yksityisiä. Aiemmissa esimerkeissä 3 ja 4 käytettiin julkista listaa. Joitain listoja päivitetään manuaalisesti, kun taas toiset ovat täysin automati- soituja. Listat voivat myös poiketa toisistaan merkittävästi, koska listan ylläpitäjä päättää itse, millä perustein tietty lähettäjä lisätään mustalistalle. Näin ollen tietyt listat ovat tiu- kempia kuin toiset. Käyttäjien tulee siten huomioida niiden erot DNSBL-listoja käyttöönot- taessaan, sillä tiukempi lista saattaa herkemmin sisältää myös aitoja lähettäjiä, mikä voi tuottaa ongelmia tavallisen sähköpostin kulussa. Tunnettuja DNSBL-listoja ovat esimerkiksi Barracuda Reputation Block List ja Spamhaus Zen. (DNSBL 2019.)

5.3 Harmaalistaus

Harmaalistaus on tekniikka, joka perustuu roskapostittajien käyttämien ohjelmistojen yksinkertaisuuteen. SMTP-protokollaa käsittelevää RFC 5321 -internetstandardia noudattavat sähköpostipalvelimet kokeilevat sähköpostiviestin lähetystä uudelleen tietyn ajan ku- luttua, jos vastaanottava palvelin ei hyväksy ensimmäistä lähetysyritystä. Harmaalistauk- sessa viesti hylätään ensimmäisen kerran niiltä lähettäjiltä, jotka eivät ole entuudestaan tunnettuja tai joita ei ole havaittu pitkään aikaan. Asiallisia sähköpostiviestejä lähettävien tahojen palvelimet yrittävät lähetystä myöhemmin uudelleen, kun taas roskapostittajien käyttämät RFC 5321 -standardin vastaiset ohjelmistot eivät. (Lundgren 2019.)

Tekniikka käyttää toiminnassaan kolmea eri osoitetietoa, jotka se kerää jokaisen viestiä lähettävän palvelimen yhteydenoton yhteydessä. Kyseiset kolme osoitetta ovat lähettävän sähköpostipalvelimen IP-osoite sekä viestin kirjekuoren ”MAIL FROM”- ja ”RCPT TO”- osoitteet. Jos harmaalistausta hyödyntävä vastaanottava palvelin ei ole havainnut yhtey- denotosta poimittuja kolmea osoitetta aiemmin yhdessä, se hylkää viestin samalta osoite- ryhmältä tietyksi ennalta määritellyksi ajaksi. Hylkäys tapahtuu väliaikaisella virheilmoituk- sella, johon normaalit oikein konfiguroidut sähköpostipalvelimet reagoivat yrittämällä lähe- tystä myöhemmin uudelleen. (Harris 2003.)

Harmaalistausta toteutetaan sähköposti-infrastruktuurin siirto-ohjelman tasolla. Se voidaan ottaa käyttöön esimerkiksi Postfix-palvelinohjelmistossa asentamalla erillinen Post- grey-ohjelma (Schweikert 2019). Postfix voidaan määritellä käyttämään Postgrey-ohjel- maa harmaalistaukseen lisäämällä Postfixin main.cf-konfiguraatiotiedostoon rivi ”check_policy_service ” parametrin ”smtpd_recipient_restrictions” alle. Lisätty rivi näkyy alla olevassa esimerkissä 5 lihavoituna. Postgrey kuuntelee oletuksena 127.0.0.1- localhost-osoitteen tietoliikenneporttia 10023 ja odottaa viisi minuuttia, ennen kuin se sallii uuden yhteydenoton samalta lähettäjältä. (Ubuntu 2017.) smtpd_recipient_restrictions = ... check_policy_service inet:127.0.0.1:10023 permit

Esimerkki 5. Harmaalistausta suorittavan Postgrey-ohjelman sovittaminen Postfix-siirto- ohjelmaan

Harmaalistauksen etuina ovat vähäinen resurssien kulutus vastaanottavan sähköpostipal- velimen päässä ja helppo ylläpidettävyys. Tekniikan näkyvimmäksi ongelmaksi muodostuu sen aiheuttama viive myös tavanomaisten sähköpostiviestien kulussa. Se on myös helposti kierrettävissä, jos roskapostittajat käyttävät edistyneempiä ohjelmistoja. Toisaalta sellaisessa tilanteessa se myös tuottaa enemmän työtä roskapostittajien palvelimilla, mikä voidaan katsoa eduksi, vaikkei se roskapostin toimittamista estäkään. (Harris 2003.)

5.4 Nolisting

Nolisting on käytäntö, jonka toiminta perustuu harmaalistauksen tavoin roskapostia lähet- tävien ohjelmistojen yksinkertaisuuteen. Sen käytännön vaikutukset aitoihin lähettäviin sähköpostipalvelimiin ovat pieniä, ja tekniikan käyttöönotto on hyvin suoraviivaista. Nolis- ting ei kuitenkaan ole yksinään riittävä roskapostin suodattamiseksi, vaan sitä tulisi käyt- tää yhdessä muiden tekniikoiden kanssa. (Nolisting 2019.)

SMTP-protokollaa käsittelevää RFC 5321 -internetstandardia noudattavat sähköpostipal- velimet kokeilevat viestin lähetystä ensisijaisesti sille vastaanottajan toimialueen sähkö- postipalvelimelle, jolla on nimipalvelussa MX-tietueiden suurin prioriteetti. Standardin mukaisesti, jos ensisijainen palvelin ei jostain syystä vastaa, lähettäjän tulee kokeilla muita MX-tietueiden osoittamia palvelimia prioriteettijärjestyksessä suurimmasta pienimpään. (IETF 2008b, 69-71.)

Yksinkertaiset roskapostitukseen käytettävät ohjelmistot eivät historiallisesti ole testanneet kuin vain ensimmäisen MX-tietueen osoittaman palvelimen. Nolisting toimii siten, että organisaatio määrittelee tarkoituksenmukaisesti toimialuenimen ensimmäisen MX-tietueen osoittamaan osoitteeseen, jossa ei ole toimivaa sähköpostipalvelinta kuuntelemassa SMTP-liikennettä (Nolisting 2019).

Alla olevassa esimerkissä 6 lihavoidun palvelimen ”fake.example.net” osoitteessa ei kuvit- teellisesti ole toimivaa sähköpostipalvelinta. Kaikki sähköpostia lähettävät palvelimet kokeilevat silti lähettämistä ensisijaisesti sille sen pienimmän prioriteettiarvon ”0” vuoksi.

Domain TTL Class Type Priority Host example.net. 3600 IN MX 0 fake.example.net example.net. 3600 IN MX 10 mx1.example.net example.net. 3600 IN MX 20 mx2.example.net

Esimerkki 6. Nolisting-tekniikan hyödyntäminen nimipalvelun MX-tietueissa

Asialliset ja standardinmukaiset lähettävät sähköpalvelimet kokeilevat myös muiden MX- tietueiden osoittamat sähköpostipalvelimet, kun taas roskapostitusohjelmat eivät. Näin ainakin periaatteessa, mutta käytännössä ennen nolisting-tekniikan käyttöönottoa olisi suositeltavaa suorittaa omia testejä sen odotetusta tehokkuudesta. Testaus onnistuu esimerkiksi seuraamalla saapuvien yhteydenottojen määrää suurimman ja toiseksi suurimman prioriteetin palvelimilla. Saapuville viesteille tehdään sitten sisällönsuodatusta roskapostin tunnistamiseksi. Jos toissijaisten MX-tietueiden ohittavien palvelimien lähettämät viestit ovat pääasiassa roskapostia, voidaan tekniikan tulkita toimivan. (Nolisting 2019.)

Nolisting on tehokasta ainoastaan silloin, kun roskapostittajat käyttävät hyvin alkeellisia ohjelmistoja. Se on siis helposti ohitettavissa edistyneemmillä ohjelmistoilla. Käytännön tehokkuutta on tieteellisesti mitattuna testattu hyvin vähän. Vuonna 2016 julkaistussa tutkimuksessa (Pagani, De Astis, Graziano, Lanzi & Balzarotti 2016) tutkittiin harmaalistauksen ja nolisting-tekniikan tehokkuutta roskapostin torjunnassa. Tuloksissa todettiin, että molemmat tekniikat olivat tehokkaita yhä vuonna 2015. Yhdessä ne torjuivat yli 70 % roskapostista. Tutkijat havaitsivat, että yleisimmät roskapostia lähettävät haittaohjelmat läpäi- sivät molemmat tekniikat, kun niitä käytettiin vain yksinään. Ne eivät silti läpäisseet tekniikoita, kun harmaalistaus ja nolisting -tekniikoita käytettiin samanaikaisesti. Tutkimuksen mukaan Kelihos-haittaohjelma vastasi vuonna 2014 noin 36 % bottiverkkojen tuottamasta roskapostista. Se oli ainoa tutkittu haittaohjelmaperhe, jota vastaan nolisting toimi yksi- nään. Muiden tunnetuimpien bottiverkkojen lähettämät roskapostit päätyivät myös pienempien prioriteettien sähköpostipalvelimille. (Pagani 2016.)

5.5 Sähköpostin sisällönsuodatus

Yleinen tapa tunnistaa roskapostia tapahtuu sähköpostiviestin sisällönsuodatuksen perusteella. Viestistä voidaan tarkistaa sekä otsaketiedot että sisältöosa. Otsaketietojen sisäl- lönsuodatuksessa etsitään monesti väärennettyjä tietokenttiä, joita roskapostittajien käyt- tämät ohjelmistot yleensä luovat. Tällaisia otsakekenttiä ovat varsinkin otsakkeen ”From” sähköpostiosoite, jolla pyritään uskottelemaan viestin saapuneen eri lähettäjältä. Viestin otsikosta voidaan etsiä tiettyjä sanoja tai merkkijonoja, joita tyypillisesti esiintyy roskapos- teissa. Etsityt hakusanat voivat olla staattisia tai dynaamisesti ajankohtaisten roskaposti- kampanjoiden myötä muuttuvia. (Taugh 2003, 6.)

Samanlaista sisällönsuodatusta suoritetaan myös sisältöosan tekstille ja liitetiedostoille. Tekstistä etsitään tiettyjä sanoja tai merkkijonoja, joita tunnetusti esiintyy roskapostivies- teissä (Taugh 2003, 6). Esimerkiksi viestit, joiden sisältö liittyy palkintorahoihin, lottovoit- toihin tai potenssilääkkeisiin, tunnistetaan hyvin herkästi roskapostiksi. Lisäksi viestien si- sällöistä etsitään mahdollisesti haitallisia linkkejä, joille voidaan tehdä maineentarkistus DNS-pohjaisilla mustalistoilla.

Modernit sisällönsuodattimet voivat tarkistaa myös viestin liitetiedostot ja muun MIME-si- sällön, kuten kuvat. Sähköpostipalvelimen ylläpitäjä voi itse määritellä ennalta, millaiset tiedostomuodot sallitaan tai millaisia avainsanoja niissä ei saa esiintyä (IJS 2018). Esi- merkki tunnetusta vapaan ohjelmiston sisällönsuodattimesta on Amavisd-new, jota käyte- tään monesti yhdessä bayesilaisena suodattimena toimivan SpamAssassinin ja ClamAV- virustutkan kanssa Linux-pohjaisella sähköpostipalvelimella.

Windows-pohjaisissa Microsoft Exchange -sähköpostipalvelimissa on oma ”Content Filter Agent”, joka toimii sekä sisällönsuodattimena että roskapostin luokittelijana bayesilaisen suodattimen tavoin. Se arvioi viestin sisällön perusteella, millä todennäköisyydellä se on roskapostia. Arvioinnissa se käyttää vertailukohtana aiempaa laajaa otantaa aidoista säh- köposteista ja roskaposteista. Tarkistuksen pohjalta sähköpostiviestille annetaan SCL- arvo lukujen 0-9 väliltä. Mitä suurempi numero sitä todennäköisemmin viesti on roskapostia. Palvelimen ylläpitäjä voi sitten määritellä, mitä kunkin arvon saaneelle viestille teh- dään. Viestit voidaan esimerkiksi poistaa, hylätä tai asettaa karanteeniin. (Microsoft 2018b.)

5.6 Bayesilainen suodatus

Bayesilainen suodatus perustuu koneoppimisessa paljon käytettyyn Naive Bayes -luokitte- luun. Sitä on jo pitkään hyödynnetty roskapostin tunnistamiseksi tavallisen sähköpostilii- kenteen joukosta. Bayesilainen suodatus perustuu käytäntöön, jonka mukaan todennäköi- syys tietyn tapahtuman esiintymiselle on ennustettavissa aiempien tapahtumien esiintymi- sistä. (Iqbal, Abid, Ahmad & Khurshid 2016, 17.)

Bayesilaiset suodattimet luokittelevat sähköpostiviestit joko roskapostiksi (spam) tai harmittomiksi sähköpostiviesteiksi (ham). Ne luokittelevat sähköpostiviestejä niiden aiempien kokemuksien perusteella. Suodattimia koulutetaan tilastollisesti aiempien harmittomien sähköpostiviestien ja haitallisten roskapostien avulla, miltä roskaposti näyttää tavalliseen sähköpostiin verrattuna. Bayesilainen suodatin ei yksinään kykene tekemään erotusta, ellei sille ole annettu pohjaa, josta se voi oppimalla tehdä johtopäätöksensä viestien luokit- telujen todennäköisyyksistä. (Eberhardt 2016, 1.)

Tekniikkaa varten tarvitaan tietokanta, joka koostuu sähkö- ja roskapostiviesteistä kerä- tyistä tavallisista sanoista, merkeistä ja merkkijonoista. Kullekin sanalle tai merkkijonolle annetaan todennäköisyysarvo, joka perustuu laskelmiin siitä, kuinka usein kyseinen sana on esiintynyt roskapostiviesteissä tavallisiin harmittomiin viesteihin verrattuna. On oleellista, että bayesilaisen suodattimen tietokantaa päivitetään säännöllisesti tunnistamaan myös uusimmat roskapostiviestit. Sitä ne tyypillisesti tekevät itsenäisesti eli oppivat tar- kemmiksi, kun sähköpostiviestejä vastaanotetaan tai estetään ajan myötä. (Iqbal 2016, 17-18.)

Kuvassa 4 on esitetty sähköpostiviestin käsittely bayesilaisessa suodattimessa. Kuvan nuolet kuvaavat viestin kulkua. Viesti saapuu lähettävältä sähköpostin siirto-ohjelmalta vastaanottavalle siirto-ohjelmalle, jossa se kulkee bayesilaisen suodattimen läpi. Viestin sisältöä verrataan suodattimen tietokantaan tallennettuihin tietoihin, jotka on yhdistetty suodattimen aiempien kokemuksien perusteella joko roskapostille (kuvassa punainen tietokanta) tai harmittomille sähköpostiviesteille ominaisiksi tiedoiksi (vihreä tietokanta). Bayesilainen suodatin laskee todennäköisyyden sille, kumpaan kategoriaan viesti kuuluu. Jos sähköpostiviesti katsotaan harmittomaksi, se lähetetään edelleen sähköpostin toimitusohjelmalle, jonka kautta se kulkee sähköpostin käyttäjäohjelmalle ja loppukäyttäjälle.

Kuva 4. Bayesilainen suodatus vastaanottavalla sähköpostin siirto-ohjelmalla

Tunnetuin ja yleisimmin käytetty tapa hyödyntää tekniikkaa on vapaan ohjelmiston Apache SpamAssassin. Se on sähköpostin sisällönsuodatin, joka käyttää myös bayesilaista suodatusta. SpamAssassin voidaan asentaa sähköpostin siirto- tai toimitusohjel- mille. Siirto-ohjelmalle asennettuna viestin suodatus tapahtuu SMTP-yhteyden aikana. Se on paras sijainti keskitetylle roskapostisuodatukselle, sillä kaikki organisaatiolle saapuva posti kulkee sen kautta. SpamAssassin on asennettavissa myös sähköpostin toimitusohjelmalle, jolloin voidaan käyttöönottaa käyttäjäkohtaisia suodatussääntöjä. Kyseinen vaihtoehto on palvelinresurssien kannalta raskaampaa, sillä suodatus tehdään viestin vastaanottamisen jälkeen sen sijaan, että se hylättäisiin jo siirto-ohjelmassa SMTP-yhteyden aikana. (Schwartz 2004.)

SpamAssassin antaa sähköpostiviesteille pisteytyksen sen havaitsemien tunnisteiden perusteella. Oletuksena yli 5.0 pistearvon saaneet viestit merkitään roskapostiksi. Kun viesti on kulkenut SpamAssassin-suodattimen läpi, sen otsaketietoihin lisätään kenttiä, jotka kertovat viestin saamasta pisteytyksestä ja käytetyn suodattimen versiotiedoista. Alla on esimerkkituloste ohjelman luomista otsaketiedoista viestissä, joka tunnistettiin roskapostiksi. (SpamAssassin 2019a.)

X-Spam-Checker-Version: SpamAssassin 3.4.2 (2019-05-16) on localhost X-Spam-Flag: YES X-Spam-Level: ********** X-Spam-Status: Yes, score=10.9 required=5.0 tests=FROM_LOCAL_NOVOWEL, HTML_FONT_LOW_CONTRAST,HTML_FONT_SIZE_LARGE,HTML_MESSAGE,HTML_OBFUS- CATE_05_10, MIME_HTML_ONLY,MISSING_MID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_BRBL_LAST- EXT, RCVD_IN_PBL,RCVD_IN_PSBL,RCVD_IN_XBL,RDNS_NONE autolearn=no autolearn_force=no version=3.4.2

Esimerkki 7. SpamAssassinin lisäämiä otsaketietokenttiä

Esimerkin 7 ensimmäinen otsake kertoo käytetyn ohjelman versiotiedot. Toinen otsake- kenttä osoittaa ohjelman merkinneen viestin roskapostiksi. Kolmas kenttä osoittaa visuaalisesti asteriskeilla viestin saaman pisteytyksen. Viimeinen ”X-Spam-Status”-otsakekenttä kertoo tarkat tiedot viestin saamasta pisteytyksestä, ja millä perusteilla pisteet annettiin. Esimerkin ”X-Spam-Status”-kenttä kertoo, että viesti tunnistettiin roskapostiksi pisteytyk- sellä 10,9, kun raja-arvona oli 5.0. Sama otsakekenttä kertoo myös, mitä testejä viestiin sovellettiin roskapostin tunnistamiseksi. Kaikki SpamAssassin-ohjelman suorittamat testit löytyvät ohjelman virallisesta dokumentaatiosta (SpamAssassin 2019b). Sähköpostipalve- limen ylläpitäjät voivat itse määritellä, mitä testejä sovelletaan tai jätetään soveltamatta viesteihin.

5.7 Fyysiset roskapostisuodattimet

Yksi tapa vähentää roskapostia on käyttää kaupallisia fyysisiä roskapostisuodattimia. Tunnettuja suodatinmalleja ovat esimerkiksi Cisco Email Security Appliance (entinen Iron- Port) ja Barracuda Spam Firewall. Ne yhdistelevät tässä opinnäytetyössä käsiteltyjä tekniikoita yhden fyysisen laitteen sisään. Etuna on se, että laite voidaan sijoittaa organisaation omien sisäisten sähköpostipalvelimien eteen. Tällöin roskapostinsuodatus ei kuluta palvelinresursseja sisäisiltä palvelimilta, koska tarkistukset on jo tehty ennen kuin viestit saapuvat niille. Laitteen tyypillinen sijainti on demilitarisoidulla alueella organisaation palomuurin ja julkisen internetin välissä. (Return Path 2019c.)

Kaupalliset vaihtoehdot eroavat toisistaan niiden käyttämien tekniikoiden osalta. Tyypilli- sesti ne on määritetty tekemään tarkistuksia muun muassa lähettäjän maineesta DNS- pohjaisella mustalistauksella ja suorittamaan viestien sisällönsuodatusta bayesilaisilla suodattimilla. Esimerkiksi Ciscon laitteet testaavat lähettäjän maineen DNS-pohjaisilla mustalistoilla, viestin sisällön erilaisilla suodattimilla, estävät osoitteiden väärentämisyri- tykset, toteuttavat virusskannausta sekä saapuvassa että lähtevässä liikenteessä ja salaa- vat lähtevän sähköpostiliikenteen. (Cisco 2017.)

Markkinoilla on myös suomalainen tuote, joka käyttää tekniikoita, kuten viestin sisällön- suodatusta, bayesilaista suodatusta, DNSBL-listoja, harmaalistausta, virusskannausta, sekä Sender ID -, SPF- ja DKIM-tekniikoita, joista kerrotaan myöhemmin opinnäytetyön luvuissa 6.1-6.3. (Arrak 2019.)

5.8 Pilvipalvelupohjainen roskapostisuodatus

Sähköpostipalvelujen ostaminen pilvipalveluna on kasvanut suosiossa, mikä tekee myös roskapostin torjunnasta helpompaa palvelun ostaneelle organisaatiolle. Tällöin palvelun

28 tietoturva ja ylläpito ovat pääosin palveluntarjoajan vastuulla, mikä säästää organisaation IT-resursseja. Pilvipalvelupohjaiset ratkaisut ovat tyypillisesti helpommin skaalattavissa ja ylläpito on yksinkertaisempaa kuin paikallisissa sähköpostipalveluissa (Cohen 2019). Os- tettaviin sähköpostipalveluihin kuuluu lähes poikkeuksetta myös valmiiksi konfiguroidut ja tehokkaat roskapostin torjuntatekniikat. Tämän opinnäytetyön tutkimusosiossa selvitetään suomalaisten yritysten käyttämiä roskapostin torjuntatekniikoita, minkä yhteydessä tutki- taan myös yritysten käyttämiä sähköpostipalveluita. Tässä luvussa tarkastellaan käyte- tyimpien pilvipohjaisten sähköpostipalveluiden hyödyntämiä torjuntatekniikoita sekä tutus- tutaan puhtaasti roskapostin torjuntaan kehitettyjen pilvipalveluiden toimintaan.

5.8.1 Office 365

Microsoftin Office 365 on yksi tunnetuimpia pilvipalveluita, joihin sisältyy yritystason säh- köpostipalvelu. Office 365 -pakettiin kuuluva sähköposti perustuu Exchange Online -säh- köpostipalvelimeen, johon kuuluu oletuksena Exchange Online Protection (EOP) -roska- postisuodatin. EOP-palvelu on myös mahdollista integroida organisaation jo olemassa oleviin paikallisiin Microsoft Exchange -palvelimiin, tosin yleisimmin sitä käytetään osana Office 365 -palvelua (Microsoft 2019d).

Microsoft kuvaa EOP -roskapostisuodattimen toimintaa kuvan 5 esittämällä tavalla. Orga- nisaatiolle tarkoitetut sähköpostiviestit reititetään Microsoftin palvelimien kautta MX-tietueiden perusteella. EOP suodattaa ensin saapuvaa SMTP-liikennettä, minkä yhteydessä tarkistetaan lähettäjän maine ja viestistä tunnistetaan mahdolliset haittaohjelmat. Suurin osa roskapostista torjutaan jo heti ensimmäisessä vaiheessa. Ylläpitäjät voivat myös halutessaan luoda omia musta- tai valkolistoja tietyille IP-osoitteille tai maantieteellisille sijain- neille, joita sitten käytetään yhteyksien suodattamisessa.

Seuraavassa vaiheessa viesti käsitellään ennalta määriteltyjen käytäntösuodattimien kautta. Siinä viestit arvioidaan ylläpitäjän määrittelemien kuljetussääntöjen perusteella. Säännöillä voidaan esimerkiksi määritellä, että tietyn lähettäjän viesteistä kulkeutuu aina ilmoitus organisaation sähköpostipalvelujen ylläpitäjille. Tiettyjä liitetiedostoja sisältävät viestit voidaan torjua kokonaan ja toimenpiteestä voidaan lähettää ilmoitus viestin lähettä- jälle tai vastaanottajille (Microsoft 2019f). Kuljetussäännöt ovat vapaaehtoisia, eli niiden asettamia käytäntöjä ei sovelleta viesteihin oletuksena. Viimeisessä vaiheessa viestit läpi- käyvät sisällönsuodatusta niissä esiintyvien sanojen tai muiden yleisesti roskapostiin liitet- tyjen yhteneväisyyksien perusteella. Sisältösuodattimet ovat ylläpitäjien itsensä konfiguroi- tavissa. (Microsoft 2019d.)

Tarkistuksen myötä merkatut sähköpostiviestit voidaan asettaa karanteeniin tai käsitellä muulla ylläpitäjän määrittelemällä tavalla. Viestit kuljetaan lopullisille vastaanottajille, kun ne ovat läpäisseet kaikki EOP-roskapostisuodattimen vaiheet. (Microsoft 2019d.)

Kuva 5. Microsoft Exchange Online Protection (EOP) -suodattimen toimintavaiheet ja säh- köpostin kulku (mukaillen Microsoft 2019d)

EOP-suodatinta voidaan käyttää sekä sisään- että ulospäin suuntautuvan sähköpostilii- kenteen suojaukseen. EOP tarkistaa aina oletuksena saapuvan liikenteen, eikä sitä voida poistaa käytöstä edes niin haluttaessa. Lähtevän postin suodatus on sen sijaan vapaaehtoista. Molemmissa tapauksissa suoritetaan kuvan 5 mukaiset keltaiset vaiheet. EOP-palveluun sisältyy myös muita torjuntatekniikoita, jotka keskittyvät yksilöllisempiin roskaposti- tyyppeihin. Se käyttää DNSBL-listoja tunnettujen roskapostittajien tunnistamiseen, joita se etsii viesteihin sisällytetyistä linkeistä. DNSBL-listoilla EOP tunnistaa myös tietojenkalaste- luyrityksiä sekä torjuu backscatter-viestejä, jotka ovat seurausta automatisoiduista palau- tusviesteistä. (Microsoft 2016.)

Microsoft suosittelee organisaatioita käyttämään SPF-, DKIM- ja DMARC-tekniikoita Ex- change Online Protection -palvelun ohella (Microsoft 2018c). Kyseisiä tekniikoita käsitel- lään laajemmin opinnäytetyön luvussa 6. Niitä käytetään sähköpostiviestien ja niiden lä- hettäjien aitouden todentamiseen. SPF on Office 365 -palvelussa valmiiksi käyttöönotet- tuna, eli SPF-tarkistukset tehdään saapuvassa liikenteessä ja organisaation puolesta on julkaistu SPF-tietue (Microsoft 2018a). DKIM on myös konfiguroitu toimimaan oletuksena

30 sekä saapuvassa että lähtevässä liikenteessä. Tietyissä tapauksissa olisi silti hyvä manuaalisesti ottaa DKIM käyttöön, jos esimerkiksi halutaan täysi hallinta omasta yksityisestä avaimesta tai jos organisaatiolla on useita suojattavia verkkotunnuksia (Microsoft 2019g). Organisaation tulee itse luoda DMARC-tietue lähtevää liikennettä varten, mutta Office 365 käyttää oletuksena DMARC-tarkistuksia saapuvalle liikenteelle (Microsoft 2019h).

Jos Officen sähköpostiin halutaan laajemmat turvallisuusominaisuudet, Microsoft tarjoaa myös Office 365 Advanced Threat Protection (ATP) -lisäpalvelun erillisen tilauksen kautta. Se voidaan ottaa käyttöön organisaation Exchange Online -sähköpostipalvelimen tai pai- kallisten palvelimien kanssa. Pakettiin kuuluu muun muassa liitetiedostojen skannaus, haitallisten linkkien havaitseminen sisältöosassa tai liitetiedostossa, tietojenkalasteluyritysten torjunta koneoppimisen ja ennalta määriteltyjen käytäntöjen kautta sekä erilaisia reaaliai- kaisten uhkien seurantatyökaluja, jotka puuttuvat EOP-palvelusta. ATP mahdollistaa myös simuloitujen hyökkäysten toteuttamisen organisaation sähköpostipalveluihin. (Microsoft 2019e.)

5.8.2 G Suite

G Suite on Googlen vastine Office 365 -pilvipalvelulle. Se on pilvipalvelu, johon kuuluu sähköposti organisaation omalla toimialuenimellä. G Suiten sähköpostipalvelu perustuu ilmaiseen Gmail-sähköpostiin, mutta siihen sisältyy lisäksi ylläpitäjille laajemmat hallinta- työkalut, jotka puuttuvat Gmailin ilmaisversioista.

Google suodattaa roskapostia omilla suodattimillaan, jotka siirtävät roskapostiksi epäillyt viestit oletuksena käyttäjän Gmail-sähköpostiohjelman roskapostikansioon. Ylläpitäjät voivat halutessaan lisätä tiettyjä lähettäjiä valkolistalle, jolloin heiltä vastaanotettuja viestejä käsitellään hellävaraisemmin. Googlen suodattimet vertaavat viestin otsaketietojen ”FROM”-kentän osoitteen tahoa valkolistattuihin lähettäjiin. Viestit voidaan silti merkitä roskapostiksi, vaikka niiden lähettäjä olisikin organisaation ylläpitäjän määrittelemällä val- kolistalla. Kaikki viestit läpikäyvät oletuksena virusskannauksen, jonka yhteydessä mahdollisia haittaohjelmia sisältävät viestit hylätään täysin. Skannaus suoritetaan aina myös liitetiedostoille, mutta ylläpitäjät voivat itse määritellä tarkemmat säännöt valituille tiedosto- tyypeille. (Google 2019a.)

G Suite mahdollistaa valkolistauksen ohella mustalistauksen lähettäjien toimialuenimien tai sähköpostiosoitteiden perusteella, jolloin kyseisten lähettäjien viestit hylätään (Google 2019b). Tietojenkalasteluyrityksiä voidaan torjua tarkennetulla skannauksella ennen vies-

31 tin vastaanottoa. Palveluun kuuluu myös kehittyneemmät suodattimet kohdennetun verkkourkinnan estämiseksi. Kyseiset toiminnot ovat vapaaehtoisia eivätkä ole palvelussa oletuksena päällä. (Google 2019c.)

G Suite todentaa oletuksena lähettäjän ja viestin aitouden, mikä tapahtuu SPF-, DKIM- ja DMARC-tarkistuksilla sisäänpäin suuntautuvassa eli saapuvassa liikenteessä (Google 2019d). Organisaation lähtevä liikenne ja verkkotunnukset suojataan oletuksena SPF-tekniikalla, jos verkkotunnukset on rekisteröity Google Domains -palvelun kautta (Google 2019e). Muulloin ne täytyy konfiguroida itse. Kaikki lähtevät viestit allekirjoitetaan aina vä- hintään Googlen oletusarvoisella DKIM-avaimella. Suositeltavaa olisi silti ottaa DKIM käyt- töön organisaation omalla avaimella (Google 2019f). DMARC-tietue tulee aina luoda itse lähtevää liikennettä varten (Google 2019g).

Googlen G Suite ja Gmail ovat harvoja kaupallisia tai vapaan ohjelmiston sähköpostipal- veluita, jotka ovat käyttöönottaneet ARC-protokollan. Tämä ei ole ihmeellistä, sillä protokolla on yhä konseptivaiheessa (ARC Specification for Email 2019a). Käyttöönotto voi silti ennakoida protokollan leviämistä laajempaan käyttöön tulevaisuudessa, joskin siihen on vaikuttanut Google laaja osallistuminen protokollan kehitykseen. ARC-protokollaa käsitel- lään tarkemmin opinnäytetyön luvussa 6.5.

5.8.3 D-Fence

D-Fence on esimerkki suomalaisesta pilvipalvelumalliin pohjautuvasta sähköpostiturvapal- velusta, joka keskittyy ensisijaisesti tietoturvallisuuteen ja roskapostin torjuntaan. D-Fence Email Security (eSec) on tuote, joka voidaan integroida organisaation itse ylläpitämiin säh- köpostipalveluihin tai ostettuihin pilvipalvelupohjaisiin ratkaisuihin. Tällöin se toimii roska- postisuodattimena julkisen internetin ja organisaation käyttämien sähköpostipalvelimien välissä. Palvelu koostuu roskaposti- ja virustorjunnasta, tunkeutumisen estosta, sähkö- postiviestien varmennuksesta sekä liikenteen salauksesta. (D-Fence 2019a.)

D-Fence eSec -palvelun käyttöönotto tapahtuu asiakkaan näkökulmasta pelkällä nimipalvelun MX-tietueiden määrityksellä (D-Fence 2019a). Tällöin kaikki organisaatiolle suunnattu sähköposti reititetään D-Fencen kautta, jonka palvelimet suodattavat roskapostia pa- tentoidulla UIDS-teknologialla. Tällä teknologialla voidaan D-Fencen mukaan tunnistaa automatisoidut roskapostittajat reaaliajassa. Tekniikka vertaa viestin lähettävältä palvelimelta kerättyjä tietoja D-Fencen tietokantoihin ja käyttää ID-algoritmia tunnistaakseen automatisoidut roskapostittajat aidoista sähköpostipalvelimista (D-Fence 2019b). D-Fence ei ole julkaissut yksityiskohtaisempaa tietoa kyseisen teknologian teknisestä toiminnasta.

Lähettävän palvelimen tarkistusten jälkeen sähköpostille lasketaan vielä pistearvo, jonka perusteella se käsitellään palvelussa määriteltyjen asetusten mukaisesti. Asetukset määri- tellään asiakastoimialuekohtaisesti (D-Fence 2019c). Tuotteessa yhdistellään D-Fencen oman teknologian lisäksi yleisesti tunnettuja torjuntatekniikoita, joita monitoroidaan ja sää- detään jatkuvasti ajankohtaisten tilanteiden mukaan (Oravala 29.5.2019). Tuote myös pyrkii tunnistamaan osoitteiden väärennökset ja kohdennetut verkkourkintayritykset. (D- Fence 2019a.)

D-Fencen kaltaisen palvelun etu on siinä, että se vähentää sähköpostipalvelujen ylläpi- toon käytettyjä resursseja. Se on myös integroitavissa organisaation jo olemassa oleviin sähköpostipalveluihin, eikä siten rajoita sähköpostin käyttöä tiettyyn palveluntarjoajaan. Kaikille yrityksille ei riitä pilvipalvelupohjaisten sähköpostipalveluiden sisältämien tietotur- varatkaisujen teho, minkä vuoksi erilliselle turvapalvelulle on kysyntää organisaation liiketoiminnasta riippuen (Oravala 29.5.2019).

6 Lähettäjän ja viestin todentaminen sähköpostiliikenteessä

Opinnäytetyön edellisissä luvuissa käsiteltiin tekniikoita, joilla voidaan torjua roskapostia sen sisällön tai lähteen perusteella. Mitkään kyseisistä torjuntakeinoista eivät ota kantaa viestin lähettäjän identiteetin aitouteen. Kyseiseen tarkoitukseen on kehitetty useita tekniikoita, protokollia ja käytäntöjä, joista osa katsotaan jo lähestulkoon standardeiksi roskapostin torjunnassa. Tekniikoiden tarkoituksena on estää haitallisia tahoja käyttämästä organisaation toimialuenimeä ja verkkotunnuksia tietojenkalasteluun tai kohdennettuun verkkourkintaan sekä varmistaa viestin muuttumattomuus sähköpostiliikenteen aikana. Tunnettuja tekniikoita viestin ja sen lähettäjän todentamiseen ovat SPF, Sender ID, DKIM, DMARC ja ARC. Ne täydentävät osaltaan vanhaa SMTP-protokollaa, jossa ei ole otettu huomioon nykyisen sähköposti-infrastruktuurin turvallisuuspuutteita.

SPF-, DKIM- ja DMARC-tekniikoiden käyttöönottoon löytyy enemmän ohjeita laajem- massa mittakaavassa, koska niillä on hyvin vakiintunut käyttäjäkunta. Sender ID- ja ARC - protokollat ovat yhä konseptivaiheessa, eikä niitä ole otettu yhtä laajamittaisesti käyttöön.

6.1 Sender Policy Framework (SPF)

SPF osoittaa, mitkä sähköpostipalvelimet saavat lähettää sähköpostia organisaation toimialuenimen nimissä. Nykyisen sähköposti-infrastruktuurin ongelmana on se, että kuka tahansa taho pystyy lähettämään sähköpostiviestejä millä vain haluamallaan toimialueni- mellä. Se taas johtaa ongelmiin roskapostituksen kanssa, sillä tietyt tahot voivat käyttää oikeiden organisaatioiden toimialuenimiä haitallisiin tarkoituksiin. SPF mahdollistaa viestin lähettäjän todentamisen sähköpostiviestin kirjekuoren ”MAIL FROM” ja ”EHLO”-komen- noista vastaanottajan toimesta. (IETF 2014, 5.)

SPF määritellään TXT- eli tekstitietueeseen nimipalvelun tasolla. Viestin vastaanottava sähköpostipalvelin voi verrata lähettäjän toimialuenimen tekstitietueessa sallittuja palvelimia viestin lähettäneen palvelimen IP-osoitteeseen ja käsitellä viestin vastaanoton tietueen julkaisseen tahon suositusten mukaisesti. (IETF 2014, 5.)

Toimialuenimellä voi olla vain yksi SPF-tekstitietue, mutta jokaiselle alitoimialueelle voidaan luoda oma tietue. Se on myös kannattavaa, sillä muuten osoitteiden väärentäminen onnistuu alitoimialuenimien kautta, jolloin SPF-tarkistusta ei tehdä. Jos sallittavia palvelimia pitää määritellä lisää, muokataan jo olemassa olevaa tietuetta eikä luoda uutta. Oikea SPF-tietue koostuu aina SPF-versiosta, yhdestä tai useammasta mekanismista ja niiden karsijoista sekä lopullisesta täytäntöönpanosäännöstä (Microsoft 2018a; OpenSPF 2019).

Tietue voi myös sisältää harvemmin käytetyn määritteen, mutta niitä voi olla vain yksi. Me- kanismit arvioidaan aina järjestyksessä vasemmalta oikealle ja täytäntöönpanosääntö luetaan viimeisenä. (OpenSPF 2019.)

Jos mekanismi täsmää lähettävän palvelimen kanssa, käytetään sen karsijaa. Oletuskar- sija on ”+”, jota harvemmin nähdään merkittynä tietueissa, koska se otetaan käyttöön joka tapauksessa, jos mekanismi täsmää sähköpostin lähettäneeseen palvelimeen eikä toista karsijaa ole määritetty kyseiselle mekanismille. (OpenSPF 2019.)

6.1.1 SPF-tietueen tunnisteet

SPF-tekstitietue koostuu useasta tunnisteesta, joiden lukumäärät vaihtelevat riippuen toimialueen tarpeista. Purkamalla osiin seuraava esimerkkitietue saadaan eroteltua SPF- tietueeseen tyypillisesti kuuluvat tunnisteet: example.net IN TXT “v=spf1 ip4:1.2.3.4 include:example.net -all”

Esimerkki 8. Tyypillinen nimipalvelun SPF-tekstitietue

v: Aloittaa aina SPF-tekstitietueen. Se osoittaa käytetyn SPF-version, joka on nykystandardeilla ”spf1”. (Carranza 2013.)

ip4: Mekanismi, jolla määritellään ne IPv4-osoitteet, jotka ovat sallittuja lä- hettäjiä (Carranza 2013). Tyypillisesti on parempi luetella IP-osoitteilla mää- ritellyt palvelimet ennen toimialuenimillä määriteltyjä palvelimia, sillä IP-osoitteiden kanssa ei ole tarvetta DNS-kyselylle, jossa kestää kauemmin.

include: Mekanismi, jolla määritellään ne toimialuenimet, jotka ovat sallittuja lähettäjiä (Carranza 2013).

-all: Täytäntöönpanosääntö, joka koostuu karsijasta ”-” ja mekanismista ”all” (Microsoft 2018a). Se luetaan tietueessa viimeisenä. Karsija johtaa tulokseen ”Fail”, minkä seurauksena kaikki posti hylätään lähettäjiltä, joita ei ole sallittu tietueessa ennen täytäntöönpanosääntöä (OpenSPF 2019). Jos yllä- pitäjä on konfiguroinut SPF-tekniikan oikein, tietueen tulisi aina loppua ”-all”- tai ”~all”-säännöllä. Muulloin kaikki sähköposti hyväksyttäisiin miltä tahansa palvelimelta sellaisenaan joka tapauksessa, ja tekniikan käyttö olisi turhaa.

6.1.2 SPF-tarkistus

SPF-tietueen mekanismien ja karsijoiden tarkistus johtaa tyypillisimmin johonkin taulukon

2 esittämistä tuloksista.

Taulukko 2. SPF-mekanismien tulokset (OpenSPF 2019) Karsija Tulos Selitys Toiminto + Pass Tietueen perusteella palvelin saa lähettää. hyväksy - Fail Tietueen perusteella palvelin ei saa lähettää. hylkää ~ SoftFail Tietueen perusteella palvelin ei saa lähettää, hyväksy, mutta mutta tietue on muutostilassa (testauksessa). merkitse ? Neutral Tietue määrittelee, että mitään ei voida sanoa hyväksy lähettäjän oikeellisuudesta.

SPF-tietueet ovat yleisimpiä tapoja suojata yritysten toimialuenimet osoitteiden väären- nösyrityksiltä. Ne eivät kuitenkaan ole riittävä suoja, sillä SPF-tarkistuksen toiminta perustuu pääosin SMTP-liikenteen ”MAIL FROM”-osoitteeseen, joka on väärennettävissä. Ros- kapostittaja voi esimerkiksi läpäistä SPF-tarkistuksen käyttämällä ”MAIL FROM”-osoit- teena sähköpostiosoitetta omalta toimialueeltaan, jolla on oikein konfiguroitu SPF-tietue. Tällöin vastaanottava sähköpostipalvelin tarkistaa lähettäjän SPF-tietueen ja toteaa sen sallivan viestin lähettämisen hyökkääjän käyttämältä palvelimelta. Huijaus tapahtuu siinä, kun roskapostittaja väärentää sähköpostiviestin otsaketietojen lähettäjäkentän, joka on loppukäyttäjän nähtävissä. Tällöin vastaanottajana toimiva käyttäjä luulee viestin tulleen ”From”-otsakkeen mukaiselta lähettäjältä, vaikka oikea osoite olisi nähtävissä vain viestin kirjekuoren ”MAIL FROM”-osoitteesta, joka läpäisi SPF-tarkistuksen luotettavana lähettä- jänä. (Whalen 2018.)

Lisäksi SPF ei toimi hyvin tilanteissa, joissa sähköpostia ei välitetä suoraan lähettäjältä vastaanottajalle, vaan se lähetetään edelleen välilliseltä sähköpostipalvelimelta. Ongelma on havainnollistettu kuvassa 6, jossa lähettäjänä toimii toimialue example.net ja lopullisena vastaanottajana example.com.

Kuva 6. Sähköpostipalvelimilla suoritetut SPF-tarkistukset välillisen palvelimen edelleen lähettämälle viestille (mukaillen Microsoft 2018a)

Harmaat laatikot esittävät kuvassa eri toimialueiden sähköpostipalvelimia. Pistemäiset katkonuolet esittävät palvelimien tekemiä nimipalvelukyselyitä alkuperäisen lähettäjän ni- mipalvelutietueisiin, jotka näkyvät kuvassa sinisellä. Tavalliset nuolet kuvaavat sähköpos- tiviestin kulkua palvelimien välillä. Palvelimien toteuttamat SPF-tarkistukset näkyvät kuvassa joko vihreällä tai punaisella riippuen niiden tuloksista.

Viesti läpäisee kuvan 6 mukaisesti SPF-tarkistuksen mapy.fi-toimialueen sähköpostipalve- limella, jossa tarkistuksen onnistunut tulos on esitettynä vihreällä taustalla. Kyseinen säh- köpostipalvelin lähettää viestin sitten eteenpäin lopullisen vastaanottajan eli example.com- toimialueen sähköpostipalvelimelle. Example.com tekee viestille oman SPF-tarkistuksen, jonka epäonnistunut tulos näkyy punaisella taustalla. Tarkistus epäonnistuu, sillä viesti ei saavu alkuperäisen lähettäjän, eli example.net-toimialueen, nimipalvelun SPF-tietueessa sallitun palvelimen kautta. Sinisestä laatikosta nähdään, että example.net-toimialue on ilmoittanut IP-osoitteen 1.2.3.4 sallituksi lähettäjäksi. Sallittu palvelin ei vastaa mapy.fi-toimialueen sähköpostipalvelimen IP-osoitetta 8.8.4.4, jolta viesti vastaanotetaan. Tuolloin SPF-tarkistus epäonnistuu viestin lopullisessa kohteessa.

Näiden ongelmien vuoksi on suositeltavaa käyttää SPF-tekniikan ohella myös DKIM- ja DMARC-tekniikoita, joita käsitellään tarkemmin myöhemmissä luvuissa 6.3 ja 6.4. Vaihto- ehtoisesti, jos käytetään tietoisesti turvallista ja tunnettua välityspalvelinta, voidaan sen IP- osoite tai sitä vastaava toimialuenimi lisätä lähettäjän SPF-tietueeseen. SPF-tietueen

37 päättäminen täytäntöönpanosäännöllä ”~all” voi myös olla tietyissä ympäristöissä kannattavaa, sillä tällöin viesti ainakin vastaanotetaan, vaikka se merkitään todennäköisesti roskapostiksi.

6.2 Sender ID

Sender ID on Microsoftin kehittämä protokolla, jonka toimintaperiaate vastaa SPF-tekniikkaa. Molemmat kertovat, mitkä palvelimet saavat lähettää sähköpostia organisaation toimialueen nimissä. Toisin kuin SPF, Sender ID pystyy tekemään lähettäjän tarkistuksen sekä sähköpostiviestin otsaketietojen ”From”-kentästä että SMTP-yhteyden ”MAIL FROM”-osoitteesta. (OpenSPF 2012.)

Sender ID määritellään SPF-tekniikan tavoin tekstitietueeseen nimipalvelun tasolla. Vies- tin vastaanottava sähköpostipalvelin vertaa lähettäjän toimialuenimen nimipalvelun tekstitietueessa sallittuja palvelimia viestin lähettäneeseen palvelimeen (Hajdarbegovic 2019). Sender ID -tietue on rakenteeltaan lähes identtinen SPF-tietueiden kanssa. Molemmat si- sältävät mekanismeja, niiden karsijoita ja lopullisen täytäntöönpanosäännön. Oleellisena erona on tietueen ensimmäinen osa, joka kertoo käytettävän tekniikan version. Sender ID -tietue alkaa aina joko ”spf2.0/pra”-, ”spf2.0/mfrom”- tai ”spf2.0/mfrom,pra”-tunnisteella (OpenSPF 2012). Tunnisteen valinta määrittelee protokollan toiminnan alla esitettyjen ku- vausten mukaisesti.

spf2.0/mfrom: Tarkista viestin kirjekuoren ”MAIL FROM”-osoitteen lähettäjä. Tällöin Sender ID toimii SPF-tietueen tavoin. (OpenSPF 2012.)

spf2.0/mfrom,pra tai spf2.0/pra,mfrom: Tarkista sekä viestin kirjekuoren ”MAIL FROM” -osoitteen lähettäjä että PRA (OpenSPF 2012).

spf2.0/pra: Tarkista vain PRA (OpenSPF 2012).

Sender ID käyttää PRA-algoritmia. Algoritmi valitsee, mikä viestin otsaketietokenttien säh- köpostiosoitteista kuuluu todennäköisimmin viestin lähettäjälle. Yksinkertaistettuna PRA on otsaketiedoissa näkyvä lähettäjäosoite, jonka Sender ID tarkistaa, jos PRA on määri- telty tarkistettavaksi tietueen alussa. (Hajdarbegovic 2019.)

Vaikka Sender ID vaikuttaa samanlaiselta SPF-tekniikan kanssa, ei sitä silti tule ajatella SPF:n 2.0 versiona, vaan kyseessä on täysin SPF-tekniikasta erillinen protokolla, jolla ei

38 ole virallista hyväksyntää. Sender ID -tietueen yksilöllistävä ”spf2.0/x”-tunniste on historial- linen erehdys, jota ei ole sittemmin korjattu (OpenSPF 2012). Sender ID -protokolla on julkaistu internetstandardissa RFC 4406 (IETF 2006b) kokeellisena luonnoksena, eli julkai- sun aikaan ei vielä tiedetty, leviääkö protokolla laajaan käyttöön tai toimisiko se ylipää- tänsä käytännössä (IETF 2019b).

Sender ID ei lopulta päätynyt laajamittaiseen käyttöön, vaikka sitä käytetään yhä pienissä määrin. Syitä olivat Microsoftin lisensointiin liittyvät ongelmat, jotka estivät protokollan käyttöönoton vapaan ohjelmiston lisensseillä. Protokolla on myös yhteensopimaton tiettyjen muiden internetstandardien kanssa, joten sitä ei voida katsoa virallisesti hyväksytyksi torjuntatekniikaksi. (OpenSPF 2012.)

6.3 DomainKeys Identified Mail (DKIM)

DKIM on tekniikka, jolla voidaan todentaa sähköpostiviestin aitous digitaalisella allekirjoituksella. Lähettäjä allekirjoittaa viestin otsaketietojen kentät sekä sisältöosan yksityisellä avaimellaan ja julkaisee julkisen avaimensa toimialuenimensä tekstitietueeseen. Viestin vastaanottava sähköpostipalvelin tekee lähettäjän toimialuenimestä DNS-haun ja noutaa lähettäjän tekstitietueessa määritellyn julkisen avaimen. Vastaanottaja käyttää sitten lähet- täjän julkista avainta viestin allekirjoituksen todentamiseen. (Raulot 2019, 5.)

Tekniikan toimintaperiaate on esitetty kuvassa 7, jossa harmaat laatikot kuvaavat lähettä- vää ja vastaanottavaa sähköpostipalvelinta. Tavalliset nuolet kuvaavat sähköpostin kulkua palvelimien välillä. Pistemäiset katkonuolet kuvaavat DNS-liikennettä ja katkonuolet viestin allekirjoittamista ja sen todentamista. Lähettävän palvelimen toimialue on julkaissut julkisen avaimensa nimipalveluun, josta se on kenen tahansa noudettavissa internetin väli- tyksellä. Julkinen avain näkyy kuvassa vaalealla taustalla sinisen pilven sisällä. Lähettävä palvelin allekirjoittaa lähettämänsä sähköpostiviestin yksityisellä avaimellaan, joka koros- tuu kuvassa punaisella taustalla. Vihreällä taustalla esitetty DKIM-allekirjoitus sisällytetään palvelimen lähettämän sähköpostiviestin otsaketietoihin. Vastaanottava palvelin todentaa allekirjoituksen aitouden lähettäjän julkisella avaimella, jonka se noutaa nimipalveluky- selyllä nimipalvelusta.

Kuva 7. Lähettävä sähköpostipalvelin allekirjoittaa viestin yksityisellä avaimellaan, jolloin vastaanottava sähköpostipalvelin varmentaa allekirjoituksen lähettäjän julkisella avaimella (mukaillen Barracuda 2019)

DKIM ei ole riippuvainen avainpareja myöntävistä tunnetuista auktoriteeteista, vaan käyt- täjät voivat itse luoda julkisen ja yksityisen avaimensa (IETF 2011a, 6). Tunnettuja työka- luja avainten luomiseen ovat esimerkiksi PuTTYgen ja OpenSSH:n ssh-keygen. Avainten pituudeksi suositellaan vähintään 1024 bittiä, ja vastaanottavien sähköpostipalvelimien tulee kyetä vahvistamaan jopa 4096 bittiä pitkät salausavaimet. Alle 1024 bittisillä salaus- avaimilla tehdyt allekirjoitukset ovat turvattomia, eikä vastaanottavien palvelimien tulisi kä- sitellä niitä aitoina allekirjoituksina. (IETF 2018a, 3.)

6.3.1 DKIM-tietueen tunnisteet

Julkinen avain määritellään organisaation toimialuenimen tekstitietueeseen nimipalvelun tasolla esimerkin 9 mukaisesti. DKIM-tietueeseen kuuluu aina ”_domainkey” -tunniste käy- tettävän valitsimen ja toimialuenimen väliin. Valitsimesta kerrotaan tarkemmin luvussa 6.3.2. Esimerkin 9 DKIM-tekstitietue voidaan jakaa kolmeen tunnisteeseen. helsinki._domainkey.example.net IN TXT “v=DKIM1;k=rsa;p= AAAAB3NzaC1yc2EAAAABJQAAAIEAth0oZ8A8sYE23H9zyPfBw26gdEzCSB9Ofsvd 7YfbBG83rEUMICptueO5yTKZ/UPL1aq0sNB2Io7lUfDqeJ2gIe1TGJaH3f01e3wT dLFagSea7NWbN5zsXb6eu1NTs7h4BbJYfCDrxswlf8jm3j3rpvC8uFWV763eN0G5 K+hmK4M=”

Esimerkki 9. Tyypillinen nimipalvelun DKIM-tekstitietue

v: Tunniste, joka kertoo käytetyn DKIM-tekniikan version. Nykyinen käytet- tävä version on ”DKIM1” RFC 6376 -standardin mukaisesti. (IETF 2011a, 19.)

k: Tunniste, joka kertoo käytetyn salausavaimen tyypin. Esimerkissä käyte- tään yleistä RSA-avainta. (IETF 2011a, 27.)

p: Tunniste, joka sisältää allekirjoittajan julkisen avaimen (TransIP 2019). Tämä on se avain, jonka vastaanottava sähköpostipalvelin noutaa tarkis- taakseen viestin allekirjoituksen aitouden.

6.3.2 DKIM-allekirjoituksen tunnisteet

Allekirjoitetun viestin DKIM-allekirjoitus talletetaan sähköpostiviestin otsaketietoihin ”DKIM-Signature”-kenttään (IETF 2011a, 18). Kenttä koostuu useasta tunnisteesta alla olevan esimerkin 10 mukaisesti. Luvussa on kuvattu vain tärkeimmät ja pakolliset tunnisteet. Loput hyödylliset mutta vapaaehtoiset tunnisteet löytyvät selityksineen opinnäytetyön liitteestä 3.

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=helsinki; c=simple; q=dns/txt; [email protected]; t=1117574938; x=1118006938; h=from:to:subject:date; z=From:[email protected]|To:[email protected]| Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Esimerkki 10. DKIM-allekirjoitus sähköpostiviestin otsaketiedoissa

v: Käytetyn DKIM-tekniikan versio. Esimerkissä versio on ”1”, joka on nyky- ään myös ainoa käytettävä versio RFC 6376 -standardin mukaisesti. Pakolli- nen tunniste. (IETF 2011a, 19.)

a: Allekirjoituksen luomisessa käytetty salausalgoritmi. Allekirjoittajien tulee nykyisen standardin mukaisesti käyttää rsa-sha256-algoritmia viestin allekir- joittamiseen. Pakollinen tunniste. (IETF 2011a, 19.)

d: Sen organisaation toimialuenimi, joka sähköpostiviestin on allekirjoittanut. Pakollinen tunniste. (IETF 2011a, 20.)

s: Käytetty valitsin. Allekirjoittaneella toimialueella voi olla useita julkisia avaimia, ja siksi valitsimia käytetään avainavaruuden pilkkomiseksi osiin. Ne voivat esimerkiksi kuvata yrityksen toimistojen sijainteja kaupungin nimen perusteella tai allekirjoituksen päivämäärää. Yllä olevassa esimerkissä valit- simena on käytetty kaupunkia Helsinki. Pakollinen tunniste. (IETF 2011a, 24.)

h: Lista allekirjoitetuista opinnäytetyön luvun 3.1.2 mukaisista otsaketieto- kentistä. Otsaketiedot erotetaan toisistaan kaksoispisteellä. Pakollinen tunniste. (IETF 2011a, 21.)

bh: Viestin sisältöosan tiiviste. Pakollinen tunniste. (IETF 2011a, 20.)

b: Viestin digitaalinen allekirjoitus. Pakollinen tunniste. (IETF 2011a, 19.)

6.3.3 DKIM-tarkistus

Viestin vastaanottava sähköpostipalvelin tekee DKIM-tarkistuksen viestin otsaketietojen ”DKIM-signature”-kentän d- ja s-tunnisteiden perusteella. Palvelin siis tarkistaa viestin al- lekirjoittaneen tahon toimialuenimen ja käytetyn valitsimen. Vastaanottava palvelin vertaa sitten tietoja kyseisen toimialuenimen DKIM-tekstitietueeseen. Vastaanottaja noutaa tietueesta lähettäjän julkisen avaimen, jota se käyttää viestin otsaketietojen ja sisältöosan allekirjoitusten varmentamiseen. Jos laskelmat täsmäävät, viestin allekirjoitus katsotaan aidoksi. (IETF 2011a, 43-49.)

DKIM lisää sähköpostin kulun luotettavuutta varsinkin tilanteissa, joissa viesti lähetetään edelleen välillisen sähköpostipalvelimen kautta. Tällöin pelkkä SPF ei tule riittämään, kuten aiemmassa luvussa 6.1.2 kuvattiin. Kuvassa 8 esitetään, mitä käy DKIM-tarkistukselle vastaavassa tilanteessa. Kuvan harmaat laatikot esittävät sähköpostipalvelimia, joiden kautta viesti kulkee. Niiden väliset tavalliset nuolet kuvaavat viestin kulkua palvelimien vä- lillä. Pistemäiset katkoviivat esittävät nimipalvelukyselyitä, joita vastaanottavat palvelimet tekevät DKIM-allekirjoituksessa mainitun toimialuenimen nimipalveluun. Siniset pistemäi- set katkoviivat kuvaavat sähköpostiviestien ja niiden allekirjoituksien välistä suhdetta. Viestin allekirjoitus säilyy samana koko postin kulkeman matkan ajan. Siniset laatikot esit- tävät lähettäjätoimialueen nimipalvelutietueita, joita vastaanottavat palvelimet tarvitsevat suorittamiinsa SPF- ja DKIM-tarkistuksiin. Tarkistukset näkyvät kuvassa joko vihreällä tai punaisella taustalla riippuen siitä, mitkä niiden tulokset ovat.

Kuva 8. Välillisen sähköpostipalvelimen edelleen lähettämälle viestille suoritettujen SPF- ja DKIM-tarkistusten tulokset (mukaillen Microsoft 2019g)

Kuvassa 8 example.net-toimialueelta lähetetty viesti on allekirjoitettu heidän yksityisellä avaimellaan. Välillinen sähköpostipalvelin mapy.fi vastaanottaa viestin, joka läpäisee sille suoritetut SPF- ja DKIM-tarkistukset. Tarkistusten tulokset näkyvät keskimmäisen palvelimen kohdalla vihreillä taustoilla. SPF-tarkistus läpäistään samoin perustein kuin opinnäy- tetyön luvun 6.1.2 kuvassa 6. DKIM-tarkistus onnistuu myös, sillä mapy.fi vahvistaa viestin allekirjoituksen aitouden example.net-toimialueen DKIM-tietueessa määritellyllä julkisella avaimella. Julkinen avain näkyy lihavoituna kuvan vasemmassa yläreunassa sinisellä taustalla. Viestin vastaanottava palvelin tietää etsiä oikeaa julkista avainta example.net- toimialueen nimipalvelutietueista, sillä kyseinen toimialuenimi on määritetty sähköposti- viestin allekirjoituksen d-tunnisteessa. Kyseisen tunnisteen määrittelemä toimialuenimi nä- kyy kuvassa lihavoituna allekirjoitusten yläpuolella.

Viesti lähetetään edelleen example.com-toimialueen palvelimelle, jossa SPF-tarkistus epäonnistuu, mikä selviää kuvassa punaisella taustalla. Epäonnistumisen syy on kuvattu luvussa 6.1.2 kuvassa 6. DKIM-tarkistus sen sijaan menee taas läpi, sillä viestin allekirjoitus ei ole muuttunut koko matkan aikana. Example.com-toimialueen palvelin todentaa allekirjoituksen aidoksi example.net-toimialueen nimipalvelun DKIM-tekstitietueessa määri- tellyllä julkisella avaimella samoin, kuten edellinen palvelin teki.

DKIM-tarkistus johtaa tyypillisimmin johonkin taulukon 3 esittämistä tuloksista.

Taulukko 3. DKIM-tarkistusten tulokset (Return Path 2019b) Tulos Selitys Pass Viesti on allekirjoitettu, ja allekirjoitus on tarkistuksessa vahvistettu aidoksi. Fail Viesti on allekirjoitettu, mutta allekirjoitusta ei vahvistettu tarkistuksessa aidoksi (esimerkiksi, jos viestiä on muokattu matkan varrella). None Viestiä ei ole allekirjoitettu, joten tarkistusta ei voida tehdä. Policy Viesti on allekirjoitettu, mutta allekirjoitus ei ollut hyväksyttävä sähköposti- palvelimen toimesta (esimerkiksi, jos avain on liian lyhyt (alle 1024 bittiä)). Neutral Viestin allekirjoituksen olemassaoloa tai aitoutta ei voida vahvistaa (esimerkiksi, jos allekirjoitukset sisälsivät syntaksivirheitä).

DKIM ei yksinään tee sähköpostin vastaanottamisesta turvallista, sillä hyökkääjä voi lisätä lähettämänsä sähköpostiviestin otsaketietoihin aidon DKIM-allekirjoituksen, jonka d-tunnisteen arvo osoittaa hyökkääjän omalle toimialueelle. Tällöin allekirjoitus tulkitaan aidoksi, ja viesti läpäisee DKIM-tarkistuksen. Hyökkääjä voi silti väärentää viestin otsaketietojen ”From”-kentän sähköpostiosoitteen. Tällöin loppukäyttäjä luulee saaneensa viestin luotettavalta lähettäjältä, vaikka viestin allekirjoitus kuuluu hyökkääjän toimialueelle. DKIM ei ota kantaa siihen, mitä vastaanottajan tulisi tehdä viestille, jos sen allekirjoitusta ei voida varmentaa. Viestin hylkääminen pelkästään allekirjoituksen puuttumisen tai tarkistuksen epäonnistumisen vuoksi katsotaan haitalliseksi yhteensopivuusongelmien takia (IETF 2011a, 50). DKIM ei myöskään ota kantaa siihen, mitä viestille tulisi tehdä, jos sen allekirjoittaja ei vastaa otsaketietojen ”From”-kentän toimialueen kanssa. Siihen tarkoitukseen on DMARC. (Whalen 2018.)

6.4 Domain-based Message Authentication, Reporting & Conformance (DMARC)

DMARC on sähköpostien todennuskäytäntö ja raportointityökalu. Se toimii yhdessä SPF- ja DKIM-tekniikoiden kanssa sähköpostiviestien lähettäjän todentamiseksi sekä suojaa organisaatiota osoitteiden väärentämis- ja tietojenkalasteluyrityksiä vastaan. DMARC kertoo vastaanottavalle sähköpostipalvelimelle, mitä sen tulee tehdä, jos SPF- ja DKIM-varmen- nukset eivät onnistu. (Zoner 2016.)

DMARC määritellään organisaation toimialuenimen tekstitietueeseen nimipalvelun tasolla. DMARC-määritykset talletetaan ”_dmarc”-alkuisen alitoimialueen tietueeseen. Esimer- kiksi, jos yrityksen nimi on ”example.net”, sen DMARC-tietue määritellään alitoimialueen ”_dmarc.example.net” tekstitietueena. (IETF 2015a, 16.)

6.4.1 DMARC-tietueen tunnisteet

DMARC-tietue jakautuu alla olevan esimerkin 11 mukaisesti useisiin tunnisteisiin DKIM- tietueiden tavoin (IETF 2015a, 16). Tässä luvussa käydään läpi oleellisimmat tunnisteet. Loput vapaaehtoiset mutta hyödylliset tunnisteet löytyvät opinnäytetyön liitteestä 4.

_dmarc.example.net. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Esimerkki 11. Tyypillinen nimipalvelun DMARC-tekstitietue

v: Käytetyn DMARC-tekniikan versio. Nykyinen käytettävä versio on 1, jolloin arvon tulee olla ”DMARC1”. Pakollinen tunniste. (IETF 2015a, 20.)

p: Toivottu viestin vastaanottokäytäntö. Kertoo, mitä vastaanottajan tulisi tehdä viestillä, jos se läpäisee DMARC-tarkistuksen. Mahdolliset arvot ovat ”none”, ”quarantine” ja ”reject”, joiden kuvaukset on esitetty luvun 6.4.2 taulukossa 4. Pakollinen tunniste. (IETF 2015a, 18.)

adkim: Kertoo, mitä vastaavuustilaa käytetään, kun DMARC testaa DKIM- tarkistuksen yhteydessä havaitun identiteetin, eli ”DKIM-signature”-kentän d- tunnisteen toimialuenimen, vastaavuutta sähköpostiviestin otsaketietojen ”From”-kentän osoitteeseen. Vastaavuustila kertoo, miten tarkasti toimialuenimien tulee vastata toisiaan. Arvot voivat olla ”r” eli ”relaxed” tai ”s” eli ”strict”. ”Strict”-tilassa toimialuenimien tulee vastata identtisesti. ”Rela- xed”-tilassa ei vaadita FQDN-osoitetarkkuutta, eli esimerkiksi DKIM-allekirjoituksen toimialuenimi ”example.net” olisi riittävän tarkka vastatakseen kirjekuoren ”MAIL FROM”-osoitetta ”[email protected]”. Vapaaehtoi- nen tunniste. (IETF 2015a, 17.)

aspf: Kertoo, mitä vastaavuustilaa käytetään, kun DMARC testaa SPF-tarkistuksen yhteydessä havaitun identiteetin, eli viestin kirjekuoren ”MAIL FROM”-osoitteen, vastaavuutta sähköpostiviestin otsaketietojen ”From”-ken- tän osoitteeseen. Vastaavuustila kertoo, miten tarkasti osoitteiden toimialuenimien tulee vastata toisiinsa. Arvot voivat olla adkim-tunnisteen tavoin ”relaxed” tai ”strict”. ”Strict”-tilassa toimialuenimien tulee vastata identtisesti. ”Relaxed”-tilassa ei vaadita FQDN-osoitetarkkuutta. Vapaaehtoinen tunniste. (IETF 2015a, 17.)

6.4.2 DMARC-tarkistus

Viestin vastaanottava sähköpostipalvelin reagoi vastaanottamaansa sähköpostiviestiin lä- hettäjän toimialuenimen DMARC-tekstitietueessa määritellyllä tavalla. Sähköpostipalvelin tekee tarkistuksen SMTP-yhteyden aikana ennen vastaustaan SMTP-asiakasohjelman antamaan ”DATA”-komentoon (luku 3.3 kuva 3). Olettaen, että vastaanottava palvelin on määritelty tekemään SPF- ja DKIM-tarkistukset saapuvassa liikenteessä, se tekee ensim- mäisenä SPF-tarkistuksen, jonka jälkeen se tarkistaa DKIM-allekirjoitukset. (IETF 2015a, 63.)

Molempien tarkistusten jälkeen vastaanottava palvelin tarkistaa vielä SPF- ja DKIM-tarkistuksissa esiintyneiden toimialuenimien vastaavuuden viestin otsaketietojen ”From”-kentän osoitteeseen. Se siis katsoo, että viestin kirjekuoren ”MAIL FROM”-osoitteen ja otsaketietojen ”DKIM-signature”-kentän d-tunnisteen toimialuenimet vastaavat otsaketietojen ”From”-kentän osoitteen toimialuenimeä. Toimialuenimien vastaavuuden tarkkuusvaati- mukset on määritelty DMARC-tietueen adkim- ja aspf-tunnisteissa. Jos toimialueet täs- määvät, palvelin katsoo lähettävän toimialueen nimipalvelusta DMARC-tietueen mukaisen vastaanottokäytännön ja vastaanottaa sähköpostiviestin sen mukaisesti. (IETF 2015a, 8- 10.)

Kuvan 9 esimerkissä vihreällä ja keltaisella taustalla näkyvien tummanharmaiden laatikoi- den mukaiset lihavoidut identiteetit läpäisevät SPF- ja DKIM-tarkistukset. Tarkistukset lä- päistään example.net-toimialueen julkaisemien SPF- ja DKIM-tietueiden perusteella, jotka näkyvät vaalean harmaissa pyöristetyissä laatikoissa vihreällä ja keltaisella taustalla. Tar- kistuksen onnistuminen perustuu opinnäytetyön luvuissa 6.1 ja 6.3 esitettyihin periaattei- siin. Viimeisenä suoritetaan DMARC-tarkistus, joka näkyy kuvassa sinisellä taustalla. DMARC-tarkistuksessa SPF- ja DKIM-tarkistuksissa käytetyt identiteetit eivät vastaa säh- köpostiviestin otsakkeen ”From”-kentän toimialuenimeen, joka näkyy kuvassa lihavoituna punaisella. Tällöin DMARC-tarkistus ei mene läpi, jolloin DMARC-tietueessa määritelty lihavoitu ”p=reject” käytäntö otetaan käyttöön, ja vastaanottaja hylkää viestin. (IETF 2015a, 63.)

Kuva 9. DMARC-tarkistuksen toimintaperiaate (mukaillen Barracuda 2019)

Jos taas tarkistetut identiteetit vastaisivat ”From”-kentän osoitteen toimialueeseen, käytän- töä ei otettaisi käyttöön, ja viesti sallittaisiin. Riittäisi myös, että edes toisen tekniikan lä- hettäjän identiteetti vastaisi ”From”-osoitteen toimialuenimeen. DMARC vaatii ainoastaan yhden vastaavuuden tarkistuksen läpäisyyn. (IETF 2015a, 24.)

DMARC-tarkistus johtaa johonkin taulukon 4 mukaisista toimenpiteistä. Vastaanottavan palvelimen tapa käsitellä viestiä perustuu lähettäjän toimialueen DMARC-tietueessa mää- ritellyn p-tunnisteen mukaiseen käytäntöön.

Taulukko 4. Toimenpiteet, joilla sähköpostiviesti voidaan käsitellä DMARC-tietueessa määritellyn käytännön perusteella (IETF 2015a, 18; Kovachev 2019a) Käytäntö Selitys Toimenpide p=none Toimialuenimen omistaja ei ole Sähköpostiviesti vastaanotetaan esittänyt toivottua toimenpidettä aina. vastaanotettaville viesteille. p=quarantine Toimialuenimen omistaja haluaa, Sähköposti vastaanotetaan, mutta että vastaanotettavat viestit käsi- se laitetaan karanteeniin, jos se ei tellään epäilyttävinä, jos ne eivät läpäise DMARC-tarkistusta. Tällöin läpäise DMARC-tarkistusta. viesti päätyy tyypillisesti loppukäyt- täjän roskapostikansioon. p=reject Toimialuenimen omistaja haluaa, Yhteys lähettävään sähköpostipal- että vastaanottaja hylkää viestit, velimeen katkaistaan ja sähköposti jotka eivät läpäise DMARC-tarkis- hylätään, jos DMARC-tarkistus tusta. epäonnistuu.

6.4.3 DMARC-tekniikan käyttöönoton hyvät käytänteet

Suosituksena on käyttää sekä SPF- että DKIM-tekniikoita yhdessä DMARC:in kanssa. DMARC ei vaadi molempia, mutta molempien tekniikoiden käyttö nostaa postin läpimene- misen todennäköisyyksiä. Vähintään raportointiominaisuuksien käyttöönotto on aina suositeltavaa alkuvaiheissa. (DMARC 2017.)

Raportointiominaisuuksien käyttö helpottaa ymmärtämään oman organisaation sähköpos- tiliikenteen kulkua. Yritysten tulisi ensin analysoida DMARC-kokoomaraportit, jotta tiede- tään, kuinka iso osa organisaation sähköposteista kulkee yhdyskäytävinä toimivien siirto- ohjelmien kautta. Esimerkiksi SPF toimii yksinään huonosti DMARC:in kanssa, jos viestit lähetetään eteenpäin välillisten sähköpostipalvelimien kautta. Tuolloin lopullinen vastaanottava palvelin tekee SPF-tarkistuksen välillisen palvelimen IP-osoitteesta, mikä ei taas vastaa viestin lähettäneen toimialueen nimipalvelun SPF-tietueiden sallimiin palvelimiin. SPF-tarkistus epäonnistuu, mikä johtaa viestin hylkäämiseen, jos DMARC on määritelty ”p=reject”-käytännöllä. (DMARC 2017.)

DMARC-tekniikkaa käyttöönotettaessa kannattaa siksi aina ensin asettaa vastaanottokäy- tännöksi ”p=none”, jolloin DMARC-tarkistuksen epäonnistuminen ei johda sähköpostin hyl- käämiseen. Sitten raporttien huolellisen seurannan perusteella tehdään päätös käytännön muuttamisesta, mikä ei välttämättä ole hyvä päätös, jos suuri osa posteista lähetetään edelleen välillisten palvelimien kautta. Muuten käytännöksi voidaan asettaa ”p=reject” tai ”p=quarantine”. Raportointiominaisuudet saadaan otettua käyttöön lisäämällä DMARC- tekstitietueeseen opinnäytetyön liitteessä 4 määritellyt ”rua”- ja ”ruf”-tunnisteet. (DMARC 2017.)

Tilannetta voidaan parantaa ottamalla SPF-tekniikan lisäksi käyttöön DKIM, joka selviää todennäköisemmin DMARC-tarkistuksesta myös yllä esitetyissä tilanteissa. DKIM voi myös epäonnistua, jos viestiä on esimerkiksi matkan varrella muokattu liikaa viestin otsaketietojen ”DKIM-signature”-kentän määrityksien rajoituksista huolimatta. Tällöin DMARC-tarkistus epäonnistuu sekä SPF- että DKIM-tarkistusten epäonnistuessa. Molem- pien tekniikoiden käyttäminen DMARC-tekniikan kanssa on huomattavasti parempi vaihtoehto kuin vain yhden, sillä yhden osoitteen vastaamattomuus ei estä postin kulkua. (DMARC 2017.)

6.5 Authenticated Received Chain (ARC)

ARC on uusi protokolla, joka on tällä hetkellä IETF-organisaation kokeellisena luonnoksena. Se sai RFC 8617 -standardinumeronsa vasta heinäkuussa 2019 (IETF 2019c). Ko- keellisuudestaan huolimatta Google on jo ottanut ARC-protokollan käyttöön G Suite- ja Gmail -sähköpostipalveluissaan. (ARC Specification for Email 2019a.)

Tietyt sähköpostin todennuskeinot toimivat huonosti esimerkiksi postituslistojen ja välillis- ten edelleen lähettävien sähköpostipalvelimien kanssa, jolloin aito sähköpostiviesti saate- taan hylätä käytetyn tarkistuksen, kuten SPF:n perusteella. ARC-protokolla pyrkii ratkaise- maan nämä ongelmat säilyttämällä kaikki sähköpostiviestin todentamisen tulokset koko postin kulun ajan. Tällöin lopullinen vastaanottava sähköpostipalvelin voi vielä arvioida ARC-tulokset ja tehdä niiden pohjalta poikkeuksen tilanteissa, joissa muut tarkistukset olisivat hylänneet viestin. (ARC Specification for Email 2019a.)

Periaatteessa ARC sallii yksittäisten sähköpostipalvelimien lisätä niiden tekemien tarkistuksien tulokset sähköpostiviestin otsaketietoihin (IETF 2018b, 4). ARC-protokollaa hyö- dyntävät sähköpostipalvelimet toimivat kahdessa eri roolissa. Palvelin toimii ARC-vahvis- tajana vastaanottaessaan viestiä ja lähettäessään se toimii ARC-sinetöijänä. (IETF 2018b, 13.)

6.5.1 ARC-sarjojen otsakekentät

Sinetöijä lisää sähköpostiviestin otsaketietoihin ARC-sarjan, joka sisältää kolme uutta kenttää, joista puhutaan tyypillisimmin niiden lyhenteillä AAR, AMS ja AS. Kentät lisätään otsaketietoihin DKIM-allekirjoitusten tavoin. Jokaiselle sarjan kentälle annetaan sama tapaustunniste. Jos otsaketiedoista ei jo ennestään löydy yhtään ARC-sarjaa, tunnisteen arvo on ”1”. Muuten etsitään tunniste, jolla on suurin arvo, ja käytetään uudessa sarjassa tunnisteena arvoa, joka on yhden edellistä suurempi. (IETF 2018b, 14.)

ARC-Authentication-Results: AAR-kenttä, johon kirjataan tapaustunniste ja palvelimen suorittamien SPF-, DKIM- ja DMARC-tarkistusten tulokset, kun viesti vastaanotetaan. AAR-kenttiin talletetaan siis suoritettujen tarkistusten historia, jotta myöhemmät vastaanottajat näkevät, mitkä tarkistukset ovat onnistuneet tai epäonnistuneet aiemmilla palvelimilla, joiden kautta viesti on saapunut. (IETF 2018b, 9.)

ARC-Message-Signature: AMS-kenttä, johon kirjataan tapaustunniste ja DKIM-tyylinen allekirjoitus koko sähköpostiviestistä ARC-sarjoja lukuun ottamatta (IETF 2018b, 9).

ARC-Seal: AS-Kenttä, johon kirjataan tapaustunniste ja DKIM-tyylinen allekirjoitus aiemmista ARC-sarjoista. Pitää sisällään myös cv-tunnisteen, joka kertoo nykyisen ARC-ketjun tarkistuksen lopputuloksen. Ketju muodostuu viestin kaikista ARC-sarjoista (Kovachev 2019b). Cv-tunnisteen arvo johtaa johonkin taulukon 5 esittämistä tuloksista. AS-kenttä mahdollistaa sen, että myöhemmät vahvistajat voivat tarkastaa aiempien sinetöijien arviot viestin todennuksesta. (IETF 2018b, 10.)

Taulukko 5. AS-kentän cv-tunnisteen arvot ja niiden selitykset (Kovachev 2019b) Arvo Selitys none Otsaketiedoista ei löytynyt arvioitavaa ARC-ketjua. pass ARC-ketjun arviointi onnistui. fail ARC-ketjun arviointi epäonnistui.

6.5.2 ARC-tarkistus

Viestin seuraavaksi vastaanottava vahvistaja tekee viestille vähintään kuusiosaisen ARC- tarkistuksen, joka voi epäonnistua aina kussakin vaiheessa. Jokainen kohta tulee läpäistä, jotta tarkistus menee läpi. Jos edes yksi tarkistuksen vaiheista epäonnistuu, vastaanottaja merkitsee oman AS-kenttänsä cv-tunnisteen arvoksi ”fail”, ja koko tarkistus päättyy. ARC- ketjussa ei saa olla yhdenkään cv-tunnisteen arvona ”fail”, jotta tarkistus voidaan suorittaa loppuun. (IETF 2018b, 16-17.)

Kuvasta 10 nähdään esimerkki ARC-tarkistuksen vaiheista. Kuvan vasemmalla puolella näkyy viestin otsaketiedot, jotka sisältävät kolmesta ARC-sarjasta muodostuvan ARC-ketjun. Kukin sarja pitää sisällään ARC-protokollalle ominaiset kolme otsaketietokenttää. Ylimmäisin vihreällä kuvattu sarja on tarkistusta tekevän vahvistajan lisäämä. Tarkistuk- sessa selvitetään arvo vahvistajan itse kirjaamalle cv-tunnisteelle, joka näkyy vahvistajan AS-kentässä oranssilla. Kuvan oikealla puolella näkyy ARC-vahvistajan tekemät tarkistus- vaiheet ja niiden toimintalogiikat. Vahvistaja käy läpi kuusi tarkistusvaihetta, jotka voivat kaikki johtaa cv-tunnisteelle annettavaan arvoon ”fail”. Jos siis yksikin tarkistusvaihe epä- onnistuu, vahvistajan oman cv-tunnisteen arvoksi annetaan ”fail”, ja tarkistus päättyy. Jos taas vaiheen tarkistus onnistuu, siirrytään seuraavaan tarkistusvaiheeseen, kunnes pääs- tään kuvan esittämään vaiheeseen 6, jossa tunnisteen arvoksi annetaan ”pass”.

Kuva 10. ARC-tarkistuksen tyypilliset vaiheet ARC-vahvistajalla

ARC-vahvistaja suorittaa kuvassa 10 seuraavat toimenpiteet:

1. Ensimmäisessä vaiheessa ARC-vahvistaja vastaanottaa viestin ja tarkistaa viestin otsaketiedoista kaikki ARC-sarjat. Jos niitä ei olisi, AS-kentän cv-tunnisteen arvoksi an- nettaisi ”none”, ja koko tarkistus päättyisi. Vahvistaja tarkistaa myös sarjojen lukumää- rän, jotteivat ne ylitä protokollassa sallittua määrää 50, mikä johtaisi cv-arvoon ”fail” ja tarkistuksen päättymiseen. Kuvassa sarjojen lukumäärä ei ylitä sallittua, minkä vuoksi tarkistusvaihe läpäistään ja siirrytään seuraavaan vaiheeseen. (IETF 2018b, 17-18.)

2. Vahvistaja etsii ARC-ketjusta sen sarjan, jolla on suurin tapaustunniste (viimeisimmän palvelimen lisäämä sarja). Kuvassa kyseinen sarja näkyy ketjun keskellä tapaustun- nisteella i=2, sillä vihreällä merkitty sarja kuvaa vahvistajan lisäämää sarjaa tarkistuksen päättyessä. Sarjan cv-tunniste tarkistetaan. Jos sen arvo olisi ”fail”, vahvistaja kat- soisi myös oman cv-tunnisteensa (kuvassa oranssilla) arvoksi ”fail”, ja tarkistus päät- tyisi. Kuvassa arvo on ”pass”, joten tarkistusvaihe läpäistään ja siirrytään seuraavaan vaiheeseen. (IETF 2018b, 17-18.)

3. Vahvistaja tarkistaa, että ketjun rakenne on protokollan määritelmien mukainen. Se tarkistaa esimerkiksi, että jokaisesta sarjasta löytyy vaadittavat kolme otsakekenttää. Aiempien sarjojen cv-tunnisteista ei myöskään saa löytyä ”fail”-arvoa. Lisäksi sarjojen tapaustunnisteiden tulee olla nousevassa järjestyksessä alkaen numerosta 1, jonka

cv-tunnisteen arvona tulee olla ”none”. Jos vaatimukset eivät täyttyisi, vahvistajan oman cv-tunnisteen arvoksi annettaisiin ”fail”, ja tarkistus päättyisi. Kuvassa kaikki vaatimukset täyttyvät, joten tarkistusvaihe läpäistään ja siirrytään seuraavaan vaiheeseen. (IETF 2018b, 17-18.)

4. Vahvistaja tarkistaa suurimman tapaustunnisteen omaavan sarjan AMS-kentän (i=2 - sarja, sillä ensimmäinen kuvaa vahvistajan lisäämää sarjaa). Jos kentän tarkistus epä- onnistuisi, annettaisiin vahvistajan cv-tunnisteelle arvo ”fail”, ja tarkistus päättyisi. Ku- vasta ei selviä kaikki AMS-kentän yksityiskohdat, mutta kenttä noudattaa pääasiassa DKIM-allekirjoituksien tunnisteita. AMS-kentästä voidaan siis todentaa allekirjoittaja- taho ja allekirjoituksen aitous. Kuvassa kentän tarkistus onnistuu, joten tarkistusvaihe läpäistään ja siirrytään seuraavaan vaiheeseen. (IETF 2018b, 17-18.)

5. Vahvistaja tarkistaa kaikkien aiempien sarjojen AS-kentät tapaustunnistejärjestyk- sessä suurimmasta pienimpään. Jos yhdenkin AS-kentän tarkistus epäonnistuu, annetaan vahvistajan cv-tunnisteelle arvo ”fail”, ja koko tarkistus päättyy. Kuvasta ei selviä kaikki AMS-kenttien yksityiskohdat, mutta kentät noudattavat pääasiassa DKIM-allekirjoituksien tunnisteita. Kuvassa kenttien tarkistukset onnistuvat, joten tarkistusvaihe lä- päistään ja siirrytään seuraavaan vaiheeseen. (IETF 2018b, 17-18.)

6. ARC-tarkistus läpäistään, sillä kaikki edelliset vaiheet läpäistiin ilman, että vahvistajan omalle cv-tunnisteelle jouduttiin asettamaan arvo ”fail”. Vahvistaja antaa otsaketietoihin lisäämälleen cv-tunnisteelle arvon ”pass”. (IETF 2018b, 17-18.)

ARC-ketjun tarkistamisen pohjalta vastaanottava palvelin voi tehdä päätelmiä sähköposti- viestin luotettavuudesta, vaikka palvelimen oma DMARC-tarkistus olisi epäonnistunut. Vastaanottaja voi sitten käyttää ARC-ketjun tietoja oman DMARC-käytäntönsä ohittami- seen. Esimerkiksi ”p=reject”-käytännön julkaisemalta toimialueelta vastaanotetut viestit normaalisti hylättäisiin DMARC-tarkistuksen epäonnistuessa. ARC mahdollistaa kyseisten viestien vastaanottamisen, jos vastaanottava sähköpostipalvelin kokee ARC-ketjun tarkis- tustulokset luotettaviksi. (IETF 2018b, 20-21.)

7 Aiemmat tutkimukset

Yritysten käyttämiä roskapostin torjuntakeinoja on tutkittu vuonna 2006 Oulun yliopiston ja Georgian osavaltion yliopiston yhteisessä tutkimuksessa. Siinä selvitettiin suomalaisten ja yhdysvaltalaisten yritysten käyttämien roskapostin torjuntatekniikoiden tehokkuutta sekä roskapostin vaikutuksia yritysten toimintaan. (Siponen & Stucke 2006.)

Kyselylomake lähetettiin 500 suurimman yhdysvaltalaisen ja suomalaisen yrityksen IT- päälliköille. Lopulta tutkimukseen vastasi Suomessa hieman yli sata yritystä noin 20 prosentin vastausasteella ja Yhdysvalloissa yli 40 yritystä noin yhdeksän prosentin vastausasteella. Siposen ja Stucken tutkimusta ei toteutettu anonyymisti, eli yrityksen vastasivat omalla nimellään, mikä tutkijoiden arvioiden mukaan vaikutti erityisesti yhdysvaltalaisten vastausasteeseen. Data kerättiin vuonna 2004 ja sen kerääminen kesti 10 kuukautta. (Si- ponen & Stucke 2006, 1.)

Tutkimuksen tuloksista havaittiin, että keskimäärin yli 80 % yrityksen sisäänpäin suuntau- tuvasta sähköpostiliikenteestä oli roskapostia. Roskapostin käsittely vei keskimäärin melkein 15 minuuttia vastaajien tavallisesta työpäivästä. Merkittävä osa vastaajista koki roskapostin määrän kasvaneen aiemmista vuosista. Enemmistö myös epäili roskapostien tuottavan enemmän ongelmia tulevaisuudessa kuin he kokivat niiden tuottavan kyselyn vastaushetkellä. 20 yritystä ei kokenut roskapostia suureksi ongelmaksi tehokkaiden roskapostin suodatustekniikoiden vuoksi. (Siponen & Stucke 2006, 2-5.)

Yleisimmin käytettyjä torjuntatekniikoita olivat erilaiset suodattimet, joita käytti lähes 75 % vastaajista. Mustalistausta käytti vastaajista yli 60 %, valkolistausta noin 30 % ja muita keinoja noin 20 %. Sähköpostipalvelimien ylläpitäjän näkökulmasta muita keinoja ei ollut suodatuksen ja musta-/valkolistauksen ohella. Roskapostin torjunta huomioitiin muilla keinoin. Sähköpostiosoitteet esimerkiksi esitettiin verkkosivuilla sellaisessa muodossa, ettei- vät automaattiset roskapostittajat kykene niitä hyödyntämään. Muita keinoja oli muun muassa vetoaminen suoraan roskapostittajiin tai internetpalveluntarjoajaan. Merkittävä osa vastaajista siirsi myös vastuuta roskapostin torjunnasta loppukäyttäjille. (Siponen & Stucke 2006, 6.)

Tutkimuksen tuloksia tarkasteltaessa on selvää, ettei nykyään käytettyjä roskapostin torjuntatekniikoita ollut vielä keksitty tai käyttöönotettu vuonna 2004, jolloin kysely toteutettiin. Vastaajista lähes kymmenen oli sitä mieltä, että sähköpostin teknistä infrastruktuuria tulisi kehittää. Eräs tutkimukseen osallistunut suomalainen vastaaja näki SMTP-protokol-

53 lan isona ongelmana, ja muutamat vastaajat ehdottivat lähettäjän todentamisen mahdollis- tavien tekniikoiden kehittämistä ja käyttöönottoa (Siponen & Stucke 2006, 8). Lähettäjän todentaminen onkin sittemmin mahdollistettu esimerkiksi SPF- ja DMARC-tekniikoiden myötä, jotka IETF määritteli ensimmäisen kerran vuosina 2006 ja 2015 (IETF 2006a; IETF 2015a).

Suomalaisten yritysten roskapostin torjuntatekniikoita ei ole pahemmin tutkittu laajasti Si- posen ja Stucken tutkimusta lukuun ottamatta. Sundström haastatteli osana Pro Gradu - tutkielmaa Nokian sähköpostiturvallisuusvastaavaa (Sundström 2008, 38). Nokian alkupe- räisenä pääpainona oli ollut sähköpostien mukana leviävien virusten torjunta, mutta huo- mio siirtyi roskapostin torjuntaan vasta vuoden 2000 jälkeen. Tuolloin he käyttivät kaupallista sääntöpohjaista ja sisältöön perustuvaa suodatinta. Vuonna 2008 Nokia käytti pää- asiassa musta- ja valkolistausta roskapostin suodatukseen. Sisäänpäin suuntautuvien sähköpostien määrää samasta lähteestä rajoitettiin myös tiettyyn lukumäärään minuu- tissa, jonka jälkeen rajan ylittänyt lähettäjä estettiin väliaikaisesti. Lopuksi viestit tarkastet- tiin vielä Cloudmarkin sääntöpohjaisella suodattimella, joka hyödynsi osittain SpamAssas- sin-ohjelman ominaisuuksia. Edellisten ohella Nokia käytti erään palvelutarjoajan pilvipohjaista tarkistenumerosuodatinta ja viittä eri kaupallista sisältöön perustuvaa suodatusme- netelmää. Haastateltava sähköpostiturvallisuusvastaava ei tarkentanut suodatusmenetel- mien teknistä toimintaa, mutta roskapostien piti läpäistä kaikki viisi suodatinta ennen viestin toimittamista loppukäyttäjälle. 96 prosenttia roskapostista eliminoitiin, ennen kuin ne päätyivät käyttäjän postilaatikkoon. Lisäksi kaikille ulospäin suuntautuville sähköpostivies- teille suoritettiin virustarkistus. (Sundström 2008, 39-40.)

Molemmat tutkimukset ovat yli kymmenen vuotta vanhoja, eikä niiden toteutushetkellä ollut käytössä monia nykyaikaisia torjuntakeinoja. Roskapostittajien käyttämät menetelmät ovat myös kehittyneet merkittävästi 2010-luvulla, mikä lisää tarvetta ajankohtaisille tutkimuksille.

8 Aineisto ja tutkimusmenetelmät

Tässä luvussa esitellään ne menetelmät ja työkalut, joita tutkimusaineiston keräämisessä ja käsittelyssä hyödynnettiin. Tutkimus toteutettiin kyselytutkimuksena, jossa oli sekä kvantitatiivisia että kvalitatiivisia kysymyksiä. Luvussa esitettyjen tietojen pohjalta lukija ymmärtänee, miten tutkimuksessa saadut tiedot kerättiin ja miten niitä käsiteltiin lopulliseen hyödynnettävään muotoon.

8.1 Aineiston keruu

Aineisto kerättiin 12.5.-9.6.2019 välisenä aikana. Tutkimuksen perusjoukkona toimivat suomalaiset IT-alan yritykset. Rajaus IT-alan yrityksiin tehtiin yritysten kartoituksen yksin- kertaistamiseksi. Tausta-ajatuksena oli, että IT-alan yrityksissä ylläpidetään opinnäytetyön aihealueen osalta korkeampia standardeja, mikä voisi kannustaa myös muita toimialoja sähköpostipalveluidensa kehittämiseen tutkimustuloksia hyödyntäessään. Lisäksi tutkimukseen osallistuminen saattaisi olla todennäköisempää saman alan asiantuntijoilta verrattuna toimialoihin, joiden työntekijät eivät tunne tutkimuksen aihepiiriä.

Tutkimuksen potentiaalisten osallistujien valinta perustui harkinnanvaraiseen näytteeseen, joka koostui 310 yrityksestä. Yritysten yhteystiedot kerättiin internetin hakukoneilla ja Ite Wikin yrityshaulla (Ite Wiki 2019). Yhteystiedoista luotiin kaksi Excel-taulukkoa, joissa osoitteet olivat jaoteltu eri taulukkotiedostoihin riippuen siitä, olivatko ne kohdistetun työn- tekijän vai asiakaspalvelun sähköpostiosoitteita. Alun perin yrityksiltä kerättiin myös yritysten vaihtoehtoiset sähköpostiosoitteet toista kyselyerää varten. Vaihtoehtoisia osoitteita ei lopulta käytetty, sillä huolena oli vastausten kaksoiskappaleiden muodostuminen, jos kyselylomake päätyy kahdelle eri työntekijälle samassa yrityksessä. Aihetta käsitellään tarkemmin opinnäytetyön luvussa 10.2.

Vastausvajeeseen varauduttiin toisella kyselyerällä, joka toteutettiin ensimmäisen kysely- erän päätyttyä. Toisen kyselyerän tarkoituksena oli muistuttaa vastaanottajia kyselyyn osallistumisesta. Lopullisena tavoitteena oli saada yhteensä vähintään 50 vastausta sekä vähintään 10 vastausta per yrityskoko. Tavoite ymmärrettiin vaikeaksi saavuttaa, sillä merkittävä osa näytteestä koostui pienikokoisista yrityksistä yritysten kartoituksen aikana tehtyjen ennakkopäätelmien perusteella. Lopulliseksi realistiseksi osallistujamääräksi odo- tettiin noin 10 % kaikista vastaajista.

Kyselylomake toteutettiin Google Forms -työkalulla. Vastaukset linkitettiin Google Sheets - tiedostoon, jolloin kaikki data oli lopulta saatavissa valmiina taulukkotiedostona. Lomak- keesta luotiin yhteensä neljä eri versiota, joita kehitettiin ensimmäisestä versiosta lähtien

55 testikäyttäjien palautteen perusteella. Palautetta kerättiin kahdella suurella suomalaisella tietotekniikkafoorumilla. Lisäksi palautetta pyydettiin sähköpostin peruskäyttäjiltä sekä kahdelta kokeneelta IT-alan osaajalta. Palautteen vaikutus lomakkeen lopulliseen sisäl- töön oli merkittävää, vaikka palaute alkuperäiseen testilomakkeeseen oli pääosin positiivista. Muutoksilla saavutettiin paremmin muotoillut kysymykset, mikä lisäsi tutkimustulosten tarkkuutta.

Lopullisessa lomakkeessa oli kahdeksan pakollista kysymystä, joista seitsemän oli moni- valintakysymyksiä. Lomakkeen lopussa oli lisäksi kaksi vapaaehtoista vapaamuotoista ky- symystä. Vastaajille annettiin mahdollisuus muokata lähettämiään vastauksiaan jälkeen- päin. Vastauskertoja ei voitu rajoittaa yhteen kertaan per vastaaja, sillä se olisi edellyttänyt vastaajien sisäänkirjautumisen Google-tilillä, mikä taas oletettavasti olisi vähentänyt vastaajien määrää. Kyselylomakkeen kysymykset löytyvät raportin liitteestä 9.

Lomakkeen alussa määriteltiin tutkimuksen tarkoitus ja tavoitteet sekä annettiin tutkimuksen mukainen määritelmä roskapostista. Kysymyksistä ensimmäiset kaksi mittasivat yrityksen kokoa ja lomakkeeseen vastaavan henkilön roolia yrityksessä. Yrityskoissa käytet- tiin Tilastokeskuksen määritelmiä (Tilastokeskus 2019a & 2019b). Vastaajan rooli kysyt- tiin, koska sillä voidaan vahvasti olettaa olevan merkitystä vastausten tarkkuuteen. Esi- merkiksi IT-päälliköltä saataneen todennäköisemmin asiantuntevammat vastaukset, kuin toimitusjohtajalta.

Kysymykset kolme ja neljä mittasivat yrityksen tyytyväisyyttä heidän käyttämiensä sähkö- postijärjestelmien kykyyn suodattaa roskapostiliikennettä. Vastaukset annettiin asteikolla 1-5, joista yksi merkkasi tyytymätöntä ja viisi tyytyväistä. Kolmannessa kysymyksessä ha- luttiin tietää yrityksen tyytyväisyys oikeiden roskapostiviestien suodatukseen, kun taas nel- jännessä mitattiin tyytyväisyyttä järjestelmien kykyyn erotella aidot sähköpostiviestit roskapostista. Kysymykset olivat subjektiivisia ja täysin riippuvaisia vastaajan mielipiteestä.

Kysymyksissä 5-10 kartoitettiin teknisiä asioita. Viidennessä kysymyksessä selvitettiin, mihin palveluun yrityksen sisäiset sähköpostipalvelut perustuivat. Tiedon perusteella voidaan tehdä päätelmiä yrityksen varmasti käyttämistä roskapostin torjuntatekniikoista, sillä palvelut tyypillisesti sisältävät tiettyjä tekniikoita oletuksena. Tieto on oleellinen ainakin niiden vastaajien kohdalla, jotka eivät osaa antaa tarkempia tietoja myöhempiin kysymyksiin. Kuudennessa kysymyksessä selvitettiin niitä tekniikoita, joita yritys käyttää roskapostin torjuntaan sen lähteen tai sisällön perusteella. Kysymykset 7-8 keskittyivät viestin aitouden ja lähettäjän todentamiseen sisään- ja ulospäin suuntautuvassa liikenteessä. Kysy- myksissä 6-8 vastaajille annettiin monta vastausvaihtoehtoa kunkin luetellun tekniikan

56 kohdalla. Vaihtoehdot olivat: ”On käytössä”, ”Ei ole käytössä, mutta haluaisimme käyttää”, ”Ei ole käytössä, emmekä näe tarpeelliseksi”, ”En muista tai tiedä, käytämmekö” ja ”En tunne tätä tekniikkaa”. Tavoitteena oli saada tarkempia vastauksia sekä kerätä tietoa halu- tuista ja vähemmän tunnetuista tekniikoista.

Viimeiset kaksi kysymystä olivat vapaaehtoisia, ja ne antoivat vastaajalle mahdollisuuden ilmoittaa muista käyttämistään roskapostin torjuntatekniikoista, joita kyselylomakkeessa ei ollut ennestään tuotu esille. Lisäksi he pystyivät tuomaan esille sellaisia tekniikoita, joita he eivät vielä käyttäneet mutta haluaisivat käyttää tulevaisuudessa.

Yrityksiä lähestyttiin sähköpostitse. Vastaanottajille lähetettiin kahta erilaista viestiä riippuen siitä, olivatko he listanneet yritystensä verkkosivuilla IT-asioiden yhteyshenkilön. Yri- tysten IT-henkilöstölle kohdistetut viestit (liite 5) olivat sisällöltään hieman erilaisia kuin ne, jotka lähetettiin asiakaspalvelun tai -tuen osoitteisiin (liite 6). Asiakaspalveluun ja -tukeen lähetetyissä viesteissä vastaanottajaa pyydettiin ohjaamaan viesti yrityksen IT-vastaavalle henkilölle.

Ensimmäisen erän lomakelinkki lähetettiin sähköpostiviestillä vastaanottajille 12.5.2019 sunnuntai-iltana. Toisen erän lomakelinkki lähetettiin sähköpostitse kaksi viikkoa myöhem- min 26.5.2019. Tuolloin viestien sisällöt olivat hieman erilaiset, sillä tarkoituksena oli muistuttaa niitä tahoja, jotka eivät vielä mahdollisesti olleet vastanneet kyselyyn. Toisen erän viestipohjat löytyvät opinnäytetyön liitteistä 7 ja 8. Kyselyn anonyymin luonteen vuoksi tutkimukseen jo vastanneita yrityksiä ei pystytty poissulkemaan toisesta kyselyerästä. Poik- keuksena oli noin kymmenen yritystä, joiden kanssa erikseen käyty viestintä paljasti hei- dän vastanneen kyselytutkimukseen.

8.2 Aineiston käsittely

Vastauksia saatiin ensimmäisen vuorokauden aikana 44. Kyselytutkimuksen ensimmäi- nen erä kesti kaksi viikkoa, jonka aikana vastauksia oli kertynyt 54. Toisen erän ensim- mäisen vuorokauden aikana kyselyyn oli vastannut 12 yritystä. Toisen erän päätyttyä tutkimukseen oli vastannut 74 suomalaista IT-alan yritystä, mikä vastaa lähes 25 % osuutta lomakkeen kaikista vastaanottajista. Vastauksia kerättiin yhteensä kuukauden ajan.

Kyselytutkimuksen vastaukset oli linkitetty automaattisesti Google Sheets -työkalun tau- lukkotiedostoon, joka vietiin manuaalisesti Exceliin käsiteltäväksi. Data käsiteltiin Ex- celissä selkeämpään muotoon, jossa käytettiin värikoodistoa visuaalisena apuvälineenä.

Vastauksia muutettiin hieman luettavuuden ja yhteneväisyyden vuoksi ilman, että alkupe- räisten vastausten sisältöä muutettiin. Lisäksi datasta poistettiin turhat vastaukset vapaa- muotoisista kysymyksistä, jos niillä ei ollut arvoa tutkimustulosten kannalta.

Käsitelty tutkimusdata tallennettiin yhteen Excel-tiedostoon, joka koostui kuudesta taulukosta. Ensimmäisessä taulukossa kuvattiin ne menetelmät, joilla vastauksia tulkittiin. Siinä esitettiin käytännön esimerkkien avulla, miten lopullisiin tutkimustuloksiin päädyttiin kunkin tutkittavan aihealueen osalta. Toinen taulukko sisälsi kaikkien yritysten vastaukset yrityskoosta huolimatta, ja loput neljä taulukkoa sisälsivät vastaukset kullekin yrityskoolle. Jo- kaisen vastauksia sisältävän taulukon alkuun sisällytettiin yhteenveto, josta selvisi taulukon oleellisimmat tulokset kyseiselle yrityskoolle. Tätä kutsuttiin yrityskoon tyypillisim- mäksi vastaukseksi.

Yksittäiset vastaukset sijoitettiin taulukoissa omille riveilleen ja jokaiselle vastaukselle myönnettiin oma ID-tunniste. Tutkimuksen kysymykset muotoiltiin omiin sarakkeisiinsa. Kunkin sarakkeen vastauksista laskettiin joko keskiarvo tai tyyppivastaus riippuen vastauksen muodosta. Tekstipohjaisista vastauksista laskettiin tyyppivastaus eli yleisimmin esiintynyt vastaus, kun taas numeerisista vastauksista laskettiin keskiarvo. Tiedot talletet- tiin vastausten alapuolelle lihavoituna. Keskiarvot laskettiin Excelin keskiarvofunktiolla ja tyyppivastaukset mukaillulla funktiolla, joka laski funktiossa määritellyllä alueella yleisimmin esiintyneen vastauksen. Tarkemmat tiedot aineiston käsittelystä ja tulkinnasta löytyvät opinnäytetyön liitteestä 11.

9 Tulokset

Tässä luvussa käsitellään kyselytutkimuksen tuloksia. Tulokset on jaettu alalukuihin yrityskoon perusteella, jolloin vastausten vertailu vastaavan kokoisiin yrityksiin on helpompaa. Viimeisessä alaluvussa esitetään tulokset kokonaisuutena kaikkien yritysten osalta. Tutki- musdata on ladattavissa opinnäytetyön tekijän verkkosivuilta (Pyhäranta 2019).

Kunkin yrityskoon alaluvun alussa kuvataan yhteenveto käsitellyn yrityskoon tyypillisim- mästä vastauksesta. Vastaajat voivat verrata antamiaan vastauksia yhteenvedon tuloksiin, jolloin he tietävät, miten he vastasivat muihin yrityksiin verrattuna. Vastausten tulokset esitetään sellaisina, kuin tutkimukseen osallistuneet yritykset ovat ne antaneet. Tulok- sissa ei ole opinnäytetyön tekijän toimesta korjattu mahdollisia epätarkkuuksia tai virheelli- siä vastauksia, jotka ovat voineet olla seurausta vastaajan tiedon puutteesta tai epä- huomiosta. Kyseistä aihetta käsitellään tarkemmin opinnäytetyön pohdintaosiossa 10.2.

9.1 Mikroyritykset (1-9 henkilöä)

Tutkimukseen vastasi 29 henkilöä suomalaisista IT-alan mikroyrityksistä. Mikroyrityksellä viitataan yritykseen, joka työllistää 1-9 henkilöä. Vastauksista koottiin tyypillisin vastaus, joka koostui lomakekysymysten vastausten keskiarvoista ja tyyppivastauksista. Tyyppi- vastauksella tarkoitetaan vastauksissa useimmiten esiintynyttä arvoa. Taulukossa 6 on esitetty mikroyritysten tyypillisin vastaus.

Taulukko 6. Mikroyritysten tyypillisin vastaus Mikroyritysten tyypillisin vastaus: Yrityskoko: mikroyritykset (1-9 henkilöä) Vastaajien määrä: 29 Vastaajan rooli yrityksessä: toimitusjohtaja Yrityksen käyttämä sähköpostipalvelu: G Suite (Gmail) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4,4 b) olla merkitsemättä aitoja sähköpostiviestejä 3,8 roskapostiksi c) kokonaisuudessa 4,1 Roskapostin torjunta lähteen tai sisällön perusteella − palvelun oletustekniikoilla toteutettiin seuraavilla tekniikoilla: − sähköpostin sisällönsuoda- tuksella. Viestin aitouden ja lähettäjän todennus saapuvassa − palvelun oletustekniikoilla liikenteessä varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla. Verkkotunnuksien ja lähtevän sähköpostin todennuk- − palvelun oletustekniikoilla sen suojaus varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla.

Taulukosta 6 havaitaan, että mikroyritysten tyypillisin vastaaja oli yrityksen toimitusjohtaja. Vastaajayritys käytti tyypillisimmin Googlen G Suite -palvelua yrityksen sisäisiin sähköpos- tipalveluihin. Keskimääräinen tyytyväisyys palvelua käyttäneillä oli 4,1 asteikolla 1-5.

Tyypillinen vastaajayritys torjui roskapostia sen sisällön ja lähteen perusteella käyttä- määnsä palveluun oletuksena kuuluvilla tekniikoilla sekä sähköpostin sisällönsuodatuk- sella. Viestin aitous ja lähettäjän todennus varmistettiin saapuvassa liikenteessä käytetyn sähköpostipalvelun oletustekniikoilla ja SPF-tekniikalla. Verkkotunnukset ja lähtevän säh- köpostin todennuksen suojaus varmistettiin käytetyn sähköpostipalvelun oletustekniikoilla sekä SPF- ja DKIM-tekniikoilla.

9.1.1 Sähköpostipalveluiden käyttöosuudet mikroyrityksissä

Kuvassa 11 on esitetty eri sähköpostipalveluiden käyttöosuudet mikroyritysten vastauksista. Ympyräkaavion tummansininen sektori kuvaa Office 365 -palvelua, punainen G Suite -palvelua, keltainen itse ylläpidettyä Linux-pohjaista sähköpostipalvelua ja musta jotain muuta ennalta määrittelemätöntä sähköpostipalvelua.

Kuva 11. Mikroyritysten käyttämien sähköpostipalveluiden prosenttiosuudet vastauksista

G Suite-palvelun osuus mikroyritysten vastauksista oli lähes 40 %, kuten kuvasta 11 näh- dään. Itse ylläpidettyjä Windows-pohjaisia sähköpostipalveluja ei käyttänyt kukaan vastaajista. Muut vastausvaihtoehdot jakautuivat melko tasaisesti käyttäjien kesken 20 % mo- lemmille puolille. Pilvipalvelupohjaisten sähköpostipalvelujen osuus vastauksista oli lähes

70 %, jos mukaan lasketaan muut ennalta määrittelemättömät pilvipalvelupohjaiset sähkö- postipalvelut. Prosenttiluku sisältää vain kokonaan pilvitoteutuksena ylläpidetyt palvelut, eikä sekamuotoisia palvelutoteutuksia ole huomioitu prosenttiosuudessa.

9.1.2 Palvelukohtainen tyytyväisyys mikroyrityksissä

Vastaajien tyytyväisyyttä käytettyihin sähköpostipalveluihin mitattiin kahdella muuttujalla: tyytyväisyydellä järjestelmien kykyyn suodattaa oikeita roskapostiviestejä sekä järjestel- mien kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Tyytyväisyyttä kuvattiin asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Lopuksi molemmista vastauksista laskettiin kunkin sähköpostipalvelun tyytyväisyyden keskiarvo.

Kuvassa 12 on esitetty tyytyväisyyden keskiarvot mikroyritysten käyttämiin sähköpostipal- veluihin. Kaavion tummansininen palkki kuvaa vastaajien tyytyväisyyden keskiarvoa Office 365 -palveluun, punainen G Suite -palveluun, keltainen itse ylläpidettyyn Linux-pohjaiseen sähköpostipalveluun ja musta keskiarvoa johonkin muuhun ennalta määrittelemättömään sähköpostipalveluun. Vaalean- ja tummanharmaat palkit värillisten palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 12. Mikroyritysten tyytyväisyydet käytettyihin sähköpostipalveluihin

Kuvan 12 tiedoista nähdään, että tyytyväisyys oli keskimäärin suurinta Office 365 -käyttä- jien keskuudessa, mikä näkyy palvelun saamasta keskiarvosta 4,3. G Suite ja itse ylläpi- detyt Linux-pohjaiset sähköpostipalvelut saivat molemmat tyytyväisyyden keskiarvoikseen

4,1. Muita sähköpostiratkaisuja käyttäneet vastaajat kuvasivat tyytyväisyyttään keskiarvolla 3,3. Windows-pohjaisia sähköpostipalveluja ylläpitäviä vastaajia ei ollut, minkä vuoksi sen tyytyväisyyden keskiarvona näkyy palkkikaaviossa 0.

9.1.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyt- tömäärät mikroyrityksissä

Mikroyritykset suodattivat roskapostia sen lähteen tai sisällön perusteella yhdeksällä eri tekniikalla, joista tyypillisimmät näkyvät taulukosta 6. Kuvassa 13 on esitetty kaikkien kysyttyjen tekniikoiden käyttömäärät mikroyrityksissä. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 13. Mikroyritysten käyttämien torjuntatekniikoiden käyttömäärät viestin lähteeseen tai sisältöön perustuvassa torjunnassa

Kuvasta 13 nähdään, että mikroyritysten käytetyimpiä torjuntatekniikoita olivat palveluun kuuluvien oletustekniikoiden ohella sähköpostin sisällönsuodatus (14), bayesilainen suodatus (12) ja SMTP-liikenteen suodatus (11). Niitä käytti yhteensä yli kolmasosa vastaajista. Luetelluista tekniikoista ainoastaan palvelun oletustekniikat ja sähköpostin sisällön- suodatus päätyivät lopulta tyypillisimpään vastaukseen. Enemmistö vastaajista ilmoitti käyttävänsä näitä kahta tekniikkaa, kun taas muiden tekniikoiden kohdalla enemmistö ilmoitti, että he eivät käytä kysyttyjä torjuntatekniikoita.

Kuvasta 13 käy myös ilmi, että fyysisten (4) ja pilvipohjaisten roskapostisuodattimien (6) sekä nolisting-tekniikan (5) käyttö oli vastanneilla mikroyrityksillä vähäisintä. Huomionar- voista on, että pilvipohjainen roskapostisuodatus oli muotoiltu vastauksessa muotoon ”pilvipohjainen roskapostisuodatus eri palveluntarjoajalta”. Tämä siksi, että suuri osa vastaajien käyttämistä sähköpostipalveluista oli pilvipalvelupohjaisia, jolloin myös niihin oletuksena sisältyvä roskapostisuodatus on pilvipalvelupohjaista. Ne kuusi pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta käyttävää yritystä käytti tällöin oman sähköpostipal- velunsa lisäksi jonkin toisen palveluntarjoajan pilvipohjaista torjuntaratkaisua.

9.1.4 Todennukseen pyrkivien tekniikoiden käyttömäärät mikroyrityksissä

Todennukseen pyrkivät torjuntatekniikat oli eroteltu tutkimuksessa kahteen osa-aluee- seen, joista ensimmäinen keskittyi viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä. Toinen taas keskittyi yrityksen verkkotunnuksien ja lähtevän sähkö- postin todennuksen suojaukseen. Kuvasta 14 nähdään tekniikoiden käyttömäärät mik- royrityksissä. Siniset palkit kuvaavat tekniikan käyttömääriä viestin aitouden ja lähettäjän todennukselle saapuvassa liikenteessä. Oranssit palkit taas kuvaavat tekniikoiden käyttö- määriä yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukselle. Lu- vun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 14. Mikroyritysten käyttämien todennukseen pyrkivien tekniikoiden käyttömäärät

Kuvan 14 sinisistä palkeista nähdään, että käytetyimpiä tekniikoita viestin aitouden ja lä- hettäjän todennukseen saapuvassa liikenteessä olivat käytetyn sähköpostipalvelun oletustekniikat (27) sekä SPF- (14) ja DKIM-tekniikat (11). Niitä käytti yhteensä yli kolmasosa vastaajista. DKIM ei silti päätynyt mikroyritysten tyypillisimpään vastaukseen, sillä tekniikkaa käyttämättömät yritykset esiintyivät vastauksissa enemmistönä. Yli kolmasosa vastaajista käytti samoja tekniikoita myös verkkotunnuksiensa ja lähtevän sähköpostin todennuksen suojaukseen. Suojaus varmistettiin käytetyn sähköpostipalvelun oletustekniikoilla (27) sekä SPF- (17) ja DKIM-tekniikoilla (12), kuten kuvan oransseista palkeista voidaan nähdä. Enemmistö vastaajista ei ilmoittanut käyttävänsä muita todennukseen pyrkiviä tekniikoita, eikä niitä siten luettu mukaan mikroyritysten tyypillisimpään vastaukseen.

ARC- ja Sender ID -protokollat olivat vähiten käytetyt tekniikat alle 25 % yhteenlasketulla osuudella. Tässä vaiheessa täytyy muistuttaa, että tulokset perustuvat osallistuneiden yritysten omiin vastauksiin, eikä niitä ole muokattu. Tulosten tarkkuuden luotettavuutta käsi- tellään opinnäytetyön pohdintaosion luvussa 10.2.

9.1.5 Muut torjuntatekniikat mikroyrityksissä

Vastanneet mikroyritykset täsmensivät kyselylomakkeen viimeisissä kysymyksissä muiksi käyttämikseen torjuntatekniikoiksi useita eri pilvipohjaisia turvapalveluita, kuten F-Secure MSG -, Server and Email Security -palvelut sekä D-Fence- ja Mimecast-turvapalvelut. Yksi vastaajayritys kertoi käyttävänsä lähettävän palvelimen standardin mukaiseen toimintaan perustuvia mekanismeja ja tarkistuksia tarkentamatta, mitä kyseiset tarkistukset ovat. Vastaajat käyttivät myös monia tutkimuksen rajauksen ulkopuolella olleita tekniikoita, kuten sähköpostiohjelman sisäisiä roskapostisuodattimia ja sähköpostiviestien salausta. Yksi vastaajayritys kertoi lisäksi haluavansa käyttää salattua sähköpostia tulevaisuudessa. (Liite 12.)

9.2 Pienet yritykset (10-49 henkilöä)

Tutkimukseen vastasi 34 henkilöä suomalaisista IT-alan pienistä yrityksistä. Pienellä yri- tyksellä viitataan yritykseen, joka työllistää 10-49 henkilöä. Yrityskoon vastauksista koottiin tyypillisin vastaus, joka näkyy taulukosta 7.

Taulukko 7. Pienten yritysten tyypillisin vastaus Pienten yritysten tyypillisin vastaus: Yrityskoko: pienet yritykset (10-49 henkilöä) Vastaajien määrä: 34 Vastaajan rooli yrityksessä: teknologiajohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4,1 b) olla merkitsemättä aitoja sähköpostiviestejä 3,9 roskapostiksi c) kokonaisuudessa 4,0 Roskapostin torjunta lähteen tai sisällön perusteella − palvelun oletustekniikoilla toteutettiin seuraavilla tekniikoilla: − SMTP-liikenteen suodatuksella − mustalistauksella (DNSBL) − sähköpostin sisällönsuoda- tuksella. Viestin aitouden ja lähettäjän todennus saapuvassa lii- − palvelun oletustekniikoilla kenteessä varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla. Verkkotunnuksien ja lähtevän sähköpostin todennuk- − palvelun oletustekniikoilla sen suojaus varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla.

Taulukosta 7 havaitaan, että pienten yritysten tyypillisin vastaaja oli yrityksen teknologiajohtaja. Vastaajayritys käytti tyypillisimmin Office 365 -palveluun sisältyvää Exchange On- line -sähköpostipalvelinta yrityksen sisäisiin sähköpostipalveluihin. Keskimääräinen tyyty- väisyys palvelua käyttäneillä oli 4 asteikolla 1-5.

Samasta taulukosta nähdään, että tyypillinen vastaajayritys torjui roskapostia sen sisällön ja lähteen perusteella seuraavilla tekniikoilla: − käyttämäänsä palveluun oletuksena kuuluvilla tekniikoilla − SMTP-liikenteen suodatuksella − DNS-pohjaisella mustalistauksella − sähköpostin sisällönsuodatuksella.

Lisäksi palvelun oletus-, SPF- ja DKIM-tekniikoilla varmistettiin viestin aitous ja lähettäjän todennus saapuvassa liikenteessä. Samoilla tekniikoilla varmistettiin myös yrityksen verkkotunnukset ja lähtevän sähköpostin todennuksen suojaus.

9.2.1 Sähköpostipalveluiden käyttöosuudet pienissä yrityksissä

Kuvassa 15 on esitetty eri sähköpostipalveluiden käyttöosuudet pienten yritysten vastauksista. Ympyräkaavion tummansininen sektori kuvaa Office 365 -palvelua, punainen G Suite -palvelua, keltainen itse ylläpidettyä Linux-pohjaista sähköpostipalvelua, sininen itse ylläpidettyä Windows-pohjaista sähköpostipalvelua ja musta jotain muuta ennalta määrit- telemätöntä sähköpostipalvelua.

Kuva 15. Pienten yritysten käyttämien sähköpostipalveluiden prosenttiosuudet vastauksista

Office 365 (Exchange Online) -palvelun osuus vastauksista oli ylivoimainen yli 50 % osuu- dellaan, kuten kuvasta 15 nähdään. Seuraavaksi käytetyin palvelu oli Googlen G Suite yli 25 % osuudella. Kaikki muut vaihtoehdot saivat alle 10 % käyttöosuuden, ja niistä itse yl- läpidetyllä Windows-pohjaisella sähköpostipalvelulla oli pienin osuus. Pilvipalvelupohjais- ten sähköpostipalvelujen osuus kaikista vastauksista oli noin 80 %.

9.2.2 Palvelukohtainen tyytyväisyys pienissä yrityksissä

Vastaajien tyytyväisyyttä käytettyihin sähköpostipalveluihin mitattiin kahdella muuttujalla: tyytyväisyydellä järjestelmien kykyyn suodattaa oikeita roskapostiviestejä sekä järjestel- mien kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Vastaajat kuvasivat tyytyväisyyttään asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Lo- puksi molemmista vastauksista laskettiin kunkin sähköpostipalvelun tyytyväisyyden keskiarvo.

Kuvassa 16 on esitetty tyytyväisyyden keskiarvot pienten yritysten käyttämiin sähköposti- palveluihin. Kaavion tummansininen palkki kuvaa vastaajien tyytyväisyyden keskiarvoa Office 365 -palveluun, punainen G Suite -palveluun, keltainen itse ylläpidettyyn Linux-pohjaiseen sähköpostipalveluun, sininen itse ylläpidettyyn Windows-pohjaiseen sähköposti- palveluun ja musta johonkin muuhun ennalta määrittelemättömään sähköpostipalveluun. Vaalean- ja tummanharmaat palkit värillisten palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 16. Pienten yritysten tyytyväisyyksien keskiarvo käytettyihin sähköpostipalveluihin

Kuvan 16 tiedoista nähdään, että tyytyväisyys oli suurinta G Suite -käyttäjien keskuudessa, mikä näkyy palvelun saamasta keskiarvosta 4,4. Itse ylläpidetyt Linux-pohjaiset sähköpostipalvelut saivat vastaajilta toiseksi parhaimman keskiarvon 4,3. Muita sähköpos- tipalveluita käyttäneet vastaajat kuvasivat tyytyväisyyttään keskiarvolla 4. Heihin kuului myös enemmistö eli Office 365 -palvelua käyttäneet vastaajat.

9.2.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyt- tömäärät pienissä yrityksissä

Pienet yritykset suodattivat roskapostia sen lähteen tai sisällön perusteella yhdeksällä eri tekniikalla, joista tyypillisimmät näkyvät taulukosta 7. Kuvassa 17 on esitetty kaikkien ky-

67 syttyjen tekniikoiden käyttömäärät pienissä yrityksissä. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 17. Pienten yritysten käyttämien torjuntatekniikoiden käyttömäärät viestin lähtee- seen tai sisältöön perustuvassa torjunnassa

Kuvasta 17 nähdään, että pienten yritysten käytetyimpiä torjuntatekniikoita olivat palveluun kuuluvien oletustekniikoiden ohella sähköpostin sisällönsuodatus (16), DNS-pohjainen mustalistaus (15) ja SMTP-liikenteen suodatus (14). Niitä käytti yhteensä yli kolmasosa vastaajista. Samat torjuntatekniikat päätyivät lopulta mukaan pienten yritysten tyypilli- simpään vastaukseen. Kuvasta 17 käy myös ilmi, että fyysisten roskapostisuodattimien käyttö oli selkeästi vähäisintä. Niitä käytti vain kaksi vastaajaa eli noin viisi prosenttia pie- nistä yrityksistä.

9.2.4 Todennukseen pyrkivien tekniikoiden käyttömäärät pienissä yrityksissä

68 dennukselle saapuvassa liikenteessä. Oranssit palkit taas kuvaavat tekniikoiden käyttö- määriä yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukselle. Lu- vun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 18. Pienten yritysten käyttämien todennukseen pyrkivien tekniikoiden käyttömäärät

Kuvan 18 sinisistä palkeista nähdään, että käytetyimpiä tekniikoita viestin aitouden ja lä- hettäjän todennukseen saapuvassa liikenteessä olivat käytetyn sähköpostipalvelun oletustekniikat (33) sekä SPF- (18) ja DKIM-tekniikat (12). Niitä käytti yhteensä yli kolmasosa vastaajista. Yli kolmasosa vastaajista käytti samoja tekniikoita myös verkkotunnuksiensa ja lähtevän sähköpostin todennuksen suojaukseen. Suojaus varmistettiin käytetyn sähkö- postipalvelun oletustekniikoilla (34) sekä SPF- (21) ja DKIM-tekniikoilla (14), kuten kuvan oransseista palkeista voidaan nähdä. Enemmistö vastaajista ei ilmoittanut käyttävänsä muita todennukseen pyrkiviä tekniikoita, eikä niitä siten katsottu mukaan pienten yritysten tyypillisimpään vastaukseen. ARC, DMARC ja Sender ID olivat vähiten käytettyjä tekniikoita vastaajien keskuudessa.

9.2.5 Muut torjuntatekniikat pienissä yrityksissä

Vastanneet pienet yritykset täsmensivät kyselylomakkeen viimeisissä kysymyksissä muiksi käyttämikseen torjuntatekniikoiksi useita eri pilvipohjaisia turvapalveluita, kuten Of- fice 365 Advanced Threat Protection- ja MagicSpam -palvelut. Yksikään vastaaja ei tuonut

69 esille sellaista torjuntatekniikkaa, joka ei kuuluisi tutkimuksen rajaukseen. Kukaan vastanneista ei myöskään ilmoittanut haluavansa käyttää sellaista torjuntatekniikkaa, jota kyselylomakkeessa ei ollut erikseen kysytty. (Liite 13.)

9.3 Keskisuuret yritykset (50-249 henkilöä)

Tutkimukseen vastasi kuusi henkilöä suomalaisista IT-alan keskisuurista yrityksistä. Kes- kisuurella yrityksellä viitataan yritykseen, joka työllistää 50-249 henkilöä. Yrityskoon vastauksista koottiin tyypillisin vastaus, joka näkyy taulukosta 8. Koska vastaajia oli vähän, tuloksia tulee pitää vain suuntaa antavina eikä niistä tule tehdä liian yleistettyjä johtopää- töksiä. Asiaa käsitellään tarkemmin luvussa 10.2.

Taulukko 8. Keskisuurten yritysten tyypillisin vastaus Keskisuurten yritysten tyypillisin vastaus: Yrityskoko: keskisuuret yritykset (50-249 Vastaajien määrä: 6 henkilöä) Vastaajan rooli yrityksessä: teknologiajohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4,3 b) olla merkitsemättä aitoja sähköpostiviestejä 4,7 roskapostiksi c) kokonaisuudessa 4,5 Roskapostin torjunta lähteen tai sisällön perusteella − palvelun oletustekniikoilla toteutettiin seuraavilla tekniikoilla: − pilvipohjaisella roskapostisuodatuksella − SMTP-liikenteen suodatuksella − mustalistauksella (DNSBL) − harmaalistauksella − nolisting-tekniikalla − sähköpostin sisällönsuoda- tuksella − fyysisillä roskapostisuodattimilla. Viestin aitouden ja lähettäjän todennus saapuvassa − palvelun oletustekniikoilla liikenteessä varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − Sender ID -tekniikalla − DKIM-tekniikalla − DMARC-tekniikalla. Verkkotunnuksien ja lähtevän sähköpostin todennuk- − palvelun oletustekniikoilla sen suojaus varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − Sender ID -tekniikalla − DKIM-tekniikalla − DMARC-tekniikalla.

Taulukosta 8 havaitaan, että keskisuurten yritysten tyypillisin vastaaja oli yrityksen teknologiajohtaja. Vastaajayritys käytti tyypillisimmin Office 365 -palveluun sisältyvää Exchange Online -sähköpostipalvelinta yrityksen sisäisiin sähköpostipalveluihin. Keskimääräinen tyy- tyväisyys palvelua käyttäneillä oli 4,5 asteikolla 1-5.

Samasta taulukosta nähdään, että tyypillinen vastaajayritys torjui roskapostia sen sisällön ja lähteen perusteella seuraavilla tekniikoilla: − käyttämäänsä palveluun oletuksena kuuluvilla tekniikoilla − pilvipalvelupohjaisella roskapostisuodatuksella − SMTP-liikenteen suodatuksella − DNS-pohjaisella mustalistauksella − harmaalistauksella − nolisting-tekniikalla − sähköpostin sisällönsuodatuksella − fyysisillä roskapostisuodattimilla.

Lisäksi vastaajayritys varmisti viestin aitouden ja lähettäjän todennuksen sekä yrityksen verkkotunnuksien ja lähtevän sähköpostin todennuksen suojauksen seuraavilla tekniikoilla: − käyttämäänsä palveluun oletuksena kuuluvilla tekniikoilla − SPF-tekniikalla − Sender ID -tekniikalla − DKIM-tekniikalla − DMARC-tekniikalla.

9.3.1 Sähköpostipalveluiden käyttöosuudet keskisuurissa yrityksissä

Kuvassa 19 on esitetty eri sähköpostipalveluiden käyttöosuudet keskisuurten yritysten vastauksista. Ympyräkaavion tummansininen sektori kuvaa Office 365 -palvelua, punainen G Suite -palvelua, sininen itse ylläpidettyä Windows-pohjaista sähköpostipalvelua ja musta jotain muuta ennalta määrittelemätöntä sähköpostipalvelua.

Kuva 19. Keskisuurten yritysten käyttämien sähköpostipalveluiden prosenttiosuudet vastauksista

Office 365 (Exchange Online) -palvelun osuus oli puolet kaikista keskisuurten yritysten vastauksista, kuten kuvasta 19 nähdään. Itse ylläpidettyä Linux-pohjaista sähköpostipal- velua ei käyttänyt kukaan vastanneista. Loput kolme vaihtoehtoa saivat yhtä suuren 17 % osuuden vastauksista. Kokonaisuudessa pilvipalvelujen käyttöosuudet olivat lähes 85 % kaikista vastauksista. Tämä siksi, että vastausvaihtoehdon ”Muu” valinnut yritys ilmoitti käyttävänsä D-Fencen pilvipalvelupohjaista sähköpostiratkaisua.

Tässä kohtaa on huomattava, että kyselytutkimukseen osallistuneita keskisuuria yrityksiä oli vain kuusi. Koska näytekoko oli näin pieni, eri sähköpostipalvelujen osuuksista ei voida tehdä laaja-alaisia johtopäätöksiä keskisuurten yritysten käyttämistä sähköpostipalveluista yleisesti. Esimerkiksi Office 365 -palvelu sai 50 % käyttöosuuden vain kolmen vastauksen perusteella. Tulokset edustavat vain hyvin pientä osaa perusjoukosta, mikä vaikuttaa tutkimuksen luotettavuuteen (Taanila 2019d). Vaikutusta on vaikea selvittää, sillä ei ole tietoa siitä, miten eri yrityskoot jakautuivat tutkimuksen perusjoukossa. Mahdollisia syitä kyseisen yrityskoon vähäiseen osallistumiseen ja tutkimusmenetelmien vaikutusta tulosten luotettavuuteen käsitellään opinnäytetyön pohdintaosion luvussa 10.2.

9.3.2 Palvelukohtainen tyytyväisyys keskisuurissa yrityksissä

Vastaajien tyytyväisyyttä käytettyihin sähköpostipalveluihin mitattiin kahdella muuttujalla: tyytyväisyydellä järjestelmien kykyyn suodattaa oikeita roskapostiviestejä sekä järjestel- mien kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Vastaajat kuvasivat tyytyväisyyttään asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Lo- puksi molemmista vastauksista laskettiin kunkin sähköpostipalvelun tyytyväisyyden keskiarvo.

Kuvassa 20 on esitetty tyytyväisyyden keskiarvot keskisuurten yritysten käyttämiin sähkö- postipalveluihin. Kaavion tummansininen palkki kuvaa vastaajien tyytyväisyyden keskiarvoa Office 365 -palveluun, punainen G Suite -palveluun, sininen itse ylläpidettyyn Win- dows-pohjaiseen sähköpostipalveluun ja musta johonkin muuhun ennalta määrittelemättö- mään sähköpostipalveluun. Vaalean- ja tummanharmaat palkit värillisten palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 20. Keskisuurten yritysten tyytyväisyyksien keskiarvo käytettyihin sähköpostipalve- luihin

Kuvan 20 tiedoista voidaan havaita, että tyytyväisyys oli tunnettujen sähköpostipalvelujen kohdalla suurinta G Suite -palvelua käyttäneiden keskuudessa, mikä näkyy palvelun saamasta keskiarvosta 5. Lisäksi muita ennalta määrittelemättömiä sähköpostipalveluja käyt- täneet vastaajat kuvasivat tyytyväisyyttään myös keskiarvolla 5. On huomioitava, että G Suite -palvelua ja ”Muu”-vaihtoehdon valinneita vastaajia oli vain yksi molempia, joten keskiarvo perustuu palveluiden kohdalla vain yhteen vastaukseen. ”Muu”-vaihtoehdon vastannut yritys käytti D-Fencen pilvipalvelupohjaista sähköpostipalvelua. Enemmistön käyttämä Office 365 sai tyytyväisyyden keskiarvokseen 4,5. Keskiarvo oli sama kuin itse ylläpidetyllä Windows-pohjaisella sähköpostipalvelulla, jota käytti yksi vastaaja.

9.3.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyt- tömäärät keskisuurissa yrityksissä

Keskisuuret yritykset suodattivat roskapostia sen lähteen tai sisällön perusteella yhdek- sällä eri tekniikalla, joista tyypillisimmät näkyvät taulukosta 8. Kuvassa 21 on esitetty kaikkien kysyttyjen tekniikoiden käyttömäärät keskisuurissa yrityksissä. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 21. Keskisuurten yritysten käyttämien torjuntatekniikoiden käyttömäärät viestin läh- teeseen tai sisältöön perustuvassa torjunnassa

Bayesilainen suodatus (1) oli ainoa torjuntatekniikka, joka ei päätynyt keskisuurten yritysten tyypillisimpään vastaukseen. Kuvasta 21 näkyy, että fyysisiä roskapostisuodattimia ja nolisting-tekniikkaa ilmoitti käyttävänsä kaksi vastaajaa kuudesta. Molemmat tekniikat päätyivät silti yrityskoon tyypillisimpään vastaukseen, sillä tarpeeksi moni vastaaja ilmoitti, etteivät he muista tai tiedä, käyttävätkö he kyseisiä tekniikoita. Tällöin tekniikoiden käyt- töönottaneita oli vähintäänkin yhtä paljon kuin vastaajia, jotka eivät varmuudella käyttä- neet kyseisiä tekniikoita.

9.3.4 Todennukseen pyrkivien tekniikoiden käyttömäärät keskisuurissa yrityk- sissä

Todennukseen pyrkivät torjuntatekniikat oli eroteltu tutkimuksessa kahteen osa-aluee- seen, joista ensimmäinen keskittyi viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä. Toinen taas keskittyi yrityksen verkkotunnuksien ja lähtevän sähkö- postin todennuksen suojaukseen. Kuvasta 22 nähdään tekniikoiden käyttömäärät keskisuurissa yrityksissä. Siniset palkit kuvaavat tekniikan käyttömääriä viestin aitouden ja lä- hettäjän todennukselle saapuvassa liikenteessä. Oranssit palkit taas kuvaavat tekniikoiden käyttömääriä yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukselle. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 22. Keskisuurten yritysten käyttämien todennukseen pyrkivien tekniikoiden käyttö- määrät

Kuvan 22 sinisistä palkeista on havaittavissa, että käytetyimpiä tekniikoita viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä olivat kaikki tekniikat ARC-protokollaa lukuun ottamatta. Kyseisiä tekniikoita käytti yhteensä vähintään kolmasosa vastaajista. Kolmasosa vastaajista käytti samoja tekniikoita myös verkkotunnuksiensa ja lähtevän säh- köpostin todennukseen, kuten kuvan oransseista palkeista voidaan nähdä.

9.3.5 Muut torjuntatekniikat keskisuurissa yrityksissä

Vastanneet keskisuuret yritykset täsmensivät kyselylomakkeen viimeisissä kysymyksissä muiksi käyttämikseen torjuntatekniikoiksi useita eri Microsoftin pilvipalvelupohjaisia turvapalveluita. Näitä olivat Office 365 Advanced Threat Protection- ja Azure Advanced Threat Protection -palvelut. Yksikään vastaaja ei tuonut esille torjuntatekniikkaa, joka ei kuuluisi tutkimuksen rajaukseen. Kukaan vastanneista ei myöskään ilmoittanut haluavansa käyt- tää sellaista torjuntatekniikkaa, jota kyselylomakkeessa ei ollut erikseen kysytty. (Liite 14.)

9.4 Suuryritykset (250 henkilöä tai enemmän)

Tutkimukseen vastasi viisi henkilöä suomalaisista IT-alan suuryrityksistä. Suuryrityksellä viitataan yritykseen, joka työllistää 250 henkilöä tai enemmän. Yrityskoon vastauksista koottiin tyypillisin vastaus, joka näkyy taulukosta 9. Koska vastaajia oli vähän, tuloksia tulee pitää vain suuntaa antavina eikä niistä tule tehdä liian yleistettyjä johtopäätöksiä. Asiaa käsitellään tarkemmin luvussa 10.2.

Taulukko 9. Suuryritysten tyypillisin vastaus Suuryritysten tyypillisin vastaus: Yrityskoko: suuryritykset (250+ henkilöä) Vastaajien määrä: 5 Vastaajan rooli yrityksessä: tietohallintojohtaja tai -päällikkö Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) tai G Suite (Gmail) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4,0 b) olla merkitsemättä aitoja sähköpostiviestejä 4,5 roskapostiksi c) kokonaisuudessa 4,3 Roskapostin torjunta lähteen tai sisällön perusteella − palvelun oletustekniikoilla toteutettiin seuraavilla tekniikoilla: − SMTP-liikenteen suodatuksella − mustalistauksella (DNSBL) − harmaalistauksella. Viestin aitouden ja lähettäjän todennus saapuvassa − palvelun oletustekniikoilla liikenteessä varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla − DMARC-tekniikalla. Verkkotunnuksien ja lähtevän sähköpostin todennuk- − palvelun oletustekniikoilla sen suojaus varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla − DMARC-tekniikalla.

Taulukosta 9 havaitaan, että suuryritysten tyypillisin vastaaja työskenteli yrityksen tietohal- linnossa joko johtajana tai päällikkönä. Yhdenkään vastaajan kuvailema rooli ei esiintynyt vastauksissa kahdesti, joten takin annettava tyyppivastaus on joko tietohallintojohtaja tai - päällikkö.

Vastaajayritys käytti tyypillisimmin joko Office 365- tai G Suite -palvelua yrityksen sisäisiin sähköpostipalveluihin. Keskimääräinen tyytyväisyys palveluita käyttäneillä oli 4,3 asteikolla 1-5. Office 365- ja G Suite -käyttäjiä oli vastaajien joukossa yhtä paljon, joten kes- kimääräinen tyytyväisyys laskettiin molempien palveluiden tyytyväisyyksien keskiarvojen keskiarvosta.

Samasta taulukosta 9 nähdään, että tyypillinen vastaajayritys torjui roskapostia sen sisäl- lön ja lähteen perusteella seuraavilla tekniikoilla: − käyttämäänsä palveluun oletuksena kuuluvilla tekniikoilla − SMTP-liikenteen suodatuksella − DNS-pohjaisella mustalistauksella − harmaalistauksella.

9.4.1 Sähköpostipalveluiden käyttöosuudet suuryrityksissä

Kuvassa 23 on esitetty eri sähköpostipalveluiden käyttöosuudet suuryritysten vastauksista. Ympyräkaavion tummansininen sektori kuvaa Office 365 -palvelua, punainen G Suite -palvelua ja sininen itse ylläpidettyä Windows-pohjaista sähköpostipalvelua.

Kuva 23. Suuryritysten käyttämien sähköpostipalveluiden prosenttiosuudet vastauksista

Kuvasta 23 on havaittavissa, että Office 365 ja G Suite -palveluiden osuudet jakautuivat tasan puoliksi niiden yhteisestä 80 % osuudesta. Viidesosa vastaajista ilmoitti käyttävänsä itse ylläpidettyä Windows-pohjaista sähköpostipalvelua. Sen sijaan Linux-pohjaista sähkö-

78 postipalvelua ei käytetty, eikä kukaan vastaajista ilmoittanut käyttävänsä jotain muuta ennalta määrittelemätöntä sähköpostipalvelua. Kokonaisuudessa pilvipalvelujen käyttöosuu- det olivat 80 % kaikista vastaajista.

Tässä on taas huomioitava, että kyselytutkimukseen osallistuneita suuryrityksiä oli vain viisi. Tällöin eri sähköpostipalvelujen osuuksia suuryrityksissä ei voida yleistää koko yrityskoolle, sillä esimerkiksi itse ylläpidetty Windows-pohjainen sähköpostipalvelu sai 20 % osuuden vastauksista ainoastaan yhden vastaajan vuoksi. Tulokset edustavat vain hyvin pientä osaa perusjoukosta, mikä vaikuttaa tutkimuksen luotettavuuteen (Taanila 2019d). Vaikutusta on vaikea selvittää, sillä ei ole tietoa siitä, miten eri yrityskoot jakautuivat tutkimuksen perusjoukossa. Mahdollisia syitä yrityskoon vähäiseen osallistumiseen ja tutkimusmenetelmien vaikutusta tulosten luotettavuuteen käsitellään opinnäytetyön pohdintaosion luvussa 10.2.

9.4.2 Palvelukohtainen tyytyväisyys suuryrityksissä

Vastaajien tyytyväisyyttä käytettyihin sähköpostipalveluihin mitattiin kahdella muuttujalla: tyytyväisyydellä järjestelmien kykyyn suodattaa oikeita roskapostiviestejä sekä järjestel- mien kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Vastaajat kuvasivat tyytyväisyyttään asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Lo- puksi molemmista vastauksista laskettiin kunkin sähköpostipalvelun tyytyväisyyden keskiarvo.

Kuvassa 24 on esitetty tyytyväisyyden keskiarvot suuryritysten käyttämiin sähköpostipal- veluihin. Kaavion tummansininen palkki kuvaa vastaajien tyytyväisyyden keskiarvoa Office 365 -palveluun, punainen G Suite -palveluun ja sininen itse ylläpidettyyn Windows-pohjaiseen sähköpostipalveluun. Vaalean- ja tummanharmaat palkit värillisten palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 24. Suuryritysten tyytyväisyyksien keskiarvo käytettyihin sähköpostipalveluihin

Kuvan 24 tiedoista nähdään, että tyytyväisyys oli tunnettujen sähköpostipalvelujen kohdalla suurinta G Suite -palvelua käyttäneiden keskuudessa, mikä näkyy palvelun saamasta keskiarvosta 4,8. Toiseksi tyytyväisin oli itse ylläpidetyn Windows-pohjaisen sähkö- postipalvelun käyttäjä, joka arvioi tyytyväisyyden keskiarvokseen 4. Office 365 -käyttäjät olivat tyytymättömimpiä. Heidän palvelutyytyväisyytensä keskiarvoksi laskettiin kokonaisuudessaan 3,8. Office- ja G Suite -käyttäjien tyytyväisyyteen vaikuttavien muuttujien suhde oli sama molemmissa palveluissa eli 0,5. Kyseisiä palveluita käyttäneet olivat tyyty- väisempiä palveluiden kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi kuin palveluiden kykyyn suodattaa oikeaa roskapostia. Windows-käyttäjä arvioi tyytyväi- syydekseen kaikilla osa-alueilla saman arvosanan 4.

9.4.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyt- tömäärät suuryrityksissä

Suuryritykset suodattivat roskapostia sen lähteen tai sisällön perusteella kuudella eri tekniikalla, joista tyypillisimmät näkyvät taulukosta 9. Kuvassa 25 on esitetty kaikkien kysyttyjen tekniikoiden käyttömäärät suuryrityksissä. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 25. Suuryritysten käyttämien torjuntatekniikoiden käyttömäärät viestin lähteeseen tai sisältöön perustuvassa torjunnassa

Kuvasta 25 nähdään, että fyysisiä roskapostisuodattimia, bayesilaista suodatusta ja nolisting-tekniikkaa ei käyttänyt kukaan vastanneista suuryrityksistä. Käyttö oli myös vähäistä sähköpostin sisällönsuodatuksen (1) ja pilvipohjaisen roskapostisuodatuksen kohdilla (1), sillä niitä käytti vain yksi vastaaja. Kaikki viisi vastaajaa käyttivät palveluunsa kuuluvia oletustekniikoita (5). Käytetyimpiä tekniikoita olivat oletustekniikoiden ohella SMTP-liikenteen suodatus (2), DNS-pohjainen mustalistaus (2) ja harmaalistaus (2), joista kaikkia käytti kaksi vastaajaa viidestä. Tekniikoiden käyttömäärät olivat pieniä, sillä ainoastaan neljää tekniikkaa yhdeksästä käytti yli kolmasosa vastaajista.

9.4.4 Todennukseen pyrkivien tekniikoiden käyttömäärät suuryrityksissä

Todennukseen pyrkivät torjuntatekniikat oli eroteltu tutkimuksessa kahteen osa-aluee- seen, joista ensimmäinen keskittyi viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä. Toinen taas keskittyi yrityksen verkkotunnuksien ja lähtevän sähkö- postin todennuksen suojaukseen. Kuvasta 26 nähdään kyseisten tekniikoiden käyttömää- rät suuryrityksissä. Siniset palkit kuvaavat tekniikan käyttömääriä viestin aitouden ja lähet- täjän todennukselle saapuvassa liikenteessä. Oranssit palkit taas kuvaavat tekniikoiden käyttömääriä yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukselle. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 26. Suuryritysten käyttämien todennukseen pyrkivien tekniikoiden käyttömäärät

Kuvan 26 sinisistä ja oransseista palkeista voidaan nähdä, että yli kolmasosa vastaajista käytti palveluun kuuluvien oletustekniikoiden (5) ohella SPF- (4), DKIM- (2) ja DMARC- tekniikoita (2) viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä. Sen- der ID -tarkistuksen teki vain yksi vastaaja saapuvassa liikenteessä. Se ja ARC-protokolla olivat vähiten käytettyjä todennukseen pyrkiviä tekniikoita suuryrityksissä. ARC-protokollaa ei ilmoittanut käyttävänsä yksikään vastanneista yrityksistä.

Lisäksi oranssien palkkien perusteella yli kolmasosa vastaajista varmisti verkkotunnuksien ja lähtevän sähköpostin todennuksen suojauksen käytetyn sähköpostipalvelun oletustekniikoilla (5) sekä SPF- (4), DKIM- (2) ja DMARC-tekniikoilla (2).

9.4.5 Muut torjuntatekniikat suuryrityksissä

Suuryritykset eivät ilmoittaneet käyttävänsä mitään sellaista torjuntatekniikkaa, joita kyselylomakkeessa ei ennestään tuotu esille. Vastaajat eivät myöskään ilmoittaneet mitään sellaista tekniikkaa, jonka he haluaisivat ottaa käyttöön tulevaisuudessa. (Liite 15.)

9.5 Kaikki yritykset

Tutkimukseen vastasi yhteensä 74 henkilöä suomalaisista IT-alan yrityksistä. Kaikkien tutkimukseen osallistuneiden yritysten vastauksista koottiin tyypillisin vastaus, joka on nähtä- vissä taulukosta 10.

Taulukko 10. Kaikkien yritysten tyypillisin vastaus Kaikkien yritysten tyypillisin vastaus: Yrityskoko: kaikki yritykset Vastaajien määrä: 74 Vastaajan rooli yrityksessä: toimitusjohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4,1 b) olla merkitsemättä aitoja sähköpostiviestejä 4,1 roskapostiksi c) kokonaisuudessa 4,1 Roskapostin torjunta lähteen tai sisällön perusteella − palvelun oletustekniikoilla toteutettiin seuraavilla tekniikoilla: − SMTP-liikenteen suodatuksella − mustalistauksella (DNSBL) − sähköpostin sisällönsuoda- tuksella. Viestin aitouden ja lähettäjän todennus saapuvassa − palvelun oletustekniikoilla liikenteessä varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla. Verkkotunnuksien ja lähtevän sähköpostin todennuk- − palvelun oletustekniikoilla sen suojaus varmistettiin seuraavilla tekniikoilla: − SPF-tekniikalla − DKIM-tekniikalla.

Taulukosta 10 havaitaan, että kaikkien yritysten tyypillisin vastaaja oli yrityksen toimitusjohtaja. Vastaajayritys käytti tyypillisimmin Office 365 -palveluun sisältyvää Exchange On- linea yrityksen sisäisiin sähköpostipalveluihin. Keskimääräinen tyytyväisyys palvelua käyt- täneillä oli 4,1 asteikolla 1-5.

Samasta taulukosta nähdään myös, että tyypillinen vastaajayritys torjui roskapostia sen sisällön ja lähteen perusteella seuraavilla tekniikoilla: − käyttämäänsä palveluun oletuksena kuuluvilla tekniikoilla − SMTP-liikenteen suodatuksella − DNS-pohjaisella mustalistauksella − sähköpostin sisällönsuodatuksella.

Lisäksi palvelun kuuluvilla oletus-, SPF- ja DKIM-tekniikoilla varmistettiin viestin aitous ja lähettäjän todennus saapuvassa liikenteessä sekä yrityksen verkkotunnukset ja lähtevän sähköpostin todennuksen suojaus.

9.5.1 Sähköpostipalveluiden käyttöosuudet kaikissa yrityksissä

Kuvassa 27 on esitetty eri sähköpostipalveluiden käyttöosuudet kaikkien yritysten vastauksista. Ympyräkaavion tummansininen sektori kuvaa Office 365 -palvelua, punainen G Suite -palvelua, keltainen itse ylläpidettyä Linux-pohjaista sähköpostipalvelua, sininen itse ylläpidettyä Windows-pohjaista sähköpostipalvelua ja musta jotain muuta ennalta määrit- telemätöntä sähköpostipalvelua.

Kuva 27. Kaikkien yritysten käyttämien sähköpostipalveluiden prosenttiosuudet vastauksista

Office 365 palvelun osuus vastauksista oli lähes 40 %, kuten kuvasta 27 nähdään. Seu- raavaksi suurin osuus oli G Suite -palvelua käyttäneillä, joiden osuus oli hieman yli 30 % vastaajista. Muita ennalta määrittelemättömiä sähköpostiratkaisuja käytti 15 % vastaajista. Linux-käyttäjien osuus oli hieman yli 10 % vastauksista. Itse ylläpidettyjä Windows-pohjaisia sähköpostipalveluja käytti alle viisi prosenttia vastaajista, mikä teki siitä vähiten käyte- tyn vaihtoehdon kaikissa yrityksissä. Pilvipalveluiden osuus vastauksista oli noin 70 % luokkaa. Luku on yli 75 %, jos huomioidaan vastauksen ”Muu” antaneiden yritysten mää- rittelemät pilvipalvelupohjaiset sähköpostipalvelut. Prosenttiluku sisältää vain kokonaan pilvitoteutuksena ylläpidetyt palvelut, eikä siinä ole huomioitu sekamuotoisia palvelutoteutuksia.

9.5.2 Palvelukohtainen tyytyväisyys kaikissa yrityksissä

Vastaajien tyytyväisyyttä käytettyihin sähköpostipalveluihin mitattiin kahdella muuttujalla: tyytyväisyydellä järjestelmien kykyyn suodattaa oikeita roskapostiviestejä sekä järjestel- mien kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Vastaajat kuvasivat tyytyväisyyttään asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Lo- puksi molemmista vastauksista laskettiin kunkin sähköpostipalvelun tyytyväisyyden keskiarvo.

Kuvassa 28 on esitetty tyytyväisyyden keskiarvot kaikkien yritysten käyttämiin sähköposti- palveluihin. Kaavion tummansininen palkki kuvaa vastaajien tyytyväisyyden keskiarvoa Office 365 -palveluun, punainen G Suite -palveluun, keltainen itse ylläpidettyyn Linux-pohjaiseen sähköpostipalveluun, sininen itse ylläpidettyyn Windows-pohjaiseen sähköposti- palveluun ja musta johonkin muuhun ennalta määrittelemättömään sähköpostipalveluun. Vaalean- ja tummanharmaat palkit värillisten palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 28. Kaikkien yritysten tyytyväisyyksien keskiarvo käytettyihin sähköpostipalveluihin

Kuvan 28 tiedoista havaitaan, että tyytyväisyys oli keskimäärin suurinta G Suite -palvelua käyttäneiden keskuudessa, mikä näkyy palvelun saamasta keskiarvosta 4,3. Itse ylläpide- tyt Linux- ja Windows-pohjaiset sähköpostipalvelut saivat molemmat käyttäjiltään tyytyväi- syyden keskiarvoksi 4,2. Office 365 -palvelun käyttäjien tyytyväisyyden keskiarvo oli 4,1.

Muita sähköpostiratkaisuja käyttäneet vastaajat kuvasivat tyytyväisyyttään keskiarvolla 3,6. Arvo ei ole yksiselitteinen, sillä se koottiin vastauksista 11 yritykseltä, jotka käyttivät hyvin erilaisia sähköpostiratkaisuja. Tästä syystä luvussa 9.5.6 on laskettu käyttäjien tyy- tyväisyydet kullekin ”Muu”-vaihtoehdossa tarkennetulle palvelulle.

9.5.3 Roskapostia sen sisällön tai lähteen perusteella torjuvien tekniikoiden käyt- tömäärät kaikissa yrityksissä

Yritykset suodattivat roskapostia sen lähteen tai sisällön perusteella yhdeksällä eri tekniikalla, joista tyypillisimmät näkyvät taulukosta 10. Kuvassa 29 on esitetty kaikkien kysyttyjen tekniikoiden käyttömäärät yrityksissä. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 29. Kaikkien yritysten käyttämien torjuntatekniikoiden käyttömäärät viestin lähtee- seen tai sisältöön perustuvassa torjunnassa

Kuvasta 29 havaitaan, että kaikkien yritysten käytetyimpiä torjuntatekniikoita olivat palveluun kuuluvien oletustekniikoiden ohella sähköpostin sisällönsuodatus (34), DNS-pohjainen mustalistaus (31) ja SMTP-liikenteen suodatus (30). Niitä käytti reilusti yli kolmasosa vastaajista. Noin 30 % vastaajista käytti myös harmaalistausta (24) ja bayesilaista suoda-

86 tusta (22) sähköpostipalveluissaan. Vähiten käytettyjä tekniikoita olivat fyysiset roskapostisuodattimet (8) ja nolisting-tekniikka (13). 17 vastaajaa käytti jotain pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta, jolta heidän sähköpostipalvelunsa oli tilattu.

9.5.4 Todennukseen pyrkivien tekniikoiden käyttömäärät kaikissa yrityksissä

Todennukseen pyrkivät torjuntatekniikat oli eroteltu tutkimuksessa kahteen osa-aluee- seen, joista ensimmäinen keskittyi viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä. Toinen taas keskittyi yrityksen verkkotunnuksien ja lähtevän sähkö- postin todennuksen suojaukseen. Kuvasta 30 nähdään kyseisten tekniikoiden käyttömää- rät kaikissa yrityksissä. Siniset palkit kuvaavat tekniikan käyttömääriä viestin aitouden ja lähettäjän todennukselle saapuvassa liikenteessä. Oranssit palkit taas kuvaavat tekniikoiden käyttömääriä yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukselle. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttäjämääriin.

Kuva 30. Kaikkien yritysten käyttämien todennukseen pyrkivien tekniikoiden käyttömäärät

Kuvan 30 sinisistä palkeista nähdään, että käytetyimpiä tekniikoita viestin aitouden ja lä- hettäjän todennukseen saapuvassa liikenteessä olivat käytetyn sähköpostipalvelun oletustekniikat (71) sekä SPF- (40) ja DKIM-tekniikat (28). Samat tekniikat päätyivät myös taulukon 10 tyypillisimpään vastaukseen, sillä käyttöönottaneet muodostivat enemmistön vastaajista. Kyseisiä tekniikoita käytti yli kolmasosa vastaajista.

Yli kolmasosa vastaajista käytti samoja tekniikoita myös verkkotunnuksiensa ja lähtevän sähköpostin todennuksen suojaukseen. Suojaus varmistettiin käytetyn sähköpostipalvelun

87 oletustekniikoilla (72) sekä SPF- (46) ja DKIM-tekniikoilla (31), kuten kuvan oransseista palkeista voidaan nähdä. Tekniikoiden käyttäminen omien verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen oli yleisempää kuin tarkistusten tekeminen saapuvassa sähköpostiliikenteessä. Vähiten käytettyjä tekniikoita olivat Sender ID ja ARC, joita käytti alle 20 % vastaajista.

9.5.5 Muut torjuntatekniikat kaikissa yrityksissä

Tutkimukseen vastanneet yritykset kuvailivat kyselylomakkeen viimeisissä kysymyksissä muita käyttämiään torjuntatekniikoita (liite 16). Näitä olivat esimerkiksi: − Azure Advanced Threat Protection − D-Fence Email Security − F-Secure MSG − F-Secure Server and Email Security − lähettävän palvelimen standardin mukaiseen toimintaan perustuvat mekanismit ja tarkistukset − MagicSpam − Mimecast − Office 365 Advanced Threat Protection.

Lisäksi vastaajat kertoivat käyttävänsä tai haluavansa käyttää sähköpostin salausta esimerkiksi PGP-protokollalla. Salaus ei itsessään estä roskapostitusta ja on siten opinnäyte- työn rajauksen ulkopuolella. Samoin muutama vastaaja ilmoitti käyttävänsä Thunderbird- sähköpostiohjelman sisäistä suodatusta, joka toimii bayesilaisen suodattimen tavoin. Ky- seiset keinot eivät myöskään kuulu opinnäytetyön rajaukseen, sillä suodatus tapahtuu niissä sähköpostin käyttäjäohjelman tasolla.

9.5.6 Muuta tietoa kaikkien yritysten vastauksista

Kyselytutkimuksen vastauksista saadaan myös tietoa muun muassa tekniikoista, joita yritykset eivät tunteneet tai haluaisivat käyttää. Luvussa esitettävät kaaviot on tehty ainoastaan kaikkien yritysten yhteisestä datasta eikä erikseen yrityskokojen perusteella. Syynä oli se, että data oli hyvin vähäistä tiettyjen yrityskokojen kohdalla, joten yhteinen data on mahdollisten jatkotutkimusten kannalta oleellisempaa.

Yksi kyselylomakkeen vastausvaihtoehdoista oli ”Emme käytä, mutta haluaisimme käyt- tää” käytettyjä torjuntatekniikoita kartoittavissa kysymyksissä. Vastausmääriä tarkasteltaessa voidaan tehdä päätelmiä tiettyjen tekniikoiden haluttavuudesta yrityksissä, jotka eivät ole niitä vielä käyttöönottaneet. Kuvassa 31 on esitetty tekniikoiden käyttöönottamisesta kiinnostuneiden vastaajien määrät niille torjuntatekniikoille, joiden toiminta perustuu säh- köpostin lähteeseen tai sisältöön. Palkkikaavion värit on valittu selkeyden vuoksi, eikä

88 niillä ole muuta merkitystä. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttöönotosta kiinnostuneiden vastaajien määrään.

Kuva 31. Tekniikat, joita kaikki vastaajayritykset eivät käyttäneet, mutta haluaisivat käyttää roskapostin torjuntaan sen lähteen tai sisällön perusteella

Kuvasta 31 on havaittavissa, että nolisting-tekniikkaa (5) kohtaan oli eniten kiinnostusta yritysten keskuudessa. Sitä ilmoitti haluavan käyttää viisi vastaajaa. Seuraavaksi halu- tuimmat tekniikat olivat pilvipohjaiset- ja fyysiset roskapostisuodattimet, joita toivoi käyttä- vän kolme vastaajaa. Muita tekniikoita halusi käyttää kaksi vastaajaa kutakin lukuun ottamatta DNS-pohjaista mustalistausta, jota kukaan ei ilmoittanut haluavansa käyttää.

Kuvassa 32 on esitetty tekniikoiden käyttöönottamisesta kiinnostuneiden vastaajien mää- rät todennukseen pyrkiville tekniikoille. Siniset palkit kuvaavat tekniikan käyttöönotosta kiinnostuneiden määrää viestin aitouden ja lähettäjän todennukseen saapuvassa liiken- teessä. Oranssit palkit kuvaavat vastaavia lukuja yritysten verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen. Luvun tekstissä sulkujen sisällä esiintyvät lukuarvot viittaavat kaavion esittämien tekniikoiden käyttöönotosta kiinnostuneiden vastaajien määrään.

Kuva 32. Todennukseen pyrkivät tekniikat, joita vastaajat eivät käyttäneet, mutta haluaisivat käyttää

Kuvasta 32 havaitaan, että DMARC-tekniikan käyttöönottamista kohtaan oli eniten kiinnostusta. Sitä haluaisi käyttää viestin aitouden ja lähettäjän todennukseen kahdeksan vastaajaa (sininen palkki) sekä 13 vastaajaa verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen (oranssi palkki). DKIM oli toiseksi kiinnostavin tekniikka, jota haluaisi käyttää kuusi vastaajaa viestin aitouden ja lähettäjän todennukseen (sininen palkki) sekä yhdeksän vastaajaa verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen (oranssi palkki). SPF (2) oli yrityksiä vähiten kiinnostava tekniikka, mutta se oli samalla myös käytetyin todennukseen pyrkivä tekniikka palveluun kuuluvien oletustekniikoiden ohella (kuva 30).

Yksi toinen kyselylomakkeen vastausvaihtoehdoista oli ”En tunne tätä tekniikkaa” niiden kysymyksien kohdalla, joissa kartoitettiin yritysten käyttämiä tekniikoita. Vastausten pohjalta (liite 16) voidaan päätellä, mitkä torjuntatekniikat olivat vastaajien keskuudessa heikoiten tunnettuja. Kuvassa 33 on esitetty niiden vastaajien määrät, jotka eivät tunteneet kysyttyjä viestin lähteeseen tai sisältöön perustuvia torjuntatekniikoita. Palkkikaavion värit on valittu selkeyden vuoksi, eikä niillä ole muuta merkitystä. Tekstiviittaukset kuvan 33 kaavion arvoihin on merkattu luvun tekstissä sulkujen sisään.

Kuva 33. Heikoiten tunnetut viestin lähteen tai sisällön perusteella toimivat tekniikat

Kuvasta 33 nähdään, että nolisting (8) ja bayesilainen suodatus (8) olivat kaikkien yritysten vastauksista heikoiten tunnettuja torjuntatekniikoita. Niitä ei tuntenut yli 10 % vastaajista. Pilvipohjainen roskapostisuodatus eri palveluntarjoajalta (1) ja DNS-pohjainen mustalistaus (3) olivat parhaiten tunnettuja kyselylomakkeessa kysyttyjä viestin lähteeseen tai sisältöön perustuvia tekniikoita. Kyselylomakkeessa ei esiintynyt yhtään sellaista torjuntatekniikkaa, joka olisi ollut kaikkien vastaajien tiedossa palvelun oletustekniikoita lukuun ottamatta.

Kuvassa 34 on esitetty niiden vastaajien määrä, jotka eivät tunteneet kysyttyjä todennukseen pyrkiviä tekniikoita. Kaavion siniset palkit kuvaavat niiden vastaajien määrää, jotka eivät tunteneet mainittuja viestin aitouteen ja lähettäjän todennukseen perustuvia tekniikoita. Oranssit palkit taas kuvaavat niiden vastaajien määrään, jotka eivät tunteneet kysei- siä verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen perustuvia tekniikoita. Tekstiviittaukset kuvan 34 kaavion arvoihin on merkattu luvun tekstissä sulkujen si- sään.

Kuva 34. Heikoiten tunnetut todennukseen perustuvat tekniikat

Kuvasta 34 on nähtävissä, että ARC-protokolla (14) oli selvästi heikoiten tunnettu tekniikka sekä viestin aitouden ja lähettäjän todennukseen saapuvassa liikenteessä että verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen. Kyseistä tekniikkaa ei tuntenut kuin 14 vastaajaa eli noin 20 % kaikista 74 vastaajasta. Seuraavaksi huonoiten vastaajat tunsivat Sender ID -tekniikan, jota ei tuntenut kuin 8-9 vastaajaa eli hieman yli 10 % kaikista 74 vastaajasta. SPF- ja DKIM-tekniikat olivat parhaiten tunnettuja, sillä niistä tietämättömiä oli vain kolme vastaajaa viestin aitouden ja lähettäjän todennukseen osalta sekä neljä vastaajaa verkkotunnuksien ja lähtevän sähköpostin todennuksen suojauksen osalta. Tämä tarkoittaa, että kokonaisuudessaan lähes 95 % kaikkien yritysten vastaajista tunnisti kyseiset tekniikat.

Opinnäytetyön luvussa 9.5.2 käsiteltiin kaikkien tutkimukseen osallistuneiden yritysten pal- velukohtaisen tyytyväisyyden keskiarvoa. Muut kuin kyselylomakkeessa ennalta määritel- lyt sähköpostipalvelut saivat tyytyväisyyden keskiarvokseen 3,6 (kuva 28). Keskiarvo kuvaa keskimääräistä tyytyväisyyttä muihin vastaajien mainitsemiin sähköpostipalveluratkai- suihin, eikä se siten kuvaa tyytyväisyyttä mihinkään yksittäiseen palveluun.

Kuvassa 35 on esitetty vastaajien esille tuomien muiden sähköpostipalvelujen palvelukoh- taiset tyytyväisyydet. Vastaajat kuvasivat tyytyväisyyttään asteikolla 1-5, jossa yksi vastaa tyytymätöntä ja viisi tyytyväistä. Kaavion mustat palkit kuvaavat tyytyväisyyden keskiarvoa palkin vasemmalla puolella määriteltyyn palveluratkaisuun. Vaalean- ja tummanharmaat

92 palkit mustien palkkien alapuolella kuvaavat niitä kahta muuttujaa, joista palvelun keskiarvo laskettiin. Muuttujien selitykset näkyvät kaavion oikealla puolella.

Kuva 35. Kaikkien yritysten tyytyväisyyksien keskiarvo muihin käytettyihin sähköpostipal- veluihin

Kuvan 35 tiedoista havaitaan, että tyytyväisyys oli suurinta D-Fencen sähköpostipalvelua käyttäneillä sekä yhden vastaajan Office 365 Hybrid -ympäristössä. D-Fence -käyttäjiä oli kolme, joista kaikki antoivat palvelulle täydet pisteet. Molemmat ratkaisut saivat tyytyväi- syyden keskiarvoksi 5. Tyytymättömimpiä olivat webhotellien sähköpostipalveluita käyttä- neet kaksi yritystä. Webhotellien sähköpostipalveluiden palvelutyytyväisuuden keskiarvo oli vain 2. Muut ratkaisut saivat tyytyväisyyksien keskiarvoiksi arvoja väliltä 3-4, ja niiden käyttäjiä oli vain yksi kutakin palvelua kohden.

10 Pohdinta

Tässä opinnäytetyön viimeisessä luvussa käsitellään tutkimustulosten merkitystä, tulosten luotettavuutta ja tutkimuksen onnistumista. Luvussa pyritään löytämään mahdollisia tutkimustulosten luotettavuutta heikentäviä tekijöitä. Lisäksi pohditaan, miten tutkimusmenetel- miä voitaisiin parantaa. Luvussa esitetään myös suosituksia yrityksille tutkimustulosten pohjalta. Lopussa tarkastellaan opinnäytetyön tekijän oppimista ja kehitystä opinnäytetyö- projektin aikana.

10.1 Tulosten arviointi ja tulkinta

Luvuissa 10.1.1-5 arvioidaan kunkin yrityskoon tulosten merkitystä ja pohditaan, mitkä te- kijät ovat vaikuttaneet yritysten antamiin vastauksiin. Tämän lisäksi kyselytutkimuksessa ilmi tulleille ilmiölle pyritään esittämään mahdollisia syitä.

10.1.1 Mikroyritykset (1-9 henkilöä)

Toimitusjohtaja oli yleisimmin mikroyrityksistä kyselytutkimukseen vastannut henkilö (taulukko 6). Tämä on odotettua, sillä 1-9 henkilön yrityksissä on yleistä, että toimitusjohtaja on vastuussa myös viestinnästä ja IT-ylläpidosta muiden tehtäviensä ohessa. Tutkimuk- seen osallistuneissa mikroyrityksissä saattoi olla mukana useita yhden työntekijän yrityk- siä.

Sähköpostipalveluiden jakautuminen opinnäytetyön kuvan 11 mukaisesti voi olla seurausta ratkaisujen edullisuudesta. Esimerkiksi Linux-sähköpostipalvelimien ylläpitäminen saattaa tulla pitkällä tähtäimellä halvemmaksi kuin lisenssimaksuihin perustuvat pilvipalvelut. Tällöin kustannukset tulevat lähinnä joko paikallisen palvelinraudan hankintakustan- nuksista tai vuokrattavasta virtuaalipalvelimesta. Uusien käyttäjien lisääminen ei tuota li- säkustannuksia. Pilvipalvelut taas veloittavat käyttäjäkohtaisesti kuukausittain. Office 365 E3 -lisenssi maksaa käyttäjää kohden 19,70 €, mikä tarkoittaisi yhdeksän hengen yritykselle lähes 180 € kuukausiveloitusta (Microsoft 2019k). Monet ”Muu”-vaihtoehdon valinneet vastaajat olivat tarkentaneet käyttämäkseen palveluksi jonkin webhotellin sähköposti- palvelun. Webhotellit tarjoavat tyypillisesti rajallisen määrän sähköpostilaatikoita verkkosivutilan ohella samaan kuukausiveloitukseen. G Suite -palvelun suosio saattaa selittyä palvelun käyttöönoton ja ylläpidon yksinkertaisuudella Office 365 -palveluun verrattuna.

Mikroyritykset olivat ainoa yrityskoko, jonka vastaajat ilmoittivat Office 365 -palvelun tyyty- väisyyden keskiarvon suuremmaksi kuin G Suite -palvelun (kuva 12). Se oli myös ainoa

94 yrityskoko, jossa oli enemmän G Suite- kuin Office 365 -käyttäjiä (kuva 11). Palvelutyyty- väisyys näyttäisi laskevan kyseisten kahden palvelun osalta käyttäjämäärän kasvaessa vastaajien keskuudessa. Muita ennalta määrittelemättömiä sähköpostipalveluja käyttäneet yritykset antoivat tyytyväisyytensä keskiarvoksi tulosten heikoimman arvon (kuva 12). Muun muassa webhotellien roskapostisuodatukset saivat hyvin heikkoja keskiarvoja. Syy saattaa olla se, että webhotellien sähköpostipalvelut tulevat usein ilmaisena muiden palveluiden yhteydessä. Tällöin palveluntarjoaja ei oletettavasti ole panostanut niiden torjun- tatekniikoihin kovinkaan paljon, sillä palvelu ei itsessään tuota heille voittoa.

Torjuntatekniikoiden käyttömäärät olivat alhaisia vastanneiden yritysten kokonaislukumää- rän nähden (kuva 13). Vastauksista on havaittavissa vastaajien tietämättömyys käyttämis- tään torjuntatekniikoista. Esimerkiksi SMTP-liikenteen suodatusta käytti vastausten perusteella vain 11 vastaajaa eli alle 40 % mikroyrityksistä. Todennäköisesti luku on merkittä- västi suurempi, sillä lähes kaikki sähköpostipalvelimet tekevät oletettavasti jonkinlaista SMTP-liikenteen suodatusta yleisten suositusten mukaisesti (IETF 1999a, 4-16). Näin on varsinkin pilvipalvelupohjaisissa toteutuksissa, joissa asiakas ei konfiguroi palvelimia itse. Suurin osa vastaajista ilmoitti kyllä käyttävänsä palveluun kuuluvia oletustekniikoita, mutta he eivät kenties osanneet eritellä niihin kuuluvia tekniikoita. Tekniikoiden vähäiset käyttö- määrät ovat todennäköisimmin seurausta kyselyyn vastanneiden henkilöiden tietotaidon puutteesta tutkimuksen aihepiiriin, sillä vastaajien toimenkuva oli varmuudella IT-alaan liit- tyvä ainoastaan noin 30 % vastanneista (liite 12).

Vastaajien toimenkuvan vaikutus tulosten tarkkuuteen näkyi myös todennukseen pyrkivien tekniikoiden kartoituksessa (kuva 14). Esimerkiksi ARC-protokollaa käytti käyttötarkoituk- sesta riippuen korkeintaan viisi yritystä eli hieman yli 15 % vastanneista. Todellisuudessa käyttäjämäärä lienee huomattavasti suurempi, sillä lähes 40 % vastaajista oli Googlen G Suite -palvelun käyttäjiä (kuva 11). Google käyttää sähköpostipalveluissaan ARC-protokollaa oletuksena (ARC Specification for Email 2019a). DMARC-käyttäjiä oli kohtuullisen paljon vastaajamäärään nähden, mutta DKIM-käyttäjiä oli silti 2-4 enemmän riippuen käyt- tötarkoituksesta (kuva 14). DKIM-tekniikan käyttö ilman DMARC-tekniikkaa on erikoista, sillä DKIM ei itsessään ota kantaa siihen, mitä vastaanottavan palvelimen tulisi tehdä, jos viestin allekirjoittanut taho ei täsmää otsaketietojen määrittelemän lähettäjäosoitteen kanssa (Whalen 2018). Sama tekniikoiden käyttösuhde toistuu myös muissa yrityskoissa. Syynä on todennäköisesti DMARC-tekniikan käyttöönottoon liittyvät käytännön ongelmat. Aihetta ei käsitellä tässä opinnäytetyössä tarkemmin, koska se ei ole tutkimuskysymysten kannalta oleellista.

Kyselylomakkeen vapaamuotoisissa kysymyksissä vastaajat tarkensivat käyttämiään pilvipalvelupohjaisia roskapostisuodattimia (liite 12). Vastauksiksi olisi riittänyt, että vastaajat olisivat ilmoittaneet aiemmassa kysymyksessä yritystensä käyttävän pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta. Osa vastaajista taas ilmoitti käyttämänsä pilvipohjaisen suodattimen ainoastaan lomakkeen lopussa, jolloin niitä ei laskettu mukaan kuvan 13 kaavioon. Tämä vääristi osaltaan vastauksia ja tutkimustuloksia. Vääristymän vaikutusta tuloksiin on arvioitu luvussa 10.2.

10.1.2 Pienet yritykset (10-49 henkilöä)

Teknologiajohtaja oli yleisimmin pienistä yrityksistä kyselytutkimukseen vastannut henkilö (taulukko 7). Vastauksista oli havaittavissa, että vastaajien toimenkuvat olivat enemmän IT- ja teknologiapainotteisia mikroyritysten vastaajiin verrattuna. Ainoastaan kaksi toimi- tusjohtajaa vastasi kyselylomakkeeseen pienten yritysten puolesta (liite 13). Ero on huomattava mikroyrityksiin nähden, joissa toimitusjohtaja oli tyypillisin vastaaja. Oli ennustettavissa, että vastaajien roolit monipuolistuivat yritysten henkilöstömäärän kasvaessa, sillä yrityksillä on todennäköisesti varaa palkata enemmän eri osa-alueiden osaajia.

Sähköpostipalveluiden jakautuminen kuvan 15 mukaisesti on todennäköisesti seurausta ratkaisujen skaalattavuudesta. Pilvipalvelupohjaisten sähköpostipalvelujen osuus vastauksissa oli noin 80 %, josta yli puolet koostui Office 365 -palvelusta. Muutos oli suuri verrattuna mikroyrityksiin, joiden vastausten kokonaisuudesta Office 365 -palvelulla oli vain 17 % osuus (kuva 11). Officen suosio näyttäisi kasvaneen yrityksen henkilöstömäärän myötä. Itse ylläpidettyjen palveluratkaisujen suosio oli myös näkyvästi alhainen mikroyrityksiin verrattuna. Tämä johtunee siitä, että pilveen nojautuvat ratkaisut ovat yleisesti helpommin skaalattavissa yrityskoon kasvaessa (Cohen 2019). Pilvipalvelut saattavat tulla lisenssi- maksuineen kalliimmiksi kuin esimerkiksi itse ylläpidetty Linux-pohjainen sähköpostipalve- lin, mutta pilvipalvelujen ylläpidettävyys ja käytön helppous on huomioitava. Paikallisissa sähköpostipalvelimissa on taas käyttöönoton hankintakustannukset, mutta kuukausittaista veloitusta ei ole. Paikallisessa Windows Exchange -palvelimessa edellytetään tosin käyt- töjärjestelmälisenssien ohella myös käyttäjäkohtaisia CAL-lisenssejä, mikä nostaa kustannuksia yrityskoon kasvaessa (Office 2019b). Paikalliset ratkaisut edellyttävät myös enem- män ylläpitoa yrityksen henkilöstöltä, sillä niitä ei tyypillisesti saa valmiiksi asennettuna ilman käyttöönoton ulkoistamista. Yli kymmenen hengen yrityksillä saattaisi olla varaa ul- koistaa IT-palvelut kokonaan tai osittain, jolloin Microsoftin kumppanipalveluntarjoajat suo- sittelevat korkealla todennäköisyydellä Office 365 -palvelua.

Palvelutyytyväisyys näyttäisi vastaajien keskuudessa laskevan palvelun käyttäjämäärän kasvaessa (kuva 16). Näin oli myös mikroyrityksissä (kuva 12). Office 365 -palvelun käyt- tömäärät olivat pienissä yrityksissä suurinta, mutta palvelutyytyväisyys vasta toiseksi suurinta. Toisaalta vastaajien tyytyväisyyttä mittaavien muuttujien saamat keskiarvot olivat Of- fice-käyttäjien keskuudessa tasaisimpia. Palvelua käyttäneet olivat siis keskimäärin lähes yhtä tyytyväisiä palvelun kykyyn suodattaa oikeita roskapostiviestejä kuin sen kykyyn olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Muuttujien arvojen välillä oli vaihte- lua vain 0,2 asteikolla 1-5. Muissa palveluissa muuttujien keskiarvot vaihtelivat laajemmin, jopa 0,4-2 samalla asteikolla. Office 365 -palvelu koettiin siis tasaisen luotettavaksi.

Torjuntatekniikoiden käyttömäärät olivat mikroyritysten tavoin alhaisia vastanneiden yritysten kokonaislukumäärän nähden (kuva 17). Vastaajien teknologiataustalla ei näytä olevan huomattavaa parannusta vastausten tarkkuuteen niiden käyttömäärissä. Esimerkiksi SMTP-liikennettä ilmoitti käyttävän vain noin 40 % vastaajista, mikä vaikuttaa hyvin alhai- selta. Suurin osa vastaajista ilmoitti käyttävänsä palveluun kuuluvia oletustekniikoita, mutta he eivät osanneet eritellä niihin kuuluvia tekniikoita mikroyrityksiä paremmin.

Samat epätarkkuudet toistuivat todennukseen pyrkivien tekniikoiden kartoituksessa (kuva 18). Esimerkiksi ARC-protokollaa käytti vain yksi vastaaja, vaikka G Suite -käyttäjiä oli yli 25 % (kuva 15). Toisaalta tämä on ymmärrettävää, sillä protokolla ei ole vielä kovin tunnettu uutuutensa takia. Lähes 20 % kaikista tutkimukseen osallistuneista vastaajista ei tuntenut kyseistä tekniikkaa (kuva 34). DMARC-tekniikan käyttöönottomäärät olivat pie- nissä yrityksissä suhteellisesti alhaisemmat DKIM-tekniikan käyttömääriin verrattuna (kuva 18). Erot eivät olleet yhtä suuria mikroyrityksissä (kuva 14). Vaikuttaa siltä, että DMARC-tekniikan käyttöönoton kynnys verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaukseen kasvaa yrityskoon myötä. Tämä voi olla seurausta sähköposti-infrastruktuurin laajentumisesta, jolloin tekniikan käyttöönotossa on enemmän huomioitavia osa-alueita. Mikroyritykset näyttäisivät omaksuneen DMARC-tekniikan pieniä yrityksiä huomattavasti nopeammin.

Kyselylomakkeen vapaamuotoisissa kysymyksissä vastaajat lähinnä tarkensivat käyttämi- ään pilvipalvelupohjaisia roskapostisuodattimia. Puolet vastaajista ilmoitti käyttämänsä pilvipohjaisen suodattimen ainoastaan lomakkeen lopussa, jolloin niitä ei laskettu mukaan kuvan 17 kaavioon, mikä vääristi tutkimustuloksia.

10.1.3 Keskisuuret yritykset (50-249 henkilöä)

Teknologiajohtaja oli keskisuurista yrityksistä kyselytutkimukseen yleisimmin vastannut henkilö (taulukko 8). Kaikkien kuuden vastaajan rooli oli yrityksessä IT- tai teknologiapai- notteinen (liite 14). Sama muutos havaittiin jo pienten yritysten vastauksissa, kun niitä ver- rattiin mikroyrityksiin. Vastaajien roolit kohdentuvat tarkemmin tutkimuksen alalle, yrityksen henkilöstökoon kasvaessa.

Office 365 oli käytetyin sähköpostipalvelu keskisuurissa yrityksissä (kuva 19). Sitä käytti puolet vastaajista, mikä oli linjassa pienten yritysten tulosten kanssa, joissa Officella oli hieman yli 50 % käyttöosuus (kuva 15). Googlen G Suite näyttäisi menettäneen käyttö- osuuttaan Office 365 -palvelulle yrityskoon kasvaessa. Keskisuuria vastaajia oli vain kuusi (taulukko 8), jolloin tuloksia ei pidä yleistää varauksetta koko yrityskoolle. Aihetta käsitel- lään tarkemmin luvussa 10.2. Vertailuarvona pienissä yrityksissä oli 34 ja mikroyrityksissä 29 vastaajaa (taulukot 6 ja 7). Pilvipalvelupohjaisten sähköpostipalvelujen osuus vastauksista oli tähän mennessä vastausten suurinta 85 % osuudella (kuva 19).

Ainoastaan yksi keskisuuri vastaaja käytti itse ylläpitämäänsä Windows-pohjaista sähkö- postipalvelua, eikä Linux-käyttäjiä ollut yhtään (kuva 19). Tämä vahvistaa hypoteesia siitä, että yritykset ovat siirtämässä sähköpostipalvelujaan pilveen. Ratkaisun etuina ovat muun muassa palvelun toimintavarmuus ja skaalattavuus (Cohen 2019). Office 365 -pakettiin kuuluu myös tallennustilaa sekä monia toimistotyökaluja ja -ohjelmia, joita yritykset tyypillisesti tarvitsevat tai haluavat käyttää joka tapauksessa. Jos sähköpostijärjestelmät toteu- tettaisiin itse, kaikki muut työkalut tulisi silti hankkia joltain palveluntarjoajalta. Vapaan ohjelmiston ratkaisuja on olemassa, mutta ne eivät ole levinneet yhtä laajamittaiseen käyt- töön kuin Microsoft Office -tuoteperhe.

Keskisuurten yritysten palvelutyytyväisyysarvojen merkitystä on hankala tulkita ja verrata keskenään, sillä palveluiden käyttäjämäärät olivat niin pieniä. Kaikki palvelut saivat jokaisella mitatulla osa-alueellaan käyttäjien tyytyväisyydeksi arvon 4 tai suuremman (kuva 20). Yhdenkään palvelun kohdalla arvo ei ollut pienempi lukuun ottamatta itse ylläpidettyä Linux-pohjaista sähköpostipalvelua, jota ei käyttänyt yksikään vastaajista. Keskisuuret yritykset olivat siis tyytyväisempiä käyttämiinsä palveluihin kuin mikro- tai pienet yritykset. Syynä saattaa olla se, että suuremmat yritykset käyttävät enemmän resursseja organisaa- tionsa järjestelmiin ja tietoturvaan. Office 365- ja G Suite -palvelut sisältävät oletuksena useita roskapostin torjuntatekniikoita, mutta konfiguroitavaa jää myös yritykselle itselleen (luku 5.8).

Vastanneet keskisuuret yritykset käyttivät monipuolisesti erilaisia tekniikoita viestin lähtee- seen tai sisältöön perustuvassa torjunnassa (kuva 21). Tekniikoiden käyttömäärät olivat kohtuullisen suuria vastaajamäärään suhteutettuna ja aiempiin yrityskokoihin verrattuna. Enemmistö vastaajista käytti yli 65 % kysytyistä tekniikoista. Bayesilainen suodatus ei päätynyt yrityskoon tyypillisimpään vastaukseen, mikä on ymmärrettävää, sillä sen integ- roiminen pilvipalveluihin ei ole täysin suoraviivaista ja vaatisi todennäköisesti Linux-pohjaisen edustapalvelimen. Puolet vastaajista ilmoitti kyllä käyttävänsä pilvipalvelupohjaista roskapostisuodatusta eri palveluntarjoajalta, jolloin on mahdollista, että bayesilaista suodatusta käytetään kyseisten palveluntarjoajan suodattimissa. Vastaajat eivät tarkentaneet, mitä pilvipohjaisia torjuntaratkaisuja he käyttivät, joten tätä ei voida selvittää tarkemmin.

Pienen vastausmäärän vuoksi keskisuurten yritysten tuloksissa esiintyi paljon poikkeustapauksia, joissa vastauksista ei voitu suoraan laskea yksiselitteistä tyyppivastausta kullekin kysytylle torjuntatekniikalle (liite 14). Tasapelitilanteissa kysytty tekniikka laskettiin aina mukaan tyypillisimpään vastaukseen, jos tekniikkaa käyttäviä vastaajia oli yhtä paljon kuin niitä vastaajia, jotka eivät käyttäneet tai muistaneet käyttävänsä kyseistä tekniikkaa. Esi- merkiksi kolmea tiettyä tekniikkaa käyttäviä oli vain kolmasosa vastanneista. Samalla kolmasosa vastaajista ilmoitti olevansa käyttämättä kysyttyjä kolmea tekniikkaa. Jäljelle jää- nyt kolmasosa vastaajista ei osannut ottaa kantaa suuntaan tai toiseen, jolloin tilanne tulkittiin tasapeliksi käyttöönottaneiden ja käyttöönottamattomien vastaajien välillä. Poikkeus- tapauksien, kuten tasapelien, suuren määrän vuoksi iso osa torjuntatekniikoista päätyi myös yrityskoon tyypillisimpään vastaukseen (liite 14). Yrityskoon ollessa suurempi poik- keusten esiintymisen todennäköisyys olisi ollut pienempi. Poikkeustapauksia ja niiden vaikutuksia tutkimusdatan käsittelyyn on kuvattu tarkemmin opinnäytetyön liitteessä 11.

Todennukseen pyrkiviä tekniikoita käytettiin myös kohtalaisen paljon vastaajien kokonais- määrään nähden (kuva 22). ARC-protokollaa käytti verkkotunnuksien ja lähtevän sähkö- postin todennuksen suojaukseen vain yksi vastaaja. Tämä pitää todennäköisesti paik- kansa, sillä vastaaja oli yrityskoon ainoa G Suite -käyttäjä (liite 14). Toisaalta hänen olisi pitänyt ilmoittaa käyttävänsä tekniikkaa myös viestin aitouden ja lähettäjän todennukseen, kuten Google palveluissaan tekee (ARC Specification for Email 2019a). Sender ID -käyt- täjiä oli vastauksissa yllättävän paljon, vaikka tekniikka ei ole virallinen internetstandardi (OpenSPF 2012). Pienissä yrityksissä tekniikkaa käytti vain hieman yli 10 % vastaajista (kuva 18), kun taas keskisuurissa yrityksissä käyttäjien määrä oli vähintään kolmasosa (kuva 22). Tutkimusdatasta ei ilmene, ovatko vastaajat sekoittaneet Sender ID:n johonkin toiseen tekniikkaan kuin RFC 4406 -luonnoksessa määriteltyyn protokollaan (IETF

2006b). Microsoft käytti aikoinaan Caller ID -protokollaa osoitteiden väärentämisen estä- miseksi, mutta sekään ei ole enää ajankohtaisessa käytössä ja on siten tuskin sekoittanut vastaajia (Leighton 2019).

DMARC-tekniikan käyttöönottomäärät eivät olleet keskisuurissa yrityksissä yhtä alhaisia DKIM-tekniikan käyttömääriin verrattuna kuin pienissä yrityksissä. Ainoastaan yksi vastaaja käytti DKIM-allekirjoituksia lähtevän sähköpostin todennuksen suojaukseen julkaise- matta DMARC-käytäntöä (liite 14).

Kyselylomakkeen vapaamuotoisissa kysymyksissä vastaajat tarkensivat muita käyttämi- ään torjuntakeinoja (liite 14). Kaksi vastaajaa käytti Office 365 -palveluun saatavia lisä- osia. Molemmat olivat samalla Office 365 -käyttäjiä eivätkä olleet valinneet yhdeksi käyttä- mäkseen torjuntatekniikaksi pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta, sillä sekä sähköpostipalvelu että sen lisäosa ovat Microsoftin tuotteita. Keskisuurten yritysten tarkkaavaisuus vastausvaihtoehtoja antaessaan oli vastausten perusteella ilmeistä, kun taas pienemmissä yrityskoissa vastausvirheet johtivat paikoittain tulosten epätarkkuu- teen (luku 10.2).

10.1.4 Suuryritykset (250 henkilöä tai enemmän)

Kaikki suuryritysten puolesta vastanneet toimivat eri rooleissa yrityksissään. Suuryritysten tyypillisimmäksi vastaajaksi katsottiin lopulta tietohallintojohtaja tai -päällikkö, sillä molemmat esiintyivät vastauksissa kerran (taulukko 9). Niiden työkuvat katsottiin riittävän sa- mankaltaisiksi. Tästä syystä ne sopivat tyypillisimpään vastaukseen parhaiten, sillä muut- kaan vastausvaihtoehdot eivät esiintyneet tuloksissa yhtä kertaa useammin. Keskisuurten yritysten tavoin kaikki vastaajat toimivat yrityksissään IT- tai teknologiapainotteisissa työ- tehtävissä (liite 15). Yli 250 hengen yrityksillä on varmasti oma IT-osastonsa vähintään ul- koistettuna, mikä todennäköisesti puuttunee monista mikro- tai pienistä yrityksistä.

Suuryrityksissä korostui myös pilvipalvelupohjaisten sähköpostipalvelujen suosio (kuva 23), mikä on tulosten perusteella kasvanut aina yrityksen henkilöstömäärän kasvaessa. Toisaalta vastauksissa olisi voitu odottaa esiintyvän myös enemmän itse ylläpidettyjä palveluratkaisuja, joissa yrityksillä olisi paremmat puitteet palvelujen ylläpitoon ja tietosuo- jaan. Suuryritykset ovat myös mahdollisesti vaikuttaneet alalla jo pitkään, jolloin heidän nykyiset palveluratkaisunsa voivat olla jäänne ajalta, jolloin varteenotettavia pilvipalvelupohjaisia sähköpostipalveluja ei ollut markkinoilla. Laajojen palvelinympäristöjen migraa- tiot uusiin pilvipalvelumalleihin saattaisivat olla työläitä ja hankalia, jolloin yritykset mahdol-

100 lisesti vain pitäytyisivät nykyisissä tutuissa ratkaisuissaan. Varsinkin Linux-pohjaisten säh- köpostipalveluratkaisujen vähäinen määrä suuremmissa yrityksissä yllätti edellä mainituista syistä. Isoilla yrityksillä on todennäköisesti suuremmat resurssit ja omat IT-osastonsa, jotka voisivat hoitaa palveluiden ylläpidon ja kehitystoimet. Itse ylläpidetyillä palve- luilla olisi ehkä mahdollista toteuttaa pilvipohjaista tarjontaa yksilöllisempiä ja tehokkaam- pia ratkaisuja.

Toisaalta yritykset todennäköisesti haluavat yksinkertaistaa IT-ympäristönsä mahdollisimman harvan palveluntarjoajan palveluihin ja vähentää ylläpidon taakkaa omalle henkilös- tölleen. Samalla, jos palveluntarjoajalta tarvitaan muita toimistotyökaluja joka tapauksessa, voisi olla järkevää maksaa yhtenäisestä lisenssistä, joka kattaa kaikki tarvittavat palvelut samalla kuukausimaksulla. Esimerkiksi Office 365 E3 -lisenssiin kuuluu Microsof- tin Office-sovelluksien työpöytäversiot, yrityssähköposti Exchange Online -palvelun muodossa sekä muita yritysten usein käyttämiä pilvipalveluita, kuten SharePoint. E3 -lisenssin käyttäjäkohtainen hinta on 19,70 € kuukaudessa. Vaihtoehtoisesti Office 365 ProPlus -lisenssin saa 12,80 € kuukausihintaan, mutta siihen ei kuulu yrityssähköpostia, eikä Share- Pointin kaltaisia palveluita. Ainoastaan Officen työpöytäohjelmat ja OneDrive kuuluvat ti- laukseen. Monille yrityksille voisi siis olla perusteltua maksaa 6,90 € enemmän jokaista käyttäjää kohden, jos kaikki palvelut saadaan saman palveluntarjoajan ja palveluportaalin kautta, eikä erillisille sähköpostipalveluille ole tarvetta. (Microsoft 2019k.)

G Suite -palvelulla oli yhtä paljon käyttäjiä suuryritysten keskuudessa kuin Office 365 -palvelulla (kuva 23). Tämä on yllättävää, sillä vaikka G Suite sisältää perusohjelmat henkilös- tölle, se ei tarjoa kaikkia Officen tarjoamia tietoturva- ja tietosuojaominaisuuksia, joihin tä- mänkokoisten yrityksen luulisi kiinnittävän huomiota (Bralin 2019). Esimerkiksi tietovuoto- jen lailliset ja taloudelliset seuraamukset voivat olla niin suuria, että kynnys taloudellisen lisäpanostuksen hankkimiseksi laajempien tietosuojaominaisuuksien saamiseksi on ma- tala. Microsoft on kehittänyt Office 365 -palvelun oletustoimintojen lisäksi useita Googlen palveluista puuttuvia tietosuojaa parantavia lisäominaisuuksia muun muassa Office 365- ja Azure Advanced Threat Protection -palveluiden muodossa (Microsoft 2018d). Edellä mainituista syistä Office 365 -palvelun suosio G Suite -palveluun verrattuna luulisi olevan merkittävästi suurempaa juuri keskisuurten ja suuryritysten toimialueympäristöissä.

Suuryritysten käyttämistä palveluista G Suite sai korkeimman tyytyväisyyden keskiarvon 4,8 (kuva 24). Office 365 -palvelun tyytyväisyyden keskiarvo 3,8 (kuva 24) oli kaikista yri- tyskoista heikoin suuryritysten vastauksissa, vaikka Officen olisi voitu luulla soveltuvan paremmin tämänkokoisille yrityksille edellisissä kappaleissa esitettyjen huomioiden vuoksi.

101

On tosin taas huomattava, että vastaajia oli vain viisi (taulukko 9), jolloin tulosten yleistä- minen kaikkiin suuryrityksiin ei ole suositeltavaa. Aihetta käsitellään tarkemmin tilastolli- sesta näkökulmasta opinnäytetyön luvussa 10.2.

Suuryritykset olivat ainoa tutkittava joukko, jossa ei ollut vähintään yhtä käyttäjää jokaiselle kyselylomakkeessa kysytylle torjuntatekniikalle (kuva 25). Tekniikoiden käyttömäärät vastaajamäärään suhteutettuna olivat pieniä verrattuna keskisuuriin yrityksiin (kuva 21). Ainoastaan neljää tekniikkaa käytti yli kolmasosa suuryritysten vastaajista (kuva 25). Esi- merkiksi SMTP-liikenteen suodatusta käytti vain kaksi vastaajaa ja sähköpostin sisällön suodatusta vain yksi. Todennäköisesti kyseisten tekniikoiden käyttömäärät ovat paljon suurempia. SMTP-liikenteen suodatus kuuluu sähköpostipalvelimien perustoimintoihin. Jos liikennettä ei suodatettaisi mitenkään, palvelimet toimisivat avoimina välityspalveli- mina, mikä tarkoittaisi lisääntynyttä roskapostitusta palveluntarjoajan palvelimelta (IETF 1999a, 8). Kaikki tunnetuimmat palveluntarjoajat suorittavat tyypillisesti SMTP-liikenteen ja sisällön suodattamista edes jossain määrin (Google 2019a; Microsoft 2019d).

Suuryritysten pienen vastausmäärän vuoksi tutkimuksen tuloksissa esiintyi paljon poikkeustapauksia, joissa vastauksista ei voitu suoraan laskea yksiselitteistä tyyppivastausta kullekin kysytylle torjuntatekniikalle (liite 15). Sama ongelma esiintyi kaikissa muissakin yrityskoissa, mutta se oli suurinta suuryritysten tuloksissa. Poikkeustapauksien, kuten tasapelien, tuloksia tulkittiin liitteessä 11 määritellyin menetelmin.

Suuryritykset olivat ainoa yrityskoko, jossa DKIM- ja DMARC-käyttäjiä oli toisiinsa nähden yhtä paljon verkkotunnuksien ja lähtevän sähköpostin todennuksen suojauksessa (kuva 26). ARC-käyttäjiä ei ollut yhtään, vaikka G Suite -käyttäjiä oli 40 % vastaajista (kuva 23). Kuten aiemmissa luvuissa on todettu, Google käyttää oletuksena ARC-protokollaa Gmail- ja G Suite -palveluissaan, jolloin protokollaa käyttäviä tulisi olla vastauksissa yhtä monta kuin G Suite -palvelua käyttäviä vastaajia (ARC Specification for Email 2019a).

10.1.5 Kaikki yritykset

Kaikkien yritysten tyypillisimpään vastaukseen vaikutti suuresti pienempien yrityskokojen vastaukset, joita oli tutkimuksessa suhteellisesti paljon enemmän. Kyselylomakkeeseen vastannut henkilö ei ollut yhdenkään keskisuuren tai suuryrityksen kohdalla yrityksen toimitusjohtaja. Toimitusjohtaja oli silti kaikkien yritysten vastauksista laskettu tyyppivastaus (taulukko 10), sillä kyselyyn vastanneita toimitusjohtajia oli merkittävä määrä mikro- ja pie- nissä yrityksissä (liitteet 12 ja 13).

102

Tutkimuksen hypoteesi sähköpostipalvelujen siirtymisestä pilvipalvelupohjaisiksi saa tu- kea tutkimuksen tuloksista. Noin 75 % kaikista käytetyistä sähköpostipalveluista oli pilvipalvelupohjaisia (kuva 27). Office 365 oli käytetyin palvelu, mikä oli odotettavissa sen muun palvelutarjonnan vuoksi. Palvelu on myös helposti integroitavissa yritysten paikalliseen Windows-toimialueeseen, jolloin käyttäjät voivat kirjautua samoilla salasanoilla ja tunnuksilla kaikkiin yrityksessä käytettäviin palveluihin (Microsoft 2019j).

Itse ylläpidettyjen Windows-pohjaisten sähköpostipalveluiden vähäinen alle 5 % osuus (kuva 27) oli myös ennakoitavissa. Esimerkiksi paikallinen Microsoft Exchange-palvelinohjelmisto ei enää vaikuta järkevältä ratkaisulta pilvipalveluiden etuihin verrattuna (Cohen 2019). Jos silti jostain syystä edellytetään paikallista palvelua, niin Linux-pohjaiset ratkaisut ovat kustannustehokkaampia, mikä myös todennäköisesti vaikutti niiden yli 10 % osuuteen (kuva 27). Microsoft Exchange edellyttää sekä käyttöjärjestelmälisenssin että käyttäjä- tai laitekohtaiset CAL-lisenssit, kun taas esimerkiksi vapaan ohjelmiston Postfix on täysin ilmainen käyttäjäkoosta huolimatta (Office 2019b; Postfix 2019f).

Kaikkien yritysten tulosten perusteella G Suite -käyttäjät olivat kaikista tyytyväisimpiä niistä ennalta määritellyistä sähköpostipalveluista, jotka tuotiin esille (kuva 28). Office 365 -käyttäjät sen sijaan olivat toisiksi tyytymättömimpiä, tosin vain 0,2 asteikon erotuksella G Suiteen. Palveluiden tyytyväisyysarvoja yhdisti se, että molemmat sähköpostipalvelut toimivat yhtä luotettavasti oikeiden roskapostien suodatuksessa kuin olematta merkitsemättä aitoja sähköpostiviestejä roskapostiksi. Muiden palvelujen kyvyt torjua roskapostia ja erottaa aidot sähköpostit roskapostista saattoivat vaihdella toisistaan rajusti. Voitaneen siis sanoa, että G Suite ja Office 365 suoriutuvat tasaisen luotettavasti eri roskapostituksen ongelmista. Itse ylläpidetyt Windows- ja Linux-pohjaiset palvelut vaativat taas enemmän ylläpitoa ja konfigurointia yrityksen omalta IT-henkilöstöltä. Tällöin palvelujen suoriutumi- nen on paljolti henkilöstöstä riippuvaista, jolloin ratkaisujen palvelutyytyväisyyteen on vaikuttanut henkilöstön osaamistaso enemmän kuin esimerkiksi pilvipalvelupohjaisissa rat- kaisuissa.

Muiden ennalta määrittelemättömien palvelujen käyttäjätyytyväisyydestä on vaikea tehdä johtopäätöksiä niiden käyttäjämäärien vähyyden vuoksi. Tarkastelemalla niitä vastaajien esille tuomia palveluita, joilla oli enemmän kuin yksi käyttäjä, D-Fence sai kolmelta käyttä- jältään täydellisen keskiarvon 5 (kuva 35). Vastausten perusteella palvelua voidaan pitää tehokkaana. Toisaalta D-Fence eSec on erillinen sähköpostin turvapalvelu eikä sähköpos- tipalvelu. Se ei sisällä postilaatikoita käyttäjille tai sähköpostin siirto- ja toimitusohjelmia. Tämän perusteella on siis mahdollista, että vastaajat ovat sekoittaneet kysymyksessä ky-

103 sytyn asian. D-Fencen verkkosivuilta ei suoraan selviä, tarjoavatko he edes tavallisia säh- köpostipalveluja. Käyttäjät saattoivat siis todellisuudessa käyttää sisäisiin sähköpostipal- veluihinsa esimerkiksi Microsoftin Office 365 -palvelua mutta ovat antaneet kysymykseen väärän vastauksen. D-Fence soveltuisi paremmin vastaukseksi kysymyksessä, jossa kartoitettiin yritysten käyttämiä torjuntatekniikoita. Siinä vastaajat olisivat voineet ilmoittaa käyttävänsä vaihtoehtoa ”pilvipohjainen roskapostisuodatus eri palveluntarjoajalta”. Hei- koimman keskiarvon antoivat webhotellien sähköpostipalveluja käyttäneet vastaajat (kuva 35). Tämä on odotettavaa, sillä niiden sähköpostipalvelut kuuluvat monesti muun muassa verkkosivutilan yhteyteen samalla kuukausiveloituksella.

Roskapostia sen sisällön ja lähteen perusteella torjuvien tekniikoiden käyttäjämääriä tarkasteltaessa havaitaan, että vastaajat eivät kovin hyvin tietäneet käyttämistään torjuntatekniikoista (kuva 29). Tutkimuksessa ei ollut oletustekniikoiden ohella yhtään sellaista torjuntatekniikkaa, jota olisi käyttänyt vähintään puolet vastaajista. Fyysiset roskapostisuodattimet olivat kaikista vähiten käytetty tekniikka. Tämä on loogista, sillä iso osa vastaajista oli jo siirtänyt sähköpostipalvelunsa pilvipalvelupohjaisiksi (kuva 27). Tällöin roskapostinsuodatus tapahtuu myös pilvessä, eikä fyysisille suodattimille ole tarvetta. Pilvipal- velupohjaista suodatusta eri palveluntarjoajalta käytti 17 yritystä eli kohtalaisen suuri osuus kaikista 74 vastaajista (kuva 29). Todellisuudessa käyttäjämäärä on suurempi, sillä kaikki vastaajat eivät muistaneet ilmoittaa käyttävänsä pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta, vaikka määrittelivät juuri sellaisen lomakkeen vapaamuotoisissa ky- symyksissä.

Nolisting oli toiseksi vähiten käytetty torjuntatekniikka (kuva 29), mikä on osaltaan erikoista tekniikan helpon käyttöönotettavuuden vuoksi. Toisaalta se oli myös bayesilaisen suodatuksen ohella yksi heikoiten tunnettuja tekniikoita kaikista kysytyistä torjuntatekniikoista, mikä osaltaan selittää sen vähäisiä käyttömääriä (kuva 33). Tekniikan tehokkuus tulee todennäköisesti laskemaan tulevaisuudessa, mutta siitä on vielä havaittu olevan hyötyä yhteistyössä muiden tekniikoiden kanssa (Pagani 2016). Nolisting oli samalla myös vastaajien mielestä kiinnostavin niistä tekniikoista, joista he eivät olleet vielä käyttöönotta- neet. Viisi vastaajaa ilmoitti haluavansa käyttää sitä roskapostin torjuntaan (kuva 31). On mahdollista, että useat vastaajat eivät olleet tienneet koko tekniikasta, ennen kuin he luki- vat siitä tutkimuksen kyselylomakkeesta.

Kaikkien yritysten vastauksista ilmeni, että DMARC-tekniikan käyttöönottomäärät ovat liian alhaisia SPF- ja DKIM-tekniikoihin nähden (kuva 30). Luvuissa 6.1 ja 6.3 olen tuonut esille syitä siihen, miksi SPF- ja DKIM-tekniikat eivät ole yksinään riittäviä sähköpostivies- tin ja sen lähettäjän todennukseen. Tarkistusten ohittaminen on helppoa, jos yritys ei ole

104 käyttöönottanut DMARC-käytäntöä. Yksikään kyselylomakkeen ennalta määritellyistä säh- köpostipalveluista ei oletuksena käyttöönota DMARC-tekniikkaa yrityksen verkkotunnuksien ja lähtevän sähköpostin suojaukseen. Ne suorittavat kyllä DMARC-tarkistuksia saapuvalle sähköpostille, mutta DMARC-käytäntöjen käyttöönotto ja julkaiseminen on täysin yrityksen omalla vastuulla (Google 2019d; Microsoft 2019h). Vain noin viidesosa tutkimukseen osallistuneista yrityksistä käytti DMARC-tekniikkaa verkkotunnuksiensa ja lähtevän sähköpostin todennuksen suojaukseen (kuva 30). ARC-protokollan käyttömäärät olivat alhaisia G Suite -käyttäjien lukumäärään nähden, sillä todellisuudessa kaikki Googlen G Suite -palvelua käyttävät hyödyntävät myös ARC-protokollaa (ARC Specification for Email 2019a).

Haluttuja käyttöönotettavia viestin lähteeseen tai sisältöön perustuvia torjuntatekniikoita tarkasteltaessa havaitaan, että kokonaisuudesta ei oikeastaan erotu nolisting-tekniikan ohella muuta sellaista tekniikkaa, jota vastaajat erityisemmin haluaisivat käyttää (kuva 31). Sen sijaan todennukseen pyrkivissä tekniikoissa haluttavuus oli monien vaihtoehtojen kohdalla huomattavasti suurempaa (kuva 32). DMARC oli selkeästi halutuin tekniikka ja hyvästä syystä, sillä ainoastaan DMARC suojaa yritystä sähköpostiviestin otsaketietojen ”From”-kentän väärennöksiltä (IETF 2015a, 8-10). Suuri osa vastaajista käytti SPF- ja DKIM-tekniikoita ilman DMARC-käytäntöä, mikä lisää yrityksen alttiutta sähköpostiosoittei- den väärentämisyrityksille (Whalen 2018). SPF oli vähiten haluttu tekniikka, mikä on to- dennäköisesti seurausta siitä, että iso osa pilvipalveluista käyttöönottaa sen ainakin osittain oletuksena (Google 2019e; Microsoft 2018a). Käyttöönotto on myös manuaalisesti helppoa luvun 6.1 mukaisesti. DKIM oli toiseksi halutuin tekniikka. Osa pilvipohjaisista sähköpostipalveluista käyttöönottaa myös DKIM-allekirjoitukset oletuksena tietyin rajoit- tein. Siitä huolimatta on aina suositeltavaa, että yritys käyttää organisaation omaa DKIM- avainparia (Google 2019f).

Harmaalistaus oli vastaajien keskuudessa tunnetumpi torjuntatekniikka kuin sähköpostin sisällönsuodatus (kuva 33), mikä oli erikoista, sillä nimensä mukaisesti sisällönsuodatuk- sella viitataan kaikkiin tapoihin, joilla viestejä suodatetaan niiden sisällön, kuten tekstin ja liitetiedostojen perusteella. Nolisting ja bayesilainen suodatus olivat vähiten tunnettuja tekniikoita, mikä on odotettavissa, sillä niiden nimistä on vaikea päätellä mitään tuntematta aihepiiriä tarkemmin. Bayesilaista suodatusta on myös vaikeaa integroida itse palveluntarjoajan pilvipalvelupohjaisiin sähköpostipalveluihin, mikä osaltaan selittää, miksi sitä ei tun- neta pilvipalveluiden yhteydessä enemmän.

105

Heikoiten tunnettuja todennukseen pyrkiviä tekniikoita olivat kaikkien yritysten vastauksissa ARC ja Sender ID (kuva 34). Tämä on odotettua, sillä kumpikaan mainituista proto- kollista ei ole vielä laajamittaisessa käytössä. ARC on uusi ja lähinnä Googlen käyttämä, eikä Sender ID ole päätynyt laajaan käyttöön lisensointi- ja yhteensopivuusongelmien takia (OpenSPF 2012). Kyseisiin tekniikoihin nähden esimerkiksi SPF ja DKIM ovat ylei- sessä käytössä. DMARC-tekniikan heikohko tunnettavuus (lähes 10 % vastaajista) selitty- nee myös sen uutuusarvolla. DMARC määriteltiin IETF-organisaation RFC 7489 -standardissa vasta neljä vuotta sitten (IETF 2015a).

10.2 Tulosten luotettavuus ja tutkimuksen onnistuminen

Tutkimuksen vastausprosentti oli lähes 25 % kyselylomakkeen vastaanottajista. Tutki- musta voidaan pitää vastausmäärien ja yritysten osallistumisen osalta onnistuneena. Tu- lokset ovat luotettavimpia mikro- ja pienten yritysten kohdalla, sillä vastaajamäärät olivat niissä huomattavasti suurempia (taulukot 6 ja 7). Keskisuurista yrityksistä sen sijaan kyselytutkimukseen vastasi vain kuusi ja suuryrityksiä vain viisi (taulukot 8 ja 9). Kyseisten yrityskokojen vastaajien katoon vaikutti todennäköisesti se, ettei Suomessa ole useita todella suuria IT-palveluntarjoajia. Tätä ei pystytty todentamaan tutkimuksen aikana, sillä tietoa erikokoisten yritysten jakautumisesta tutkimuksen perusjoukossa ei ollut saatavissa. Tässä mielessä kato on väärä termi ongelmalle, sillä keskisuuria ja suuryrityksiä oli mahdollisesti tutkimuksen alkuperäisessä näytteessä liian vähän. Tämä oli odotettavissa jo osallistujia kartoittaessa yritysten verkkosivujen kautta, mistä pystyttiin tekemään ennak- kopäätelmiä potentiaalisten osallistujien yrityskoosta. Suurin osa yrityksistä vaikutti jo tuolloin verkkosivujensa perusteella työllistävän alle 50 työntekijää. Tästä syystä suurempien yritysten osallistuminen oli mahdollisesti jopa yllättävän suurta tutkimuksen näytteen ja- kautumiseen nähden.

Tulosten jakautumisen kannalta olisi ollut järkevämpää sisällyttää kyselytutkimuksen näyt- teeseen eri yrityskokoja niiden osuuksia kaikista suomalaisista IT-alan yrityksistä vastaa- vissa suhteissa. Nyt yritysten kerääminen toteutettiin harkinnanvaraisesti, ja kriteereinä olivat lähinnä yrityksen toimiala ja -paikka. Toisaalta syy tälle oli se, että osallistujien tarkempi valikointi olisi kasvattanut opinnäytetyön työmäärää suhteettoman paljon asetettui- hin tavoitteisiin nähden. Ongelmaksi olisi myös muodostunut se, ettei pääosa yrityksistä kerro tarkkaa yrityskokoaan julkisesti. Tällöin valtaosan osallistuminen tutkimukseen olisi hylätty tarkemman yrityskoon puuttuessa.

Jos tutkimuksessa olisi käytetty satunnaista otosta, niin riittävän suuri otoskoko olisi taan- nut, että kerätyt tulokset kuvaisivat perusjoukkoa tilastollisesti merkittävällä tarkkuudella

106

(Sheldon 2009). Koska tutkimuksessa käytettiin harkinnanvaraista näytettä otoksen sijaan, tulosten perusteella ei voida tehdä yhtä luotettavia yleistyksiä kaikkiin suomalaisiin IT-alan yrityksiin. Näyte perustuu yritysten ilmoittamiin tietoihin ja mielipiteisiin, joilla on arvoa tutkimuksen kannalta. Jos näytteeseen osallistuneita yrityksiä on kuitenkin liian vä- hän, tulokset edustavat vain hyvin pientä osaa perusjoukosta, mikä vaikuttaa tutkimuksen luotettavuuteen. Vaikutusta on vaikea selvittää, sillä ei ole tietoa siitä, miten eri yrityskoot jakautuivat perusjoukossa. (Taanila 2019d.)

Tutkimuksessa tyydyttiin harkinnanvaraiseen näytteeseen otoksen sijaan, sillä valittujen yritysten edustavuudesta suhteessa perusjoukkoon ei ollut mitään taetta (KvantiMOTV 2003). Näyte on otantakehikosta valittu osa, johon ei lasketa katoa ja jota hyödynnetään silloin, kun tutkittavat valitaan muuten kuin sattumaa hyödyntäen. Näytteen keräämisessä käytettiin tutkijan harkintaa, jolloin sitä ei voida kutsua otokseksi, joka edellyttäisi sattu- manvaraisuutta esimerkiksi arpomalla osallistujat valmiista yhteystietolistasta. Yritysten kartoituksen yhteydessä heidän verkkosivujensa pohjalta tehtiin päätelmiä yrityksen liiketoiminnan tilasta. Välillä oli esimerkiksi hankala tulkita, oliko yrityksen pääpaino IT-alalla tai Suomessa tai oliko yritys enää edes toiminnassa. Näissä tapauksissa tutkija päätti kyseisen yrityksen ohittamisesta. Näytteestä ei yleensä voidakaan tehdä yhtä luotettavia yleistyksiä laajempaan perusjoukkoon kuin otannasta. Tulosten yleistämiseen laajemmalle perusjoukolle täytyy ainakin suhtautua varauksella. (Taanila 2019d; 2019e.)

Tutkimuksen perusjoukkona toimivat suomalaiset IT-alan yritykset, mutta lopullinen näyte otettiin otantakehikosta, johon kuuluivat ne yritykset, jotka olivat helpoimmin löydettävissä julkisen verkon hakukoneilla. Tällöin tutkimuksen otantakehikkoon on vaikuttanut muun muassa yritysten kartoituksessa käytetyt hakusanat ja yritysten verkkosivujen hakukoneoptimointi. Koska otantakehikko ei ole välttämättä sisältänyt koko tutkimuksen perusjoukkoa, kyselytuloksiin on saattanut sisältyä peittovirhe (Taanila 2019a). Tämä on osaltaan voinut aiheuttaa näytteen vinoutumista, jolloin näyte ei kuvaa kaikkia suomalaisia IT- alan yrityksiä. (Taanila 2019d.)

Tutkimustulosten luotettavuuteen liittyi myös muita riskejä. Yksi näistä oli vastauksien kak- soiskappaleet samoista yrityksistä. Linkki kyselylomakkeeseen lähetettiin aina ensisijaisesti yrityksen IT-asioista vastaavalle henkilölle. Henkilöstönsä verkkosivuillaan listaavia yrityksiä oli lopullisista vastaanottajista vain noin 130. Tällöin loput noin 180 vastaanotta- jaosoitetta olivat yrityksen asiakas- tai tukipalvelun sähköpostiosoitteita. Kyselylomakkeen päätyminen asiasta vastaavalle henkilölle yrityksessä oli kyseisten vastaanottajien kohdalla siis asiakaspalvelijan käsissä. Kyselylomakkeet lähetettiin kahdessa erässä, joista

107 jälkimmäinen toimi muistutuksena tutkimukseen osallistumisesta. On mahdollista, että lo- make on päätynyt toisessa erässä samassa yrityksessä eri henkilölle, joka ei ennestään ollut kuullut tutkimuksesta. Tuolloin hän on saattanut vastata kyselyyn, vaikka hänen kolle- gansa olisi jo vastannut siihen tutkimuksen ensimmäisessä erässä.

Edellä mainittu riski oli silti pienempi kuin alkuperäisessä suunnitelmassa, jossa tarkoituksena oli lähettää toisessa erässä kyselylomakkeet aina eri sähköpostiosoitteeseen kuin ensimmäisessä. Tavoitteena olisi ollut se, että kyselylomake huomioidaan ja siihen vastataan todennäköisemmin, jos asiaa käsittelee vähintään kaksi eri henkilöä samassa yrityk- sessä. Lomakkeeseen olisi voitu saada vastaus toiselta henkilöltä kyselytutkimuksen toisessa erässä, vaikka ensimmäinen vastaanottaja olisi jättänyt lomakkeen huomioimatta. Ajatuksesta luovuttiin lopulta, jotta vastauksien kaksoiskappaleiden esiintymiseltä vältyttäi- siin.

Optimaalista olisi ollut, jos jokaisen yrityksen IT-vastaavaa olisi pystytty lähestymään suoraan ilman välillistä toimijaa, kuten asiakaspalvelua. Lähestymisessä pyrittiin aina tavoitta- maan korkeassa johtoasemassa oleva tekninen henkilö. Tausta-ajatuksena oli se, että hän todennäköisemmin delegoisi ongelman alamaiselleen tilanteissa, joissa asia ei kuulu hänelle tai jossa hän ei osaa antaa tarkkoja vastauksia esitettyihin kysymyksiin. Alem- massa asemassa toimiva IT-asiantuntija olisi taas saattanut jättää lomakkeen kokonaan huomioimatta vastaavassa tilanteessa välttääkseen esimiestensä vaivaamisen asialla.

Tulosten toinen mahdollisesti merkittävä virhelähde syntyy siitä, että tulokset esitettiin siinä muodossa, jossa tutkimukseen osallistuneet yritykset olivat ne antaneet. Tuloksista ei siis ole korjattu mahdollisia epätarkkuuksia tai virheellisiä vastauksia, jotka ovat voineet olla seurausta vastaajan tietämättömyydestä tai epähuomiosta.

Tutkimusdatan käsittelyn aikana harkittiin sitä, että tuloksista olisi tehty erillinen taulukko- tiedosto, jossa havaitut virheet olisi korjattu. Merkittävin syy sille, miksi vastauksien manu- aalista käsittelyä harkittiin, oli vastausten epätarkkuudet yritysten käyttämiin sähköposti- palveluihin kuuluvien oletustekniikoiden kanssa. Tutkimuslomakkeen kysymyksissä 6-8 kartoitettiin vastaajayrityksen käyttämiä torjuntatekniikoita (liite 9). Yhtenä kysyttynä tor- juntatekniikkana oli kussakin kysymyksessä ”Käyttämäämme palveluun oletuksena kuuluvilla tekniikoilla”. Vastaajia kehotettiin valitsemaan käyttämikseen torjuntatekniikoiksi vä- hintään käyttämänsä palvelun oletustekniikat, jos he eivät olleet varmoja muista kohdista. Muut kysytyt torjuntatekniikat olivat yksilöllisempiä, eivätkä kaikki vastaajat olisi osanneet

108 kertoa, käyttävätkö he juuri kyseisiä tekniikoita vai eivät. He olisivat silti kehotusten mukaisesti ilmoittaneet käyttävänsä palveluunsa kuuluvia oletustekniikoita, joihin sisältyy merkit- tävä osa muista kysytyistä torjuntatekniikoista.

Ongelmaksi datan tulkinnan kannalta muodostui se, että kaikkiin mahdollisiin sähköposti- palveluihin olisi pitänyt tutustua tarkkuudella, jolla vastaajien tekemät virheet oltaisiin voitu korjata. Esimerkiksi kaikkien yritysten G Suite -käyttäjät ilmoittivat käyttävänsä palveluun kuuluvia oletustekniikoita, joihin kuuluu muun muassa ARC-protokolla (ARC Specification for Email 2019a). Silti harva G Suite -käyttäjä ilmoitti erikseen käyttävänsä ARC-protokollaa, mikä vääristi tuloksia, kun eri torjuntatekniikoiden käyttömääriä analysoitiin (liite 16).

Vastausten korjaaminen olisi voinut parantaa tutkimuksen reliabiliteettia (Taanila 2019a), mutta niiden korjaaminen ei olisi ollut helppoa. Vastaajat käyttivät yhteensä 11 eri sähkö- postipalveluratkaisua, joista osa koostui useiden eri sähköpostipalvelujen yhdistelmistä (kuva 27). Niihin kaikkiin sisältyvien torjuntatekniikoiden selvittäminen luotettavasti olisi osoittautunut liian työlääksi opinnäytetyön ajankäytön suhteen. Todennäköisesti palveluntarjoaja ei myöskään ole julkaissut tietoa tarpeeksi tarkasti, jotta sitä olisi voitu hyödyntää vastausten luotettavuuden korjaamisessa. Lopulta koko ajatus hylättiin, sillä se olisi lisän- nyt inhimillisten virheiden mahdollisuutta datan käsittelyn aikana. Koettiin, että on turvalli- sempaa esittää tulokset sellaisinaan, joina vastaajat olivat ne antaneet, kuin lähteä muok- kaamaan niitä oletuksien ja julkisesta verkosta löytyvien tietojen pohjalta, jotka eivät vält- tämättä ole ajan tasalla. Tällöin myös tutkimustuloksissa asiasta johtuvat virheet ovat seurausta vastaajista itsestään eivätkä vastausten käsittelijästä.

Vastaava virhe esiintyi yritysten käyttämien pilvipalvelupohjaisten roskapostisuodattimien kohdalla, kun vastaajat tarkensivat käyttämiään pilvipalvelupohjaisia roskapostisuodattimia kyselylomakkeen vapaamuotoisissa vastauksissa. Oli vastaajia, jotka eivät kertoneet käyttävänsä pilvipohjaista roskapostisuodatusta eri palveluntarjoajalta, vaikka he myö- hemmin lomakkeen loppupuolella täsmensivät käyttävänsä juuri sellaista. Tällöin tutkimustulokset vääristyivät, sillä kaikkia kyseistä tekniikka käyttäviä ei laskettu kuvan 13 kaavioon. Alustavasti pilvipalvelupohjaista roskapostitorjuntaa eri palveluntarjoajalta ilmoitti käyttävänsä 17 yritystä, mutta vastausvirheiden korjaamisen jälkeen oikeaksi käyttäjä- määräksi paljastui 19 yritystä. Näillä luvuilla runsas 10 % torjuntatekniikan käyttäjistä ilmoitti siis virheellisesti, etteivät he käyttäneet sitä. Vastausten heikko reliabiliteetti vaikutti siten tutkimuksen validiteettiin, koska satunnaisia virheitä sisältävien vastausten tulkinta hankaloitti tutkittavien asioiden mittaamista (Taanila 2019b).

109

Itse kyselylomakkeesta saatiin vastaajilta hyvää palautetta. Ainoastaan yksi vastaanottajista ilmoitti olevansa kykenemätön vastaamaan kyselyyn tietoturvasyiden vuoksi. Lomak- keesta pyrittiin alun perin luomaan mahdollisimman tunkeilematon, jotta tietoturvahuolet eivät tulisi esteeksi vastaamiselle. Palautteen kerääminen alan asiantuntijoilta ja testikäyt- täjiltä oli myös tärkeää lomakkeen kysymysten muotoilemiseksi sellaisiksi, joista saatiin mahdollisimman paljon tietoa vastaajien käyttämistä torjuntatekniikoista. Yksi muutos tulosten tarkkuuden parantamiseksi olisi ollut vastauksen ”En tunne tätä tekniikkaa” muo- toilu kahdeksi eri vastaukseksi. Tutkimuksessa se ei nykyisessä muodossaan ottanut kantaa siihen, oliko vastaajalla kysytty tekniikka todennäköisesti käytössä vai ei. Vaihtoeh- toina olisi voinut olla esimerkiksi ”Emme käytä, emmekä tunne tätä tekniikkaa” ja ”En tiedä käytämmekö, koska en tunne tätä tekniikkaa”. Nykyisessä muodossaan vastauksen hyö- dynnettävyys tutkimustuloksia tarkasteltaessa oli verrattavissa vastaukseen ”En tiedä tai muista, käytämmekö”, sillä kumpikaan ei vahvistanut yrityksen käyttävän tai olematta käyttämättä kysyttyä tekniikkaa.

Yksi kyselylomakkeen vastausvaihtoehdoista oli myös ”En muista tai tiedä, käytämmekö”. Vastausvaihtoehto sisällytettiin lomakkeeseen mahdollisten virheiden eliminoimiseksi. Ei voitu olettaa, että kaikki vastaajat tuntisivat tutkimuksen aihepiirin täydellisesti. Monissa yrityksissä sähköpostipalvelimet saattavat olla otettu käyttöön kauan aikaa sitten, jolloin järjestelmäkonfiguraatioiden yksityiskohtien tunteminen voi olla hankalaa. Täten koettiin tärkeäksi, että vastaajille annettiin vaihtoehto, jossa ei ole riskiä väärinmuistamisesta, joka taasen vaikuttaisi vastausten reliabiliteettiin heikentävästi. (Taanila 2019b; 2019c.)

Kokonaisuudessaan tutkimus onnistui asetettujen tavoitteiden mukaisesti. Tutkimuksessa saatiin vastaukset opinnäytetyön johdannossa esitettyihin tutkimuskysymyksiin ja hypo- teesiin. Kyselylomake oli sisältönsä puolesta kattava, koska vastaajat eivät tuoneet esille sellaisia torjuntatekniikoita, joita lomakkeeseen tai opinnäytetyön tietoperustaan ei olisi si- sällytetty. Tuloksia kerättiin monipuolisesti, ja vastaajien osuus oli jopa odotettua suurempi, sillä vastaajien määrän ennakoitiin jäävän noin 10 % paikkeille kaikista kyselylomakkeen vastaanottajista. Lopullinen vastausprosentti oli lähes 25 % (luku 8.2), jolloin yritysten vastausaktiivisuus oli noin 15 prosenttiyksikköä odotettua suurempaa. Tulosten pohjalta voidaan tehdä suosituksia yrityksille ja avata mahdollisuuksia uusille tutkimuksille.

110

10.3 Suositukset yrityksille

Tutkimustulokset tukevat lähtöhypoteesia siitä, että sähköpostipalvelimet siirtyvät yhä enemmissä määrin pilveen. Pilvipalveluiden käyttömäärät muodostivat aina selkeän enemmistön tutkimukseen osallistuneiden yritysten vastauksista. Niitä käytti kaikkien yritysten joukossa noin 75 % vastaajista (kuva 27). Tutkimukseen perustuen en suosittelisi itse ylläpidettyjen Linux- tai Windows-pohjaisten sähköpostipalvelimien käyttöönottoa enää vuonna 2019. Poikkeustapauksena voisivat olla todella suuret yritykset, jotka ovat hyvin tietoisia omista erikoistarpeistaan. Esimerkiksi Linux-pohjaisilla sähköpostipalveluilla saataisiin enemmän vapauksia konfiguroinnin suhteen. Tämä luonnollisesti vaatisi, että yrityksessä on oma asiantunteva IT-tiimi, joka vastaa palveluiden päivittäisestä ylläpi- dosta. Muiden pienempien ja vähempiresurssisten yritysten vaikuttaisi kannattavan siirtää sähköpostipalvelut kokonaisuudessaan pilveen, jossa kustannukset ovat todennäköisesti ennakoitavissa paremmin. Pilvipalvelujen skaalattavuus ja ylläpito on myös huomattavasti helpompaa, eikä asiakkaan tarvitse kiinnittää huomiota palvelimien vikasietoisuuteen tai mahdollisiin laiterikkoihin (Cohen 2019). Jos käyttäjä ei ole tyytyväinen pilvipohjaisen säh- köpostipalvelun omaan roskapostisuodatukseen, toisilta palveluntarjoajilta on ostettavissa lisäpalveluita, jotka integroituvat suoraan yrityksen omiin palveluihin.

Tulosten perusteella suosittelisin mikroyrityksille Googlen G Suite -palvelun käyttöönottoa. Sen palvelutyytyväisyys oli kaikkia yrityskokoja tarkasteltaessa suurinta (kuva 28). Palve- lun ylläpito ja käyttöönotto on monien mielestä Officea yksinkertaisempaa muun muassa pelkistetympien ominaisuuksiensa sekä käyttöliittymänsä vuoksi (Donovan 2019). Enem- mistö mikroyrityksistä myös käytti G Suite -palvelua kuvan 11 mukaisesti, ja G Suite soveltuu hieman suuremmillekin yrityksille. Suosittelen silti pienille yrityksille Office 365 -palvelua, joka oli yrityskoon vastaajaenemmistön käytössä (kuva 15). Palvelun tietosuoja- ja tietoturvaominaisuudet sekä helppo integrointi yritysten Windows-toimialueisiin ovat myös mahdollisesti mikroyrityksiä suuremmille organisaatioille tärkeitä (Microsoft 2018d; 2019j). Esimerkiksi ainakin yksi pieni yritys ilmoitti käyttävänsä Office 365 Advanced Threat Pro- tection -lisäpalvelua (liite 13). Office 365 sisältää yrityssähköpostin ja kattavien tietosuoja ja -turvaominaisuuksien lisäksi kaikki muut tarvittavat toimisto-ohjelmat ja työkalut. Yrityk- set ovat Windows-toimialueineen kokemuksieni mukaan hyvin usein riippuvaisia Officen työpöytäsovelluksista, jolloin olisi käytännöllistä hankkia kaikki tarvittavat palvelut samalta palveluntarjoajalta ja samalla lisenssillä. Näistä syistä suosittelenkin Office 365 -palvelua myös keskisuurille ja suuryrityksille. Kaksi vastaajaa eli kolmasosa keskisuurista yrityk- sistä käytti Office 365- ja Azure ATP -lisäturvapalveluita Office 365 -palvelun ohella (liite 14), mikä viittaa niiden ominaisuuksien tärkeyteen suurempien yritysten näkökulmasta.

111

Sähköpostipalveluiden siirtyessä pilveen yritykset alkavat käyttää samalla myös palveluntarjoajan sähköpostipalvelimien tekemää SMTP-liikenteen suodatusta, vaikkei se suoraan käyttäjille ilmenekään. Muiden sähköpostipalvelimien tekemien yhteydenottojen suodatus esimerkiksi lähettäjän toimialueen olemassaolon varmistamiseksi on yleinen toimenpide, minkä vuoksi suosittelen niiden suorittamista sähköpostipalvelimilla (IETF 1999a, 4). Ei olisi esimerkiksi järkevää vastaanottaa sähköpostia lähettäjältä, jonka toimialuenimeä ei ole olemassa, koska lähettävä taho ei ole aito. DNS-pohjaisten mustalistojen käyttöönotto on myös kannattavaa, sillä listoja päivitetään jatkuvasti muiden organisaatioiden tekemien havaintojen pohjalta, jolloin tunnetut roskapostittajat estetään helposti. Sen sijaan en koe harmaalistauksen käyttöönottoa enää kannattavana sen muiden haittapuolien, kuten viiveen, vuoksi (Harris 2003). Roskapostittajien käyttämät ohjelmistot kehittyvät todennäköi- sesti ajan myötä yhä älykkäämmiksi, mikä voi heikentää roskapostitusohjelmistojen al- keellisuuteen perustuvan harmaalistauksen tehokkuutta (Harris 2003; Lundgren 2019). Nolisting-tekniikan toiminta perustuu harmaalistauksen tavoin roskapostittajan käyttämän ohjelmiston alkeellisuuden hyväksikäyttöön, jolloin sen suorituskyky oletettavasti heiken- tyy ajan myötä vastaavasti (Nolisting 2019). Toisaalta tekniikan käyttöönotto on hyvin yksinkertaista, ja käyttöönoton haittapuolet ovat mielestäni pieniä sen etuihin nähden (Nolis- ting 2019). Näistä syistä suosittelen nolisting-tekniikan kokeilua edes testausmielessä, vaikka sen tehokkuus olisikin heikentynyt.

Sähköpostin sisällönsuodatusta hyödynnetään kaikissa tunnetuimmissa pilvipalvelupohjaisissa sähköpostipalveluissa edes jollain tasolla (Google 2019a; Microsoft 2019d). Mene- telmä on tehokas ja käytännöllinen tapa torjua roskapostia, minkä vuoksi suosittelenkin, että yritykset luovat omia suodatussääntöjään ajankohtaisten huijausyritysten havaitse- miseksi. Bayesilainen suodatus on vain yksi esimerkki koneoppimiseen perustuvista tor- juntamenetelmistä, joiden käyttömäärät tulevat todennäköisesti kasvamaan tulevaisuudessa (Awad & Elseuofi 2011, 2-11). Itse ylläpidettyyn Linux-palvelimeen kannattaa ehdottomasti asentaa vapaan ohjelmiston SpamAssassin itselleen sopivilla roskapostin kyn- nysarvoilla. Fyysiset roskapostisuodattimet ovat oleellisia lähinnä paikallisesti ylläpidettyjä sähköpostipalveluja käyttäville eli vain noin 25 % tutkimukseen osallistuneille vastaajille, jotka ilmoittivat käyttävänsä paikallisia palveluratkaisuja (kuva 27). Kyseisille käyttäjille fyysiset suodattimet voivat olla tehokkaita ratkaisuja, jotka siirtävät roskapostisuodatukseen käytetyn resurssikulutuksen pois yrityksen omilta sähköpostipalvelimilta (Return Path 2019c).

Kaikkien yritysten sähköpostipalvelimien tulisi ehdottomasti tehdä SPF-, DKIM- ja DMARC-tarkistukset sisäänpäin suuntautuvalle postille osoitteenväärennös- ja tietojenkalasteluyritysten torjumiseksi (Whalen 2018). Samaten suosittelen yrityksiä julkaisemaan

112 toimialuenimelleen SPF-tietueen ja käyttöönottamaan DKIM-allekirjoitukset organisaatiolta lähtevään sähköpostiin, mikä sallisi vastaanottavia organisaatioita paremmin tarkistamaan postin alkuperän ja aitouden. Molempia tekniikoita käytettäisiin yhdessä DMARC-tekniikan kanssa, joka otettaisiin käyttöön ”p=reject”-käytännöllä. On suositeltavaa, että DMARC- tekniikan raportointiominaisuudet otetaan ensin käyttöön, jotta raportteja voidaan analysoida hyvissä ajoin ennen käyttöönottoa. Tällöin voidaan ennakoida mahdollisia käyttöön- ottoon vaikuttavia ongelmia (DMARC 2017). Sender ID ei ole ajankohtainen protokolla, sillä SPF ja DMARC ajavat yhdessä saman asian ilman Sender ID:n rajoitteita, kuten yh- teensopivuus- ja lisenssiongelmia (OpenSPF 2012). ARC on uusi lupaava protokolla, jonka kehitystä kannattaa pitää silmällä. Sen käyttöönotto ei ole vielä ajankohtaista, sillä harva palvelu tai vapaan ohjelmiston sähköpostipalvelin tukee sitä (ARC Specification for Email 2019b).

10.4 Tulosten hyödyntämismahdollisuudet

Tutkimuksen tuloksia voidaan hyödyntää yritysten sähköpostipalveluiden kehittämiseen sekä jatkotutkimuksiin. Vastaajayritykset voivat verrata omia vastauksiaan oman yrityskoon tyypillisimpään vastaukseen. Myös tutkimukseen osallistumattomat yritykset saivat vertailuarvon, jota he voivat käyttää omien ratkaisujensa ja käytäntöjensä arviointiin tutkimukseen osallistuneiden yritysten osoittamalla mittapuulla. Siten he tietävät, miten heidän roskapostin torjuntakeinonsa vertautuvat muihin samankokoisiin yrityksiin. Muiden vastaajien palvelutyytyväisyyksien perusteella vertaileva yritys voi harkita palveluntarjoajan vaih- tamista tai muiden torjuntatekniikoiden käyttöönottoa jo olemassa olevaan sähköpostipal- veluunsa.

Tutkimus luo myös perustaa mahdollisille myöhemmille tutkimuksille. Yksi aihepiiri jatko- tutkimuksille olisi tutkia DMARC-tekniikan käyttöönoton esteitä suomalaisissa yrityksissä. Tutkimustuloksia tarkasteltaessa on havaittavissa, että SPF-tietueita ja DKIM-allekirjoituksia käytti huomattavasti suurempi osa vastaajista kuin DMARC-tietueita (kuva 30). Vas- taajien joukossa oli siis yrityksiä, jotka olivat käyttöönottaneet esimerkiksi DKIM-allekirjoitukset toimialueeltaan lähteville viesteille mutta eivät olleet julkaisseet nimipalvelussa DMARC-tietuetta, jonka toiminta nojautuu SPF- ja DKIM-tekniikoiden tarkistuksiin ja pyrkii luomaan niihin lisäturvaa. Molemmissa tekniikoissa on omat käyttöönoton ongelmansa, jotka saattavat vaikeuttaa myös DMARC-käytäntöjen käyttöönottoja organisaatioissa. Tut- kimuskysymyksenä voisi siis esimerkiksi olla, että mitkä käytännön esteet vaikuttavat DMARC-käytäntöjen käyttöönottoon. Loppukäyttäjä ei ole kykenevä tekemään erotusta aidon ja väärennetyn osoitteen välillä, ja on siten erikoista, että jotkin yritykset eivät olleet

113 julkaisseet DMARC-tietuetta ”p=reject”-käytännöllä suojatakseen toimialuettaan otsaketietojen ”From”-kentän sähköpostiosoitteen väärennösyrityksiä vastaan. SPF- ja DKIM-tekniikat eivät yksinään tai edes keskenään tarjoa riittävää suojaa osoitteiden väärentämistä vastaan, kuten luvuissa 6.1.2 ja 6.3.3 on tuotu esille.

Yritykset ilmaisivat halutuimmaksi käyttöönotettavaksi torjuntatekniikaksi nolisting-tekniikan (kuva 31), jonka tehokkuutta moderneja roskapostitusohjelmistoja vastaan ei ole tutkittu riittävästi. Vuonna 2016 julkaistiin yksi tutkimus harmaalistauksen ja nolisting-tekniikan suorituskyvystä yleisimpiä haittaohjelmia vastaan (Pagani 2016). Torjuntatekniikan kiinnostavuuden takia ajankohtaisempi tutkimus tekniikan tehokkuudesta moderneja ros- kapostitusohjelmia vastaan voisi silti olla paikallaan.

Kolmas mahdollinen jatkotutkimuskohde voisi olla Office 365 -palvelun käyttäjien palvelu- tyytyväisyys. Office 365 oli käytetyin palvelu kaikista tutkimuksessa esille tuoduista sähkö- postipalveluista (kuva 27). Silti Office-käyttäjien tyytyväisyys oli toiseksi heikointa kaikista kysytyistä palveluista (kuva 28). Olisi siis mielenkiintoista tietää, mitkä tekijät tähän ovat mahdollisesti vaikuttaneet. Vastaajat eivät olleet tyytymättömiä mutta selvästi tyytymättö- mämpiä moniin muita palveluita käyttäneihin yrityksiin verrattuna.

Tarkka vertailu G Suite- ja Office 365 -palveluominaisuuksien välillä saattaisi myös olla ajankohtaista. Vastanneista 74 yrityksestä 31 % käytti Googlen G Suitea ja 38 % Micro- softin Office 365 -palvelua (kuva 27). Voitaisiin tutkia, mitkä tekijät ovat vaikuttaneet yritysten päätökseen valita jompikumpi palveluista ja kuinka paljon kyseisten kahden palvelun palveluntarjonta eroaa toisistaan vuonna 2019. Siirtyminen pilvipalveluihin paikallisista Windows- ja Linux-palveluratkaisuista näkyy tutkimustuloksissa, sillä yli 75 % kaikista vastaajista käytti jotain pilvipalvelupohjaista sähköpostipalvelua (luku 9.5.1). Täten olisi mielenkiintoista ymmärtää yrityksen valintapäätökseen vaikuttavia vaatimuksia.

Opinnäytetyön projektisuunnitelmassa tutkimuksen yhdeksi tavoitteeksi määriteltiin mittarin kehittäminen, johon yrityksen voisivat verrata omia käytäntöjään. Lopputuloksen tyypillinen vastaus kullekin yrityskoolle on pikemminkin vertailuarvo kuin mittari. Tuloksista voitaisiin silti harkita oikean mittarin luomista, jossa eri torjuntatekniikoiden käyttöönottojen ajankohtaisuudet kasvaisivat yrityksen henkilöstömäärän kasvaessa. Tutkimukseen osallistuneiden vastaajien määrä oli tosin suuremmissa yrityksissä liian vähäistä, jotta mitta- rista voitaisiin tehdä luotettavaa. Tutkimuksen tarkkuutta olisi voitu parantaa ositetulla otannalla eli ottamalla otos kustakin yrityskoosta siten, että otoskoot olisivat olleet suhteessa yrityskoon yritysmääriin. Tämä ei kuitenkaan ollut mahdollista, sillä yrityskokojen

114 jakaumat perusjoukossa eivät olleet etukäteen tiedossa. Ei siis esimerkiksi tiedetty, mon- tako keskisuurta yritystä suomalaisten IT-alan yritysten joukosta löytyy, jolloin ei voitu koota listaa kaikista suomalaisista IT-alan yrityksistä ja arpoa otantakehikkoa vaikkapa systemaattisella otannalla. (Taanila 2019d.)

Toisaalta tulee pohtia, onko yrityskoko edes oikea muuttuja aihepiirin vertailuun. Olisiko yrityksiltä pitänyt kysyä tarkempi toimiala? Esimerkiksi tietosuoja- ja tietoturvapalveluita ulkoistavat yritykset voivat ottaa asian huomattavasti vakavammin kuin esimerkiksi yleinen webhotellipalveluntarjoaja. Onko yrityskoolla edes merkitystä siihen, kuinka vakavasti yrityksen tulisi ottaa sähköpostipalveluidensa roskapostitorjunta?

10.5 Oma oppiminen

Opinnäytetyön aiheen valintaan vaikuttivat aiemmat työelämän kokemukseni IT-tuen asia- kaspalvelutehtävistä. Tuolloin havaitsin, että sähköpostiin liittyvät ongelmat korostuivat tu- kipyynnöistä usein, ja tunnistin tarpeen tutustua aiheeseen tarkemmin erityisesti roskapostituksen ja roskapostin torjunnan osa-alueilla, jotka muodostivat ison osan sähköpostin kulkuun liittyvistä ongelmatapauksista. Tukipyyntöjen selvittäminen vaati jatkuvasti pyyn- nön kohdistamista asiantuntevammalle kollegalle, minkä vuoksi koin aihepiiriin tutustumi- sen välttämättömäksi.

Tutkimusta tehdessäni tutustuin kattavasti sähköpostin ajankohtaisiin ongelmiin ja sähkö- posti-infrastruktuurin toimintaan sähköpostiliikenteen eri vaiheissa. Roskapostin torjuntaan perehdyin hyvissä ajoin ennen opinnäytetyön aloitusta, mikä auttoi tietoperustan aihealu- eiden ja kyselylomakkeen kysymysten suunnittelussa. Tämä näkyi jo projektisuunnitelman aikataulussa, jossa toin pääasiassa esille samat aihepiirit, jotka sisällytin lopulliseen opin- näytetyöraporttiin. Työni suunnittelu ennakoivasti ennen opinnäytetyöprosessin virallista aloitusta mahdollisti projektin toteutumisen aikataulussa ilman suurempia ongelmia. Sa- maa prosessia tulen käyttämään myös myöhemmissä projekteissa mahdollisten jatko- opintojen aikana.

Kyselylomakkeen kehittämiselle tuli kiire projektin alkuvaiheissa, sillä tunnistin kesälomat haitalliseksi tekijäksi potentiaalisten vastaajien aktiivisuudelle. Lomakkeen sisältö ei silti ollut täydellinen, minkä vuoksi koin testikäyttäjien hyödyntämisen tärkeäksi sen sisällön kehittämisessä. Palautteen kerääminen oli jo itsessään opettavaista, sillä sen yhteydessä jouduin perustelemaan valintojani, kuten tutkimuskysymyksiä. Samassa yhteydessä havaitsin puutteita lomakkeen kysymyksissä, jotka pystyin korjaamaan saamani palautteen pohjalta. Esimerkiksi torjuntatekniikoita kartoittavissa kysymyksissä en alun perin tarjonnut

115 viittä eri vastausvaihtoa, vaan pyysin osallistujia merkitsemään käyttämänsä tekniikat. Useampien vastausvaihtoehtojen tarjoaminen mahdollisti lopulta tarkemmat vastaukset. Myös vastaajan toimenkuvan kysyminen oli hyvä parannus, sillä se tarvittaessa mahdollisti tulosten yksittäisten vastauksien tarkkuuden arvioinnin.

Minulla oli alusta lähtien tarkka visio kyselydatan käsittelystä lopulliseen muotoon. Tästä huolimatta tunsin tietojenkäsittelyn aikana ajoittain, että parempikin tapa olisi ollut toteutet- tavissa. Huolena oli se, että käsitelty data oli liian vaikeasti tulkittavaa lukijalle. Tilanne hankaloitui entisestään myöhemmin, kun havaitsin liitteen 11 kuvailemia poikkeustapauksia tutkimustuloksissa, mikä hankaloitti tulosten tulkintaa. Alun perin en esimerkiksi ollut huomioinut vastausvaihtoehtojen ”Ei ole käytössä, emmekä näe tarpeelliseksi” (vastaus c) ja ”Ei ole käytössä, mutta haluaisimme käyttää” (vastaus b) samankaltaisuutta verrattuna vastaukseen ”On käytössä” (vastaus a). Kun selvitin, mitkä torjuntatekniikat päätyvät yrityskoon tyypillisimpään vastaukseen, tarkistin vain, oliko vastauksia ”a” enemmän kuin vastauksia ”c”. En ymmärtänyt kyseisessä vaiheessa yhteenlaskea vastausten ”b” ja ”c” lukumääriä, ennen kuin vertasin niitä vastaukseen ”a” määrään. Seurauksena jouduin kir- joittamaan osan tutkimustuloksista uudelleen, kun yrityskokojen tyypillisimmät vastaukset muuttuivat virheenkorjauksen seurauksena. Tulevaisuudessa aion perehtyä tutkimusai- neistoon tarkemmin ennen tietojenkäsittelyä.

Aiemman kokemuksen puute kyselytutkimuksen toteuttamisesta johti myös ajoittain stres- siin ja oman osaamisen kyseenalaistamiseen. Tämä ilmeni varsinkin kyselytutkimuksen ensimmäisessä vaiheessa, kun olin lähettämässä lomakkeita ensimmäisen kerran. Huo- leni oli lopulta turhaa, sillä alan ammattilaisten palaute kyselytutkimukseeni oli positiivista. Positiivinen palaute nosti itseluottamustani ja kannusti työn laajentamiseen muun muassa haastattelemalla tunnettua suomalaista sähköpostiturvayhtiötä.

Olisin alun perin halunnut tehdä opinnäytetyöstä käytännönläheisemmän ja tutustua laajemmin vapaan ohjelmiston sähköpostiohjelmistojen, kuten Postfixin, konfiguroimiseen. Projektisuunnitelmassa oli myös varattu budjetti Office 365 -lisenssikustannuksille, jotta olisin voinut tutustua kyseiseen palveluun laajemmin. Palvelusta oli tarkoitus esittää käy- tännön esimerkkejä tietoperustan yhteydessä. Valitettavasti opinnäytetyön mittakaava kasvoi, jolloin en ehtinyt tutustua aihepiireihin yhtä läheisesti kuin olin alun perin toivonut. Olisin myös halunnut esittää teknisiä esimerkkejä hyökkääjien ja roskapostittajien näkö- kulmasta. Toisaalta teknisten osuuksien liiallinen lisääminen olisi voinut olla epäedullista työn luettavuuden kannalta. Samalla niiden poisjättäminen vapautti enemmän aikaa tutki- musosiolle, joka oli työn tärkein osuus. Pidän päätöstä siten perusteltuna ja työn kokonaisuuden kannalta edullisena.

116

Käytin laajasti eri lähteitä kansainvälisistä asiakirjoista ja internetstandardeista tietoperustaa kirjoittaessani. Eniten käytin IETF-organisaation standardeja, jotka ovat laadukkaimpia aihepiiriin liittyviä tietolähteitä, sillä niitä luovat ja kehittävät kansainväliset suuret palveluntarjoajat ja tietoliikenneasiantuntijat (IETF 2019a). Alan virallisiin standardeihin tutustumi- nen oli itsessään opettavainen kokemus osittain siksi, että niissä käytettiin paljon alan eri- koissanastoa. Tästä syystä teksti oli paikoittain vaikeasti luettavaa ja tulkittavaa, mutta se valmensi minua alaa varten.

Kokonaisuudessaan kokemus oli hyvin opettavainen. Opin itselleni uudesta aihealueesta paljon muun muassa sähköposti-infrastruktuurin toiminnasta ja roskapostin uhista. Esi- merkiksi tietojenkalastelua on kohdistettu sähköpostitse minuun, tuttaviini, entisen työpaik- kani henkilöstöön ja jopa ammattikorkeakouluni opiskelijoihin. Täten on tärkeää ymmär- tää, millä laajuudella sähköpostiviestien osoitetiedot ovat väärennettävissä ja miten ongelmaan voidaan vastata viestin aitouden ja lähettäjän todennukseen pyrkivien tekniikoiden avulla. Samaten erilaisten verkkohuijausyritysten tapahtuessa on hyödyllistä, jos osaan tulkita otsaketietojen ”Received”-kenttiä viestin alkuperän jäljittämiseksi esimerkiksi sen lähdemaahan.

Olen tähän mennessä ylläpitänyt pääasiassa www-palvelimia, mutta tutkimus on herättä- nyt kiinnostukseni Linux-pohjaisten sähköpostipalvelimien ylläpitoon. Tällöin tärkeää osaa- mista ovat tietoperustassa käsitellyt sähköpostin sisältöön ja lähteeseen perustuvat torjuntatekniikat, kuten SMTP-liikenteen suodatus, DNS-pohjainen mustalistaus ja bayesilainen suodatus. Tutkimuksen myötä minulla on myös paremmat valmiudet oman Office 365 - ympäristöni ylläpitoon ja sen tietoturvan kehittämiseen. Se on myös tietoa, jota tulen varmasti käyttämään työelämässäni, koska Office 365 -palvelun käyttöönottajia löytyy suomalaisista yrityksistä suurissa määrin, kuten tutkimustuloksista havaittiin (kuva 27).

Aihepiiri oli ajankohtainen ja siten tärkeä. Oppimisen tarve perustui opiskelijan omiin työ- peräisiin kokemuksiin, joten sillä oli vahva uraa kehittävä tarkoitus. Edellisessä työpaikas- sani sain kohtuullisen usein tukipyyntöjä sähköpostiviestien päätymisestä käyttäjän roskapostikansioon, jolloin etsin viestin otsaketiedoista syytä tapahtuneelle. Kykyni tulkita otsaketietoja oli monesti puutteellista, joten siirsin kyseiset tukipyynnöt esimiehelleni. Esi- merkiksi yhden tapauksen syyksi paljastui kumppaniyhtiön päivittämätön SPF-tietue, joka ei ollut sallinut lähettävää palvelinta toimialueen mukaiseksi lähettäjäksi. Tämä johti SPF- tarkistuksen tulokseen ”SoftFail”, minkä vuoksi viesti vastaanotettiin mutta samalla merkit- tiin roskapostiksi. Tuolloin osasin vain epäillä ongelman johtuneen SPF-tarkistuksesta

117 mutten osannut sanoa varmasti. Tutkimuksesta oppimillani tiedoilla olisin havainnut tilan- teeseen johtaneen syyn hyvin nopeasti viestin otsaketietokentistä.

Tutkimuksen myötä loin uusia kontakteja ja allekirjoitin työsopimuksen yhden tutkimukseen osallistuneen suomalaisen IT-alan palveluntarjoajan kanssa. Eräs kyselylomakkeeseen vastannut henkilö oli tutkinut verkkosivujani sekä LinkedIn -profiiliani ja otti minuun pian yhteyttä. Lähetin työhakemuksen ja ansioluettelon, mikä johti työhaastatteluun ja päätyi lopulta harjoittelusopimukseen. Opittuja asioita pääsen siis todennäköisesti hyödyn- tämään työelämässä jo hyvin pian.

Roskapostia ei pidä aliarvioida vanhana uhkana. Huijaukset muuttuvat jatkuvasti parem- miksi, ja sähköposti on vanha keksintö, joka ei ole katoamassa minnekään. Yksi tutkimukseen osallistuneista yrityksistä totesi sähköpostin käytön vähentyneen erilaisten pikaviesti- sovelluksien tieltä. En silti ole havainnut pikaviestimien korvaavaan sähköpostia miten- kään merkittävissä määrin, jotta roskapostisuodatuksen ajankohtaisuutta voitaisiin vähä- tellä. Roskapostin torjunnalla on myös suora vaikutus sähköpostiviestien toimitettavuu- teen, minkä vuoksi aihepiirin tunteminen edes tämän opinnäytetyön tietoperustan käsitte- lemällä tasolla kuuluu mielestäni jokaisen järjestelmäasiantuntijan ja IT-alan työntekijän ammattitaitoon.

118

Lähteet

AfterNerd 2019. SMTP protocol Explained [How Email works?]. Luettavissa: https://www.afternerd.com/blog/smtp/. Luettu 27.4.2019.

Aldwin, N. 2019. What is localhost? Luettavissa: https://www.hostinger.com/tutorials/what- is-localhost. Luettu 30.5.2019.

Arrak 2019. Arska – Features. Luettavissa: https://www.arrak.fi/fi/products/arska_features. Luettu 17.5.2019.

ARC Specification for Email 2019a. ARC Specification for Email. Luettavissa: http://arc- spec.org/. Luettu 11.5.2019.

ARC Specification for Email 2019b. Resources. Luettavissa: http://arc- spec.org/?page_id=79. Luettu 16.7.2019.

Awad, W.A. & Elseuofi, S.M. 2011. Machine Learning Methods for Spam E-mail Classifi- cation. International Journal of Computer Science & Information Technology (IJCSIT). Lu- ettavissa: https://www.researchgate.net/publication/50211017_Machine_Learning_Meth- ods_for_Spam_E-Mail_Classification. Luettu 17.7.2019.

Barracuda 2019. Configuring SPF, DKIM and DMARC. Luettavissa: https://campus.barracuda.com/product/sentinel/doc/78157593/configuring-spf-dkim-and-dmarc/. Luettu 8.5.2019.

BarracudaCentral 2019. Barracuda Reputation Block List (BRBL) – How to Use. Luetta- vissa: http://barracudacentral.org/rbl/how-to-use. Luettu 15.5.2019.

Bhowmick, A. & Hazarika, S. 2016. Machine Learning for E-mail Spam Filtering: Review, Techniques and Trends. Tezpur University. Tezpur. Luettavissa: https://ar- xiv.org/pdf/1606.01042.pdf. Luettu 2.5.2019.

Bralin 2019. Cloud Platform Security Showdown: G Suite vs Office 365. Luettavissa: https://www.bralin.com/cloud-platform-security-showdown-g-suite-vs-office-365. Luettu 16.7.2019.

119

Carranza, P. 2013. How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability. Luettavissa: https://www.digitalocean.com/community/tutorials/how-to-use-an- spf-record-to-prevent-spoofing-improve-e-mail-reliability. Luettu 3.4.2019.

Christina, V., Karpagavalli, S. & Suganya, G. 2010. A Study on Email Spam Filtering Techniques. International Journal of Computer Applications. Luettavissa: http://citese- erx.ist.psu.edu/viewdoc/download?doi=10.1.1.206.4041&rep=rep1&type=pdf. Luettu 1.5.2019.

Cisco 2017. Cisco Email Security Appliance. Luettavissa: https://www.cisco.com/c/en/us/products/collateral/security/email-security-appliance/data- sheet-c78-729751.pdf. Luettu 17.5.2019.

Cisco 2018. IP Addressing: IPv4 Addressing Configuration Guide, Cisco IOS XE Release 3S. Luettavissa: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_ipv4/configuration/xe-3s/ipv4-xe-3s-book/configuring_ipv4_addresses.html#GUID-FA922599-F183- 4F6E-A878-77E549796E67. Luettu 25.6.2019.

CloudDNS 2019. What is a DNS query? Luettavissa: https://www.cloudns.net/wiki/article/254/. Luettu 25.6.2019.

Cloudflare 2019. What Is A Reverse Proxy? | Proxy Servers Explained. Luettavissa: https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/. Luettu 15.7.2019.

Cohen, M. 2019. The Pros and Cons of Moving Your Email Services to the Cloud. Luetta- vissa: https://eccitsolutions.com/pros-cons-moving-email-services-cloud/. Luettu 17.7.2019.

Computer Hope 2019. Windows. Luettavissa: https://www.computerhope.com/jar- gon/w/windows.htm. Luettu 3.7.2019.

Cyrus 2019. Cyrus SASL. Luettavissa: https://www.cyrusimap.org/sasl/. Luettu 25.5.2019.

De Leon, R. 2019. A big Shift in cloud war between Amazon, Google, Microsoft is coming: P&G top tech exec. Luettavissa: https://www.cnbc.com/2019/04/30/a-big-shift-in-cloud- war-between-amazon-google-microsoft-is-coming.html. Luettu 3.7.2019.

120

D-Fence 2019a. Korkean käytettävyyden sähköpostiviestinnän turvapalvelu. Luettavissa: https://www.d-fence.fi/email-security. Luettu 19.5.2019.

D-Fence 2019b. UIDS – Unimetric Identification System. Luettavissa: https://www.d- fence.fi/uids. Luettu 19.5.2019.

D-Fence 2019c. Miten D-Fence palvelu tunnistaa roskapostit ja päästää asiallisen postin läpi niin että spamkansion/karanteenin käyttötarve poistuu? Luettavissa: https://d- fence.fi/faq?vastaus=miten-d-fence-palvelu-tunnistaa-roskapostit-ja-pst-asiallisen- 1161809. Luettu 19.5.2019.

DMARC 2017. Can I use DMARC If I Have Only Deployed SPF? Luettavissa: https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/. Luettu 10.5.2019.

DNSBL 2019. What is DNSBL? Luettavissa: https://www.dnsbl.info/. Luettu 15.5.2019.

DNSimple 2019. SPF Records. Luettavissa: https://support.dnsimple.com/articles/spf-record/#spf-modifiers. Luettu 25.6.2019.

Donovan, M. 2019. G Suite vs Office 365. Luettavissa: https://suitebriar.com/blog/g-suite- vs-office-365. Luettu 17.7.2019.

Dovecot 2014. Postfix and Dovecot SASL. Luettavissa: https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL. Luettu 25.5.2019.

DreamHost 2019. What is an MX record? Luettavissa: https://help.dreamhost.com/hc/en- us/articles/215032408-What-is-an-MX-record-. Luettu 15.4.2019.

Eberhardt, J. 2016. Bayesian Spam Detection. University of Minnesota. Morris. Luetta- vissa: https://digitalcommons.morris.umn.edu/cgi/viewcontent.cgi?article=1024&con- text=horizons. Luettu 17.5.2019.

EmailTalk 2019. What is A Reverse PTR Record? Luettavissa: http://www.emailtalk.org/ptr.aspx. Luettu 23.5.2019.

Fagella, D. 2019. What is Machine Learning? Luettavissa: https://emerj.com/ai-glossary- terms/what-is-machine-learning/. Luettu 30.5.2019.

121

Finlex 516/2004. Sähköisen viestinnän tietosuojalaki. Luettavissa: https://www.finlex.fi/fi/laki/alkup/2004/20040516. Luettu 1.5.2019.

Fisher, T. 2019. What Is a Hostname? Luettavissa: https://www.lifewire.com/what-is-a- hostname-2625906. Luettu 30.5.2019.

F-Secure 2019. Troijalaiset. Luettavissa: https://help.f-secure.com/product.html?home/anti-virus/latest/fi/concept_AD66CB676C2749B8A235B6D7E63BB4C2- anti-virus-latest-fi. Luettu 25.6.2019.

Fumera, G., Pillai, I. & Roli, F. 2006. Spam Filtering Based On The Analysis Of Text Infor- mation Embedded Into Images. University of Cagliari. Cagliari. Luettavissa: http://www.jmlr.org/papers/volume7/fumera06a/fumera06a.pdf. Luettu 2.5.2019.

GitLab 2018. MailConcept – A short introduction to the notorious MxA bunch. Luettavissa: https://gitlab.com/muttmua/mutt/wikis/MailConcept. Luettu 27.4.2019.

GNU 2018. What is free software? Luettavissa: https://www.gnu.org/philosophy/free- sw.en.html. Luettu 19.7.2019.

Google 2019a. Customize spam filter settings. Luettavissa: https://support.google.com/a/answer/2368132?hl=en. Luettu 19.5.2019.

Google 2019b. Block specific senders based on email address or domain. Luettavissa: https://support.google.com/a/answer/2364632?hl=en&ref_topic=2683828. Luettu 19.5.2019.

Google 2019c. Use enhanced pre-delivery message scanning. Luettavissa: https://support.google.com/a/answer/7380368?hl=en&ref_topic=2683828. Luettu 19.5.2019.

Google 2019d. Using address lists in Gmail settings. Luettavissa: https://support.google.com/a/answer/7381367#authentication. Luettu 19.5.2019.

Google 2019e. Set up mail security for G Suite. Luettavissa: https://support.google.com/domains/answer/6304562. Luettu 20.5.2019.

Google 2019f. Enhance security for outgoing mail (DKIM). Luettavissa: https://support.google.com/a/answer/174124. Luettu 20.5.2019.

122

Google 2019g. Manage suspicious emails with DMARC. Luettavissa: https://support.google.com/a/answer/2466580. Luettu 20.5.2019.

Google 2019h. About TXT records. Luettavissa: https://support.google.com/a/answer/2716800?hl=en. Luettu 29.5.2019.

GSX 2019. Understand how MAPI over HTTP is changing your Outlook. Luettavissa: https://cdn2.hubspot.net/hubfs/38080/Unders- tand%20how%20MAPI%20over%20HTTP%20is%20changing%20your%20Out- look%20.pdf. Luettu 30.4.2019.

Hajdarbegovic, N. 2019. Sender ID: Where Did That Email Come From? Luettavissa: https://www.whoishostingthis.com/resources/sender-id/. Luettu 8.5.2019.

Harris, E. 2003. The Next Step in the Spam Control War: Greylisting by Evan Harris. Luet- tavissa: http://projects.puremagic.com/greylisting/whitepaper.html. Luettu 16.5.2019.

Heiskanen, J. 2015. Turvallinen palvelinympäristö. Tampereen ammattikorkeakoulu. Tam- pere. Luettavissa: https://www.theseus.fi/bitstream/handle/10024/94371/Heiska- nen_Jonne.pdf?sequence=1&isAllowed=y. Luettu 15.7.2019.

HostingPalvelu 2018. Mikä on domain/verkkotunnus/verkko-osoite? Luettavissa: https://www.hostingpalvelu.fi/ohjeet/yleiset-domain-ohjeet/mika-on-domainverkkotunnus- verkko-osoite/. Luettu 3.7.2019.

Jain, S. 2017. E-MAIL Protocols: POP-SMTP-IMAP-MAPI. Luettavissa: https://www.linkedin.com/pulse/e-mail-protocols-pop-smtp-imap-mapi-sumit-jain/. Luettu 30.4.2019.

Jalkanen, J. 2019. Is Human The Weakest Link In Information Security? Jyväskylän yliopisto. Jyväskylä. Luettavissa: https://jyx.jyu.fi/bitstream/handle/123456789/64186/URN%3aNBN%3afi%3ajyu-201905242795.pdf. Luettu 3.7.2019.

IETF 1981. RFC 793 – Transmission Control Protocol. Luettavissa: https://tools.ietf.org/html/rfc793. Luettu 30.5.2019.

IETF 1987. RFC 1033 – Domain Administrators Operations Guide. Luettavissa: https://tools.ietf.org/html/rfc1033. Luettu 29.5.2019.

123

IETF 1996a. RFC 2046 – MIME Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. Luettavissa: https://tools.ietf.org/html/rfc2046. Luettu 28.4.2019.

IETF 1996b. RFC 1939 – Post Office Protocol – Version 3. Luettavissa: https://tools.ietf.org/html/rfc1939. Luettu 28.4.2019.

IETF 1996c. RFC 1983 – Internet Users’ Glossary. Luettavissa: https://tools.ietf.org/html/rfc1983. Luettu 30.5.2019.

IETF 1997. RFC 2231 – MIME Parameter Value and Encoded Word Extensions: Charac- ter Sets, Languages, and Continuations. Luettavissa: https://tools.ietf.org/html/rfc2231. Luettu 28.4.2019.

IETF 1999a. RFC 2505 – Anti-Spam Recommendations for SMTP MTAs. Luettavissa: https://tools.ietf.org/html/rfc2505. Luettu 1.5.2019.

IETF 1999b. RFC 2612 – HyperText Transfer Protocol – HTTP/1.1. Luettavissa: https://tools.ietf.org/html/rfc2616. Luettu 30.4.2019.

IETF 2000. RFC 2920 – SMTP Service Extension for Command Pipelining. Luettavissa: https://tools.ietf.org/html/rfc2920. Luettu 24.5.2019.

IETF 2001. RFC 2821 – Simple Mail Transfer Protocol. Luettavissa: https://tools.ietf.org/html/rfc2821. Luettu 14.4.2019.

IETF 2003. RFC 3501 – Internet Message Access Protocol – Version 4rev1. Luettavissa: https://tools.ietf.org/html/rfc3501. Luettu 28.4.2019.

IETF 2004. RFC 3834 – Recommendations for Automatic Responses to Electronic Mail. Luettavissa: https://tools.ietf.org/html/rfc3834. Luettu 2.5.2019.

IETF 2006a. RFC 4408 – Sender Policy Framework (SPF) for Authorizing Use of Domain in E-Mail, Version 1. Luettavissa: https://tools.ietf.org/html/rfc4408. Luettu 1.5.2019.

IETF 2006b. RFC 4406 – Sender ID: Authenticating E-Mail. Luettavissa: https://tools.ietf.org/html/rfc4406. Luettu 8.5.2019.

124

IETF 2006c. RFC 4422 – Simple Authentication and Security Layer (SASL). Luettavissa: https://tools.ietf.org/html/rfc4422. Luettu 30.5.2019.

IETF 2007a. RFC 4954 – SMTP Service Extension for Authentication. Luettavissa: https://tools.ietf.org/html/rfc4954. Luettu 25.5.2019.

IETF 2007b. RFC 4880 – OpenPGP Message Format. Luettavissa: https://tools.ietf.org/html/rfc4880. Luettu 25.6.2019.

IETF 2008a. RFC 5322 - Internet Message Format. Luettavissa: https://tools.ietf.org/html/rfc5322. Luettu 14.4.2019.

IETF 2008b. RFC 5321 - Simple Mail Transfer Protocol. Luettavissa: https://tools.ietf.org/html/rfc5321. Luettu 14.4.2019.

IETF 2009. RFC 5598 - Internet Mail Architecture. Luettavissa: https://tools.ietf.org/html/rfc5598. Luettu 15.4.2019.

IETF 2010. RFC 5782 – DNS Blacklists and Whitelists. Luettavissa: https://tools.ietf.org/html/rfc5782. Luettu 15.5.2019.

IETF 2011a. RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures. Luettavissa: https://tools.ietf.org/html/rfc6376. Luettu 9.5.2019.

IETF 2011b. RFC 6335 – Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry. Luetta- vissa: https://tools.ietf.org/html/rfc6335. Luettu 30.5.2019.

IETF 2012. RFC 6471 – Overview of Best Email DNS-Based List (DNSBL) Operational Practices. Luettavissa: https://tools.ietf.org/html/rfc6471. Luettu 2.5.2019.

IETF 2014. RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. Luettavissa: https://tools.ietf.org/html/rfc7208. Luettu 30.4.2019.

IETF 2015a. RFC 7489 – Domain-based Message Authentication, Reporting, and Con- formance (DMARC). Luettavissa: https://tools.ietf.org/html/rfc7489. Luettu 1.5.2019.

125

IETF 2015b. RFC 7719 – DNS Terminology. Luettavissa: https://tools.ietf.org/html/rfc7719. Luettu 29.5.2019.

IETF 2016. RFC 8017 – PKCS #1: RSA Cryptography Specifications Version 2.2. Luetta- vissa: https://tools.ietf.org/html/rfc8017. Luettu 29.5.2019.

IETF 2018a. RFC 8301 – Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). Luettavissa: https://tools.ietf.org/html/rfc8301. Luettu 9.5.2019.

IETF 2018b. Authenticated Received Chain (ARC) Protocol draft-ietf-dmarc-arc-protocol- 23. Luettavissa: https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-23. Luettu 11.5.2019.

IETF 2019a. About. Luettavissa: https://www.ietf.org/about/. Luettu 30.4.2019.

IETF 2019b. The Tao of IETF: Luettavissa: https://www.ietf.org/about/parti- cipate/tao/#rfc.section.6.5. Luettu 8.5.2019.

IETF 2019c. The Authenticated Received Chain (ARC) Protocol. Luettavissa: https://tools.ietf.org/html/rfc8617. Luettu 24.7.2019.

IJS 2018. Amavisd-new. Luettavissa: https://www.ijs.si/software/amavisd/. Luettu 18.5.2019.

IBM 2019. What is a TCP/IP Socket Connection? Luettavissa: https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2ti_what_is_socket_connection.html. Luettu 29.5.2019.

Indiana University 2018. About fully qualified domain names (FQDNs). Luettavissa: https://kb.iu.edu/d/aiuv. Luettu 30.5.2019.

Ite Wiki 2019. Kaikki it- ja ohjelmistoyritykset, digitalisaation osaajayritykset ja it-palvelut ite wikin yrityshaussa. Luettavissa: https://www.itewiki.fi/yritykset. Luettu 22.4.2019.

Iqbal, M., Abid, M., Ahmad, M. & Khurshid, F. 2016. Study on the Effectiveness of Spam Detection Technologies. Southwest Jiaotong University. Chengdu. Luettavissa: http://www.mecs-press.net/ijitcs/ijitcs-v8-n1/IJITCS-V8-N1-2.pdf. Luettu 17.5.2019.

126

Kaspersky 2019a. Spam and phishing in 2018. Luettavissa: https://securelist.com/spam- and-phishing-in-2018/89701/. Luettu 1.5.2019.

Kaspersky 2019b. What is Spear Phishing? Luettavissa: https://www.kaspersky.com/re- source-center/definitions/spear-phishing. Luettu 2.5.2019.

Kovachev, I. 2019a. All you need to know about SPF, DKIM and DMARC. Luettavissa: http://knowledge.ondmarc.com/learn-about-dmarc/all-you-need-to-know-about-spf-dkim- and-dmarc. Luettu 10.9.2019.

Kovachev, I. 2019b. What are the headers that ARC uses and what do they mean? Luet- tavissa: http://knowledge.ondmarc.com/learn-about-arc/arc-headers. Luettu 11.5.2019.

Kurittu, A. 2019. Social cyberattacks – Antti Kurittu. Disobey. Helsinki. Katsottavissa: https://www.youtube.com/watch?v=3mgntbZzFaw. Katsottu 2.5.2019.

KvantiMOTV 2003. Otos ja otantamenetelmät. Luettavissa: https://www.fsd.uta.fi/menetel- maopetus/otos/otantamenetelmat.html. Luettu 19.7.2019.

Kyberturvallisuuskeskus 2018. Office 365 -sähköpostin tietojenkalastelu ja tietomurrot erit- täin yleisiä – havaitse, suojaudu, tiedota! Luettavissa: https://www.kyberturvallisuuskeskus.fi/fi/office-365-sahkopostin-tietojenkalastelu-ja-tietomurrot-erittain-yleisia-havaitse- suojaudu-tiedota. Luettu 3.7.2019.

Leighton, J. 2019. What is Microsoft Caller ID? Luettavissa: https://smallbusi- ness.chron.com/microsoft-caller-id-49706.html. Luettu 17.7.2019.

Linux 2019. What is Linux? Luettavissa: https://www.linux.com/what-is-linux. Luettu 3.7.2019.

Lundgren, B. 2019. Greylisting. Luettavissa: https://www.greylisting.org/. Luettu 26.5.2019.

MAAWG 2019. MAAWG Position on Email Appending. Messaging, Malware and Mobile Anti-Abuse Working Group. San Francisco. Luettavissa: https://www.m3aawg.org/sites/default/files/m3aawg_apending_position_update-2019- 01.pdf. Luettu 2.5.2019.

127

MainSleaze 2013. Mitä mainsleaze-roskaposti on? (fi). Luettavissa: http://mainsleaze.spambouncer.org/mita-mainsleaze-roskaposti-on-fi/. Luettu 29.5.2019.

Media Temple 2019. Understanding an Email Header. Luettavissa: https://mediatem- ple.net/community/products/dv/204643950/understanding-an-email-header. Luettu 14.4.2019.

Metropolia 2013. Tietojenkalastelu eli Verkkourkinta (phishing). Luettavissa: https://wiki.metropolia.fi/pages/viewpage.action?pageId=62195969. Luettu 25.6.2019.

Microsoft 2016. EOP features. Luettavissa: https://docs.microsoft.com/en-us/office365/securitycompliance/eop/eop-features. Luettu 19.5.2019.

Microsoft 2018a. Set up SPF in Office 365 to help prevent spoofing. Luettavissa: https://docs.microsoft.com/en-us/office365/securitycompliance/set-up-spf-in-office-365-to- help-prevent-spoofing. Luettu 3.4.2019.

Microsoft 2018b. Content filtering. Luettavissa: https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/antispam-protection/content-filtering?view=exchserver- 2019. Luettu 18.5.2019.

Microsoft 2018c. Office 365 email anti-spam protection. Luettavissa: https://docs.microsoft.com/en-us/office365/securitycompliance/anti-spam-protection. Luettu 19.5.2019.

Microsoft 2018d. Microsoft 365 vs. Google G Suite – Trust, Security, and Compliance. Lu- ettavissa: https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE2yzoX. Luettu 16.7.2019.

Microsoft 2019a. What is a domain? Luettavissa: https://docs.microsoft.com/fi-fi/of- fice365/admin/get-help-with-domains/what-is-a-domain?view=o365-worldwide. Luettu 1.5.2019.

Microsoft 2019b. [MS-ASHTTP:]: Exchange ActiveSync: HTTP Protocol - 1.3 Overview. Luettavissa: https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms- ashttp/fee47e08-b416-46b0-9350-ca9eb5a587da. Luettu 30.4.2019.

128

Microsoft 2019c. Submit spam, non-spam, and phishing scam messages to Microsoft for analysis. Luettavissa: https://docs.microsoft.com/en-us/office365/securitycompliance/submit-spam-non-spam-and-phishing-scam-messages-to-microsoft-for-analysis. Luettu 2.5.2019.

Microsoft 2019d. Exchange Online Protection overview. Luettavissa: https://docs.microsoft.com/en-us/office365/securitycompliance/eop/exchange-online-protection-overview. Luettu 19.5.2019.

Microsoft 2019e. Office 365 Advanced Threat Protection Service Description. Luettavissa: https://docs.microsoft.com/fi-fi/office365/servicedescriptions/office-365-advanced-threat- protection-service-description. Luettu 19.5.2019.

Microsoft 2019f. Mail flow rules (transport rules) in Exchange Online. Luettavissa: https://docs.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/mail- flow-rules. Luettu 19.5.2019.

Microsoft 2019g. Use DKIM to validate outbound email sent from your custom domain in Office 365. Luettavissa: https://docs.microsoft.com/fi-fi/office365/SecurityCompliance/use- dkim-to-validate-outbound-email. Luettu 19.5.2019.

Microsoft 2019h. Use DMARC to validate email in Office 365. Luettavissa: https://docs.microsoft.com/fi-fi/office365/SecurityCompliance/use-dmarc-to-validate-email. Luettu 19.5.2019.

Microsoft 2019j. Office 365 integration with on-premises environments. Luettavissa: https://docs.microsoft.com/en-us/office365/enterprise/office-365-integration. Luettu 30.6.2019.

Microsoft 2019i. Microsoft 365. Luettavissa: https://www.microsoft.com/en-us/microsoft- 365. Luettu 2.7.2019.

Microsoft 2019k. Hanki Office 365:n uusimmat kehittyneet ominaisuudet. Luettavissa: https://www.microsoft.com/fi-fi/microsoft-365/business/compare-more-office-365-for-business-plans?rtc=1. Luettu 14.7.2019.

129

Mitra, A. 2017. What is DMZ in Computer Networking? Luettavissa: https://www.thesecuri- tybuddy.com/data-breaches-prevention/what-is-dmz-in-computer-networking/. Luettu 30.5.2019.

Neupane, K. 2013. Search Engine Optimization and Its Implications in Internet Marketing. Turku University of Applied Sciences. Turku. Luettavissa: https://www.theseus.fi/bitstream/handle/10024/69062/thesis%20final.pdf?sequence=1&isAllowed=y. Luettu 20.9.2019.

Nolisting 2019. Nolisting – Poor Man’s Greylisting. Luettavissa: http://nolisting.org/. Luettu 15.5.2019.

Office 2019a. Mitä ovat IMAP ja POP? Luettavissa: https://support.office.com/fi-fi/article/mit%C3%A4-ovat-imap-ja-pop-ca2c5799-49f9-4079-aefe-ddca85d5b1c9. Luettu 28.4.2019.

Office 2019b. Exchange Server 2019:n käyttöoikeudet. Luettavissa: https://products.office.com/fi-fi/exchange/microsoft-exchange-server-licensing-licensing-overview. Luettu 17.7.2019.

OpenSPF 2012. SPF vs Sender ID. Luettavissa: http://www.openspf.org/SPF_vs_Sen- der_ID. Luettu 3.1.2019. (Huomaa, että sivusto on sittemmin sulkeutunut, mutta lähteestä löytyy arkistoitu kopio: https://web.ar- chive.org/web/20190129085259/http://www.openspf.org/SPF_vs_Sender_ID)

OpenSPF 2019. SPF Record Syntax. Luettavissa: http://www.openspf.org/SPF_Re- cord_Syntax. Luettu 3.1.2019. (Huomaa, että sivusto on sittemmin sulkeutunut, mutta läh- teestä löytyy arkistoitu kopio: https://web.ar- chive.org/web/20190224184030/http://www.openspf.org/SPF_Record_Syntax)

Oravala, J. 29.5.2019. Perustaja ja hallituksen puheenjohtaja. D-Fence. Sähköposti. Luet- tavissa: Liite 10.

Pagani, F., De Astis, M., Graziano, M., Lanzi, A. & Balzarotti, D. 2016. Measuring the Role of Greylisting and Nolisting in Fighting Spam. Eurecom. Biot. Luettavissa: http://s3.eurecom.fr/docs/dsn16_pagani.pdf. Luettu 15.5.2019.

130

Pivotal Veracity 2005. False Positives. Luettavissa: https://content.marke- tingsherpa.com/heap/Pivotal-Veracity-May-2005.pdf. Luettu 3.7.2019.

PolicyD 2019. About. Luettavissa: https://wiki.policyd.org/. Luettu 24.5.2019.

Postfix 2019a. Postfix SMTP relay and access control. Luettavissa: http://www.postfix.org/SMTPD_ACCESS_README.html. Luettu 15.5.2019.

Postfix 2019b. Postfix Configuration Parameters. Luettavissa: http://www.postfix.org/post- conf.5.html. Luettu 24.5.2019.

Postfix 2019c. Postfix Address Verification How to. Luettavissa: http://www.postfix.org/ADDRESS_VERIFICATION_README.html. Luettu 24.5.2019.

Postfix 2019d. Postfix Performance Tuning. Luettavissa: http://www.postfix.org/TU- NING_README.html. Luettu 24.5.2019.

Postfix 2019e. How Postfix uses SASL authentication. Luettavissa: http://www.postfix.org/SASL_README.html. Luettu 25.5.2019.

Postfix 2019f. IBM Public License Version 1.0 – Secure Mailer. Luettavissa: http://www.postfix.org/IBM-Public-License-1.0.txt. Luettu 17.7.2019.

Postfwd 2019. Postfwd rate limit examples. Luettavissa: http://postfwd.org/ratelimits.html. Luettu 24.5.2019.

Pyhäranta, M. 2019. Johdanto kyselytutkimukseen. Luettavissa: http://thesis.markuspyharanta.com/. Luettu 15.6.2019.

Raulot, A. 2019. Bypassing phishing protections with email authentication. University of Amsterdam. Amsterdam. Luettavissa: https://www.delaat.net/rp/2018-2019/p61/report.pdf. Luettu 8.5.2019.

Return Path 2019a. What are X-headers? Luettavissa: https://help.returnpath.com/hc/en- us/articles/220567127-What-are-X-headers-. Luettu 30.4.2019.

131

Return Path 2019b. DKIM signing and verification overview. Luettavissa: https://help.returnpath.com/hc/en-us/articles/222481148-DKIM-signing-and-verification-overview. Luettu 9.5.2019.

Return Path 2019c. Ultimate guide to deliverability: how spam filters work? Luettavissa: https://returnpath.com/downloads/spam-filters-work/. Luettu 17.7.2019.

Rouse, M. 2005a. Parameter. Luettavissa: https://whatis.techtarget.com/definition/parameter. Luettu 30.5.2019.

Rouse, M. 2005b. Whitelist. Luettavissa: https://whatis.techtarget.com/definition/whitelist. Luettu 25.6.2019.

Rouse, M. 2005c. ASCII (American Standard Code for Information Interchange). Luetta- vissa: https://whatis.techtarget.com/definition/ASCII-American-Standard-Code-for-Infor- mation-Interchange. Luettu 25.6.2019.

Rouse, M. 2018. Bandwith. Luettavissa: https://searchnetworking.techtarget.com/definition/bandwidth. Luettu 9.7.2019.

Schryen, G. 2007. Anti-Spam Measures: Analysis and Design. Springer Science & Busi- ness Media. Berlin. Luettavissa: https://books.google.fi/books?id=s8r-nx5IO6cC. Luettu 2.5.2019.

Schwartz, A. 2004. SpamAssassin. O’Reilly Media. Sebastopol. Luettavissa: https://www.oreilly.com/library/view/spamassassin/0596007078/. Luettu 17.5.2019.

Schweikert, D. 2019. Postgrey – Postfix Greylisting Policy Server. Luettavissa: https://postgrey.schweikert.ch/. Luettu 16.5.2019.

Sheldon, R. 2009. A First Course in Probability. Eight Edition. Pearson. Upper Saddle River. Luettavissa: http://julio.staff.ipb.ac.id/files/2015/02/Ross_8th_ed_English.pdf. Luettu 20.7.2019.

Siponen, M. & Stucke C. 2006. Effective Anti-spam Strategies in Companies: An Interna- tional Study. Hawaii International Conference on System Sciences. Luettavissa: https://www.researchgate.net/profile/Mikko_Siponen/publication/4216229_Effective_Anti-

132

Spam_Strategies_in_Companies_An_Interna- tional_Study/links/55425ae60cf24107d3946d14/Effective-Anti-Spam-Strategies-in-Com- panies-An-International-Study.pdf. Luettu 1.5.2019.

SpamAssassin 2019a. Extensible email filter used to identify spam. Luettavissa: https://spamassassin.apache.org/full/3.2.x/doc/spamassassin.html. Luettu 20.5.2019.

SpamAssassin 2019b. Tests Performed: v3.3.x. Luettavissa: https://spamassassin.apache.org/old/tests_3_3_x.html. Luettu 20.5.2019.

Steam.io 2013. Postfix rate limiting – Politeness goes a long way. Luettavissa: http://steam.io/2013/04/01/postfix-rate-limiting/. Luettu 24.5.2019.

Sundström, H. 2008. Roskapostin estäminen. Tampereen yliopisto. Tampere. Luettavissa: http://tampub.uta.fi/bitstream/handle/10024/78600/gradu02249.pdf. Luettu 1.5.2019.

Taanila, A. 2019a. Kyselytutkimuksen luotettavuus. Luettavissa: https://tilastoapu.wordpress.com/2012/03/13/kyselytutkimuksen-luotettavuus/. Luettu 17.7.2019.

Taanila, A. 2019b. Mittaamisen luotettavuus. Luettavissa: https://tilastoapu.wordpress.com/2012/03/14/mittaamisen-luotettavuus/. Luettu 17.7.2019.

Taanila, A. 2019c. Muistilista kyselylomakkeen laatijalle. Luettavissa: https://tilastoapu.wordpress.com/2012/03/22/muistilista-kyselylomakkeen-laatijalle/. Luettu 17.7.2019.

Taanila, A. 2019d. Otantamenetelmä. Luettavissa: https://tilastoapu.wordpress.com/2012/03/09/otantamenetelma/. Luettu 19.7.2019.

Taanila, A. 2019e. Otoskoko. Luettavissa: https://tilastoapu.wordpress.com/2012/03/01/otoskoko/. Luettu 19.7.2019.

Taanila, A. 2019f. Kato. Luettavissa: https://tilastoapu.wordpress.com/2012/03/13/kato/. Luettu 20.7.2019.

Taugh 2003. Technical Responses to Spam. Luettavissa: https://www.taugh.com/spamtech.pdf. Luettu 18.5.2019.

133

Templeton, B. 2019. Reaction to the DEC Spam of 1978. Luettavissa: https://www.temple- tons.com/brad/spamreact.html. Luettu 3.7.2019.

Tilastokeskus 2019a. Mikroyritys. Luettavissa: http://www.stat.fi/meta/kas/mikroyritys.html. Luettu 13.5.2019.

Tilastokeskus 2019b. Pienet ja keskisuuret yritykset. Luettavissa: http://www.stat.fi/meta/kas/pienet_ja_keski.html. Luettu 13.5.2019.

TransIP 2019. Setting a DKIM record. Luettavissa: https://www.transip.eu/knowledge- base/entry/427-setting-a-dkim-record/. Luettu 9.5.2019.

TutorialsPoint 2019. What is a Socket? Luettavissa: https://www.tutorialspoint.com/unix_sockets/what_is_socket.htm. Luettu 29.5.2019.

Ubuntu 2017. Postfix Greylisting. Luettavissa: https://help.ubuntu.com/community/Post- fixGreylisting. Luettu 16.5.2019.

Xeams 2017. Difference between envelope and header from. Luettavissa: https://www.xeams.com/difference-envelope-header.htm. Luettu 30.4.2019.

Zoner 2016. SPF, DKIM ja DMARC tietueet parantavat sähköpostien läpimenoa. Luetta- vissa: https://www.zoner.fi/spf-dkim-ja-dmarc-tietueet-parantavat-sahkopostien-lapime- noa/. Luettu 10.5.2019.

Zscaler 2017. CVE-2017-11882 serving RAT and encrypted phishing campaign. Luetta- vissa: https://www.zscaler.com/blogs/research/cve-2017-11882-serving-rat-and-encrypted-phishing-campaign. Luettu 1.5.2019.

Viestintävirasto 2016. Toimitusjohtajahuijauksia levitetään laajasti sähköpostilla. Luetta- vissa: https://legacy.viestintavirasto.fi/kyberturvallisuus/tietoturva- nyt/2016/01/ttn201601131014.html. Luettu 29.5.2019.

W3schools 2019. HTML Unicode (UTF-8) Reference. Luettavissa: https://www.w3schools.com/charsets/ref_html_utf8.asp. Luettu 25.6.2019.

134

Weidmann, B. 2019. Fighting Spam in the Academic Arena. Luettavissa: https://www.sans.org/reading-room/whitepapers/email/fighting-spam-academic-arena-870. Luettu 3.7.2019.

Whalen, S. 2018. Demystifying DMARC: A guide to preventing email spoofing. Luetta- vissa: https://seanthegeek.net/459/demystifying-dmarc/. Luettu 8.5.2019.

Wiki Apache 2009. OcrPlugin. Luettavissa: https://wiki.apache.org/spamassassin/OcrPlu- gin. Luettu 2.5.2019.

135

Liitteet

Liite 1. Käsitteet, termit ja lyhenteet

A-tietue = Nimipalvelun tietue, jossa tietyn julkisessa verkossa olevan laitteen isäntänimi osoitetaan tiettyyn IPv4-osoitteeseen (IETF 1987, 7).

AAR = ARC-Authentication-Results. ARC-sarjaan kuuluva tietokenttä, johon talletetaan aiempien suoritettujen tarkistusten historia, jotta myöhemmät vastaanottajat näkevät, mitkä tarkistukset ovat onnistuneet tai epäonnistuneet aiemmilla palvelimilla, joiden kautta viesti on saapunut. (IETF 2018b, 9.)

Alitoimialue = Organisaation toimialuenimen alainen nimi (IETF 2015b). Esimerkiksi ”support.example.net” on alitoimialue toimialueelle ”example.net”.

AMS = ARC-Message-Signature. ARC-sarjaan kuuluva tietokenttä, johon kirjataan sarjan tapaustunniste ja DKIM-tyylinen allekirjoitus koko sähköpostiviestistä ARC-sarjoja lukuun ottamatta. (IETF 2018b, 9.)

ARC = Authenticated Received Chain. Protokolla, joka sallii yksittäisten sähköpostipalveli- mien lisätä niiden tekemien tarkistuksien tulokset sähköpostiviestin otsaketietoihin. (IETF 2018b, 4.)

ARC-ketju = Joukko tietoa, joka koostuu kaikista ARC-sarjoista, jotka ARC-sinetöijät li- säävät viestin otsaketietoihin (Kovachev 2019b).

ARC-sarja = Tietoa, jonka ARC-sinetöijä lisää sähköpostiviestin otsaketietoihin (IETF 2018b, 14).

ARC-sinetöijä = Rooli, jonka ARC-protokollaa hyödyntävä sähköpostipalvelin ottaa lähet- täessään viestiä (IETF 2018b, 13).

ARC-vahvistaja = Rooli, jonka ARC-protokollaa hyödyntävä sähköpostipalvelin ottaa vastaanottaessaan viestiä (IETF 2018b, 13).

AS = ARC-Seal. ARC-sarjaan kuuluvat tietokenttä, johon kirjataan sarjan tapaustunniste ja DKIM-tyylinen allekirjoitus aiemmista ARC-sarjoista. Pitää sisällään myös cv-tunnisteen, joka kertoo nykyisen ARC-ketjun tarkistuksen lopputuloksen. (IETF 2018b, 10.)

136

ATP = Advanced Threat Protection. Microsoftin Office 365 -palveluun lisätilauksena han- kittava turvapalvelu. (Microsoft 2019e.)

Avoin välityspalvelin = Sähköpostipalvelin, joka hyväksyy sähköpostiviestien edelleen lähetyksen mistä tahansa lähteestä (IETF 1999a, 8).

Backscatter = Roskapostia, jota syntyy erilaisten automaattisten vastausten, palautus- viestien, myötä, joita sähköpostipalvelimet lähettävät (Bhowmick & Hazarika 2016, 5).

Bcc = Viestin otsaketietojen piilokopiokenttä, jota ei lopulta sisällytetä otsaketietoihin, kun se saapuu vastaanottajan asiakasohjelmaan. Viestin vastaanottajat eivät näe kentän muita vastaanottajaosoitteita. (IETF 2008a, 23-24.)

Bayesilainen suodatus = Roskapostin torjuntatekniikka, joka perustuu koneoppimiseen Naive Bayes -luokittelulla. Siinä sähköpostiviestit luokitellaan joko roskapostiksi (spam) tai harmittomiksi sähköpostiviesteiksi (ham) suodattimen aiempien kokemuksien perusteella. (Eberhardt 2016, 1.)

Cc = Viestin otsaketietojen kopiokenttä, johon sisällytetään muut vastaanottajaosoitteet, joille viesti on lähetetty, mutta joille viestin sisältöä ei ole suoranaisesti kohdistettu (IETF 2008a, 23-24).

Cv-tunniste = Kertoo nykyisen ARC-ketjun tarkistuksen lopputuloksen (IETF 2018b, 10).

Date = Viestin otsaketietojen tietokenttä, joka kertoo päivämäärän ja kellonajan, jolloin viesti lähetettiin lähettäjän sähköpostiohjelmasta. Pitää sisällään myös lähettäjän aika- vyöhykkeen. (IETF 2008a, 14-16.)

Demilitarisoitu alue = Fyysinen tai looginen aliverkko, joka erottaa organisaation sisäver- kon julkisesta internetistä. Tyypillinen käyttötarkoitus on julkisten internet-palveluiden, kuten verkkosivujen julkaiseminen avoimeen internettiin tavalla, jossa www-palvelimet ovat palomuurein eristettyinä organisaation sisäverkkojen palveluista, joihin internetin käyttäjillä ei ole pääsyoikeuksia. (Mitra 2017.)

DKIM = DomainKeys Identified Mail. Tekniikka, jolla voidaan todentaa sähköpostiviestin aitous digitaalisella allekirjoituksella. (Raulot 2019, 5.)

137

DKIM-Signature = Otsaketietojen kenttä, joka sisältää sähköpostiviestin DKIM-allekirjoituksen. Kostuu useista tunnisteista opinnäytetyön luvun 6.3.2 mukaisesti. (IETF 2011a, 18.)

DMARC = Domain-based Message Authentication, Reporting & Conformance. Sähköpos- tien todennuskäytäntö ja raportointityökalu. Se toimii yhdessä SPF ja DKIM tekniikoiden kanssa sähköpostiviestien lähettäjän todentamiseksi, sekä suojaa organisaatiota osoitteiden väärentämis- ja tietojenkalasteluyrityksiä vastaan. (Zoner 2016.)

DNS = Domain Name System, eli nimipalvelujärjestelmä, joka muuntaa DNS-kyselyillä toimialuenimet niitä vastaaviin IP-osoitteisiin (IETF 1996c, 17).

DNS-kysely = DNS-asiakasohjelman ja -palvelimen välinen tiedonjako. Asiakasohjelma pyytää tietoa DNS-palvelimelta tyypillisesti jostain tietystä toimialuenimestä. DNS-kysely tehdään muun muassa silloin, kun selvitetään toimialuenimeä vastaavaa IP-osoitetta. (CloudDNS 2019.)

DNS-pohjainen mustalistaus = Roskapostin torjuntakäytäntö, joka perustuu listoihin tunnetuista IP-osoitteista tai toimialuenimistä, joita on käytetty roskapostien lähettämiseen. Sähköpostipalvelimet voivat käyttää listoja suodattaakseen tiettyjen lähettäjien viestit muusta sähköpostiliikenteestä. (DNSBL 2019.)

DNSBL = DNS-pohjainen mustalista tai -mustalistaus (DNSBL 2019).

DSN = Delivery Status Notification. Sähköpostiviestejä, jotka ilmoittavat viestin lähettäjää sähköpostin toimituksessa tapahtuneesta virheestä. (IETF 2004, 2-3.)

DNR = Non-Delivery Report. Sähköpostiviestejä, jotka ilmoittavat viestin lähettäjää sähkö- postin toimituksessa tapahtuneesta virheestä, joka esti viestin päätymisen lopulliselle vastaanottajalle. (IETF 2004, 2-3.)

EAS = Exchange ActiveSync. Sähköpostiohjelman ja sähköpostipalvelimen väliseen synkronointiin kehitetty protokolla, joka on suunnattu mobiililaitteiden Outlook-sähköpostiohjel- man kanssa käytettäväksi. (Microsoft 2019b.)

Edustapalvelin = Palvelin, joka sijaitsee julkisen verkon ja organisaation sisäverkon vä- lissä. Se vastaanottaa ulkoiset yhteydenotot ja ohjaa ne sisäverkon palvelimille. Monesti puhutaan myös käänteisestä välityspalvelimesta. Sähköpostipalveluissa sen roolina voi

138 olla esimerkiksi tietoturvan ja roskapostisuodatuksen keskittäminen yhdelle palvelimelle, jolloin sisäverkon sähköpostipalvelimien ei tarvitse enää suorittaa roskapostitorjuntaa. (Cloudflare 2019; Heiskanen 2015.)

EHLO = Extended HELO. Uudempi komento laajennettuun SMTP-protokollaan, joka kor- vaa aiemman HELO-komennon. (IETF 2001, 29-30.)

EOP = Exchange Online Protection. Microsoftin Office 365 -palveluun sisältyvä suojaus- palvelu, joka pitää sisällään roskapostisuodatuksen. (Microsoft 2019d.) eSec = D-Fence Email Security. D-Fencen pilvipohjainen sähköpostiturvapalvelu. (D- Fence 2019a.)

FQDN = Fully Qualified Domain Name, eli täydellinen nimi, joka muodostuu isäntänimestä ja toimialuenimestä (Indiana University 2018). Esimerkiksi, jos isäntänimi on ”mailserver” ja toimialuenimi on ”example.net”, palvelimen FQDN on ”mailserver.example.net”.

From = Sähköpostiviestin otsaketietojen kenttä, joka identifioi viestin lähettäjän sähköpos- tiosoitteen (IETF 2008a, 22).

Hakukoneoptimointi = Joukko menetelmiä, joilla parannetaan verkkosivustojen näky- vyyttä internetin hakukoneiden kautta tehdyissä hauissa. Sen tavoitteena on parantaa ha- lutun verkkosivun todennäköisyyttä esiintyä ensimmäisten hakutulosten joukossa. (Neu- pane 2013, 16.)

Ham = Termi, jota SpamAssassin käyttää kuvatessaan aitoja sähköpostiviestejä (Eber- hardt 2016, 1).

Harkinnanvarainen näyte = Näyte, jonka valinnassa hyödynnetään tutkijan harkintaa, eikä sattumaa (Taanila 2019d).

Harmaalistaus = Roskapostin torjuntatekniikka, jossa viesti hylätään ensimmäisen kerran niiltä lähettäjiltä, jotka eivät ole entuudestaan tunnettuja, tai joita ei ole havaittu pitkään aikaan (Lundgren 2019).

HELO = Komento, jolla lähettävä SMTP-asiakasohjelma todistaa identiteettinsä SMTP- palvelimelle (IETF 2001, 29-30).

139

HTTP = Hypertext Transfer Protocol on TCP/IP OSI-mallin sovellustasolla toimiva protokolla, jota käytetään internetin verkkosivujen ja käyttäjän verkkoselaimen välisessä liiken- teessä (IETF 1999b, 7).

Joe job = Hyökkäysmenetelmä, jolla pyritään kohdeyrityksen maineen pilaamiseen (Schryen 2007, 19).

IETF = Internet Engineering Task Force. Kansainvälinen organisaatio, joka kehittää ja yl- läpitää internet-standardeja. (IETF 2019a.)

IMAP = Internet Message Access Protocol. Protokolla, jota käytetään käyttäjälle osoitettujen viestien noutamiseksi sähköpostin toimitusohjelmalta (IETF 2003, 1). IMAP mahdollistaa sähköpostiviestien lukemisen miltä tahansa laitteelta. Viestejä ei tallenneta ainoastaan paikalliselle tietokoneelle, vaan ensisijaisesti sähköpostipalvelimelle. (Office 2019a.)

IP-osoite = Osoite, joka yksilöi tietokoneen tai muun laitteen IP-verkoissa (Cisco 2018).

IPv4-osoite = IPv4-version IP-osoite. 32-bittinen osoite, joka yksilöi tietokoneen tai muun laitteen IP-verkoissa. Osoite jakautuu neljään oktettiin, jotka ovat kukin 8-bittiä pitkiä. (Cisco 2018.)

Isäntänimi = Laitteen yksilöllistävä nimi, jolla se tai muut laitteet tunnistavat sen verkossa. Muodostaa yhdessä toimialuenimen kanssa FQDN-nimen. (Fisher 2019.)

Kaistanleveys = Termi, jolla kuvataan maksimaalista teoreettista datamäärää, joka voidaan siirtää samalla verkkoyhteydellä sekunnissa (Rouse 2018).

Karsija = SPF-tietueeseen kuuluva komponentti, jota käytetään tietueen mekanismien täsmätessä. Määritelty karsija johtaa tulokseen, joka määrittelee, miten vastaanottavan palvelimen tulisi käsitellä toimialueelta saapuvat viestit. (OpenSPF 2019.)

Kato = Kyselytutkimukseen valitut tahot, jotka eivät jostain syystä vastaa kyselyyn. Ter- millä voidaan myös tarkoittaa osallistujien yksittäisiä puuttuvia vastauksia. (Taanila 2019f.)

Kirjekuori = Ohjaa viestin käsittelyaktiviteetteja SMTP-asiakasohjelman ja -palvelimen välisessä lähetyskanavassa (IETF 2009, 25).

140

Kohdennettu verkkourkinta = Tiettyyn yritykseen tai henkilöön kohdistunut huijaus. Tyy- pillinen esimerkki on toimitusjohtajahuijaus. (Viestintävirasto 2016.)

Koneoppiminen = Tekoälyn osa-alue, jossa parannetaan tietokoneiden kykyä oppia ja toimia automatisoidusti ajan kanssa niille syötetyn pohjatiedon perusteella (Fagella 2019).

Kättely = Määritelmä riippuu protokollasta, jonka yhteydessä siitä puhutaan. TCP-protokollassa kättely on vaihe, jossa lähettävä ja vastaanottava palvelin muodostavat alun perin yhteyden SYN, SYN-ACK ja ACK-komennoilla keskenään (IETF 1981, 30-31). TCP- kättely tapahtuu ennen SMTP-yhteyden HELO/EHLO-komentoa. SMTP-kättelyllä viitataan koko prosessiin, joka lähettävän ja vastaanottavan palvelimen välillä käydään ennen säh- köpostiviestin datan välittämistä (Afternerd 2019). Se pitää sisällään sekä TCP-kättelyn että opinnäytetyön luvun 3.3 kuvan 3 esittämät vaiheet 1-6.

Linux = Vapaan ohjelmiston käyttöjärjestelmä, josta on sekä kuluttaja- että yritysversioita. Linuxia suositaan erityisesti palvelinkäyttöjärjestelmänä. (Linux 2019.)

Localhost = Isäntänimi, joka osoittaa siihen paikalliseen tietokoneeseen, jolla siihen refe- roidaan. Sitä käytetään, kun yritetään tavoittaa palveluja omalta koneelta. Localhost IPv4- osoite on 127.0.0.1. (Aldwin 2019.)

MAIL FROM = Sähköpostiviestin lähettäjän sähköpostiosoitteen identifioiva komento SMTP-asiakasohjelman ja -palvelimen välisessä lähetyskanavassa (IETF 2008b, 18-30).

Mainsleaze = Asianmukaisten ja virallisten yritysten lähettämää markkinointipostia, jonka alkuperää ei yritetä peitellä (MainSleaze 2013).

MDA = Mail Delivery Agent, eli sähköpostin toimitusohjelma. Vastaa sähköpostiviestien toimittamisesta loppukäyttäjän sähköpostitilin postilaatikkoon. (IETF 2009, 33-34.)

MTA = Mail Transfer Agent, eli sähköpostin siirto-ohjelma. Vastaa sähköpostiviestien rei- tittämisestä. Välittää sähköpostiviestejä reitittämällä niitä yhdeltä palvelimelta toiselle, kunnes ne päätyvät vastaanottajan sähköpostipalvelimen toimitusohjelmalle. (IETF 2009, 32- 33.)

MUA = Mail User Agent, eli sähköpostin käyttäjäohjelma. Sähköpostin käyttäjäohjelmat ovat sähköpostin lähteitä tai kohteita (IETF 2009, 29-30). Käyttäjäohjelma on käyttöliit- tymä, jonka kautta loppukäyttäjät lukevat ja kirjoittavat sähköpostiviestejä (GitLab 2018).

141

MAPI = Messaging Application Programming Interface. Protokolla, jota käytetään Micro- softin Exchange-palvelimen ja siihen perustuvien palveluiden, kuten Office 365:n kanssa. (Jain 2017.)

Mekanismi = SPF-tietueen komponentti, jota käytetään yhdessä sen karsijan kanssa. Me- kanismit arvioidaan aina järjestyksessä vasemmalta oikealle. Ne osoittavat, mitkä palvelimet ovat sallittuja lähettäjiä. Jos mekanismi täsmää, käytetään sen karsijaa. (OpenSPF 2019.)

Message-ID = Tunniste, joka yksilöi sähköpostin ja sen version muista viesteistä (IETF 2008a, 25).

MIME = Multipurpose Internet Mail Extension. Sähköpostin lisäosa, joka sallii sähköpos- tien välittämisen erilaisia merkistöjä käyttäen. MIME:n myötä viesteihin on pystytty sisällyt- tämään myös liitteitä ja erilaisia mediatiedostoja, kuten kuvia. (IETF 1997, 1-3.)

Mustalistaus = Käytäntö, jossa tietyiltä listan mukaisilta identiteeteiltä evätään pääsy. Roskapostin torjunnan näkökulmasta mustalistauksessa voidaan estää sähköpostiviestien vastaanottaminen tietyiltä tahoilta. Opinnäytetyössä käsitellään DNS-pohjaista mustalistausta, joka on yksi mustalistauksen muodoista (DNSBL 2019).

MX-tietue = Nimipalvelun tietue, joka määrittelee, minkä sähköpostin siirto-ohjelmalla varustellun palvelimen kautta saavutetaan tietty toimialue. Se siis yksilöi sen sähköpostipal- velimen, joka vastaa sähköpostin vastaanottamisesta organisaation nimissä. (IETF 2009, 33.)

Määrite = SPF-tietueen komponentti. Tietueessa voi esiintyä ainoastaan yksi määrite. Niitä käytetään esimerkiksi, jos DNS-kysely halutaan ohjata johonkin toiseen SPF-tietueeseen, tai halutaan antaa tarkempi selitys tietueen mekanismeista. (DNSimple 2019.)

Naive Bayes = Luokittelualgoritmi, jota käytetään usein koneoppimisessa (Iqbal 2016, 17).

Nolisting = Roskapostin torjuntatekniikka, jossa toimialueen ensimmäinen MX-tietue laitetaan osoittamaan virheelliseen sähköpostipalvelimeen, jota ei ole olemassa (Nolisting 2019).

142

Ositettu otanta = Otanta, jossa tutkimuksen avainmuuttujan jakauma perusjoukossa on etukäteen tiedossa (Taanila 2019d).

Otantakehikko = Joukko, josta tutkimuksen otos lopulta valitaan. Ei välttämättä edusta koko perusjoukkoa. (Taanila 2019d.)

Otos = Valitulla otantamenetelmällä otantakehikosta valittu osa, johon ei lasketa mukaan katoa (Taanila 2019e).

Otsaketiedot = Sähköpostiviestin osa, joka sisältää viestin reitittämiseen liittyviä tietokent- tiä. Niitä voidaan hyödyntää postin kulun vikatilanteiden selvittämisessä.

Parametri = Tietoa, joka annetaan jonkun tietyn ohjelman suorittamisen yhteydessä. Pa- rametrit vaikuttavat ohjelman toimintaan määritellyllä tavalla. (Rouse 2005a.)

Peittovirhe = Virhe, joka syntyy, kun tutkimuksen otos valitaan otantakehikosta todellisen perusjoukon sijaan (Taanila 2019a).

Perusjoukko = Se joukko, jota tutkimuksessa halutaan tutkia (Taanila 2019e).

PGP = Pretty Good Privacy. Tietojen salausprotokolla, jota käytetään eritysesti sähköpos- tiviestin allekirjoittamiseksi ja sisällön salaamiseksi. (IETF 2007b, 5.)

POP3 = Post Office Protocol Version 3. Protokolla, jota sähköpostin käyttäjäohjelmat käyt- tävät loppukäyttäjälle osoitettujen sähköpostiviestien noutamiseksi toimitusohjelman sisäl- tävältä sähköpostipalvelimelta. (IETF 1996b, 2.)

Portti = Tietoliikenteen päätepiste, joka on aina yhdistettynä isäntälaitteensa IP-osoitteeseen. Palvelintietokoneella suoritettavat palvelut odottavat yhteyttä johonkin tiettyyn porttiin. Yleisin esimerkki on yhteydenottaminen www-palvelimen porttiin 80 tai 443 verkkosi- vuston lataamistarkoituksessa. (IETF 2011b, 6-7.)

PRA = Purported Resposible Address. Algoritmi, joka valitsee, mikä viestin otsaketietokenttien sähköpostiosoitteista kuuluu todennäköisimmin viestin lähettäjälle (Hajdarbegovic 2019).

PTR-tietue = Vastakohta A-tietueelle, eli siinä tietty IP-osoite osoitetaan sitä vastaavaan isäntänimeen. Tällöin vastaanottava palvelin voi tehdä käänteisen nimipalvelukyselyn ja

143 selvittää lähettävän palvelimen IP-osoitteen sen isäntänimen perusteella. (EmailTalk 2019.)

RCPT TO = Sähköpostiviestin vastaanottajan sähköpostiosoitteen identifioiva komento SMTP-asiakasohjelman ja -palvelimen välisessä lähetyskanavassa (IETF 2008b, 18-30).

Received = Kenttä, johon on merkitty, miltä SMTP-palvelimelta viesti on vastaanotettu ja minkä palvelimen toimesta. Sisältää myös muita yhteyteen liittyviä tietoja, kuten kuljetuksessa käytetyn salausprotokollan version ja yksilöllisen ID-tunnisteen. (IETF 2008b, 29.)

Reliabiliteetti = Tutkimuksen mittauksen tarkkuus, joka voi heikentää tutkimuksen validi- teettia (Taanila 2019b).

Reply-to = Viestin otsaketietojen kenttä, jossa määritellään, mihin sähköpostiosoitteen viestin alkuperäinen kirjoittaja haluaa vastaukset (IETF 2008a, 22-23).

Return-Path = Viestin otsaketietojen kenttä, joka lisätään SMTP-palvelimella viestin vii- meisessä lähetysvaiheessa. Se määrittelee sen sähköpostiosoitteen, johon lähetetään viestit, joita ei voitu syystä tai toisesta toimittaa. ”Return-Path”-kentän määrittämä sähkö- postiosoite vastaa SMTP-protokollan ”MAIL FROM”-osoitteen kanssa. (IETF 2008b, 57- 59.)

Roskaposti = Kaikki sellainen sähköpostiliikenne, joka ei ole vastaanottavan organisaation toimesta toivottua (IETF 1999a, 2).

RSA = Laajasti käytetty julkisen avaimen salausalgoritmi, jota käytetään turvalliseen tie- donsiirtoon. Avainpari muodostuu julkisesta avaimesta sekä yksityisestä avaimesta, jota ei julkaista muiden käyttöön. (IETF 2016, 4.)

SASL = Simple Authentication and Security Layer on viitekehys, jolla voidaan varmistaa todentaminen ja tiedon turvallisuus yhteydellisissä protokollissa. SASL mahdollistaa yhte- neväisen tavan käyttää vanhoja tai uusia mekanismeja kaikissa protokollissa ilman vanho- jen protokollien tai mekanismien uudelleensuunnittelua. (IETF 2006c, 3.)

SCL = Spam Confidence Level. Arvo, joka myönnetään sähköpostiviestille Microsoftin Ex- change-sähköpostipalvelimien sisällönsuodatuksessa. Tarkistuksen pohjalta sähköposti- viestille annetaan SCL-arvo lukujen 0-9 väliltä. Mitä suurempi numero, sitä todennäköi- semmin viesti on roskapostia. (Microsoft 2018b.)

144

Sender: Viestin otsaketietojen kenttä, joka yksilöi sen lähettäjän sähköpostiosoitteen, josta viesti lopulta lähetettiin. Sisällytetään otsaketietoihin ainoastaan, jos ”From”-ken- tässä on useampi kuin yksi sähköpostiosoite. (IETF, 2008a, 22.)

Sender ID = Microsoftin kehittämä protokolla, jonka toimintaperiaate vastaa SPF-tekniikkaa. Erona se, että Sender ID pystyy tekemään lähettäjän tarkistuksen sekä sähköposti- viestin otsaketietojen ”From”-kentästä että SMTP-yhteyden ”MAIL FROM”-osoitteesta. (OpenSPF 2012.)

Sisältöosa = Sähköpostin osa, joka sisältää viestin sisällön, kuten tekstin ja kuvat (IETF 2008a, 9).

SMTP = Sähköpostin siirtämiseen kehitetty protokolla, joka pystyy siirtämään sähköpostia useiden verkkojen ylitse ja niiden välillä. SMTP-asiakasohjelma aloittaa yhteyden SMTP- palvelimen välille luomalla kaksisuuntaisen lähetyskanavan, jota käytetään lopulta sähkö- postiviestin siirtämiseen. (IETF 2008b, 7.)

SMTP-asiakasohjelma = SMTP-protokollaa käyttävän sähköpostipalvelimen rooli silloin, kun se toimii lähetyskanavan aloittajana SMTP-yhteydessä. Sen vastuulla on siirtää säh- köpostiviestit SMTP-palvelimelle. (IETF 2009, 32.)

SMTP-kanavointi = Usean SMTP-komennon sisällyttäminen yhteen tietoliikennelähetyk- seen (IETF 2000).

SMTP-palvelin = SMTP-protokollaa käyttävän sähköpostipalvelimen rooli silloin, kun se toimii viestin vastaanottajana SMTP-yhteyden aikana (IETF 2008b, 7-9).

Spam = Termi, jota SpamAssassin käyttää kuvatessaan roskapostia (Eberhardt 2016, 1).

SPF = Sender Policy Framework. Sähköpostiviestin lähettäjän todentamiseksi kehitetty tekniikka, joka osoittaa, mitkä sähköpostipalvelimet saavat lähettää sähköpostia organisaation toimialuenimen nimissä. (IETF 2014, 5.)

Subject = Viestin otsaketietojen otsikkokenttä, joka kuvaa lyhyesti viestin aiheen (IETF 2008a, 27-28).

145

Systemaattinen otanta = Otantamenetelmä, jossa perusjoukosta valitaan otos satunnai- sella arvonnalla. Edellytyksenä on, että perusjoukko on jono, josta otannan aloituskohta voidaan arpoa. (Taanila 2019d.)

Sähköpostin käyttäjäohjelma = Sähköpostin lähde tai kohde (IETF 2009, 29-30). Käyttä- jäohjelma on käyttöliittymä, jonka kautta loppukäyttäjät lukevat ja kirjoittavat sähköposti- viestejä (GitLab 2018).

Sähköpostin siirto-ohjelma = Vastaa sähköpostiviestien reitittämisestä. Välittää sähkö- postiviestejä reitittämällä niitä yhdeltä palvelimelta toiselle, kunnes ne päätyvät vastaanottajan sähköpostipalvelimen toimitusohjelmalle. (IETF 2009, 32-33.)

Sähköpostin toimitusohjelma = Vastaa sähköpostiviestien toimittamisesta loppukäyttä- jän sähköpostitilin postilaatikkoon (IETF 2009, 33-34).

Sähköpostiosoitteiden kohdentaminen = Käytäntö, jossa väärinkäytetään yksityishenki- löiden henkilötietoja suoramarkkinoinnin kohdistamiseksi tiettyyn sähköpostiosoitteeseen, jonka uskotaan olevan tietyn henkilön hallussa (MAAWG 2019).

Sähköpostiosoitteiden väärentäminen = Sähköpostiviestien lähettäminen toisen organisaation toimialuenimeä käyttäen (IETF 2014, 5).

Socket = Päätepiste, joka mahdollistaa kommunikoinnin kahden eri prosessin välillä samalla tai kahdella eri laitteella (TutorialsPoint 2019). Esimerkiksi TCP-socket koostuu IP- osoitteesta ja portista (IBM 2019).

Tapaustunniste = Kertoo, mitkä ARC-otsakekentät kuuluvat millekin ARC-sarjalle. Kertoo myös ARC-vahvistajalle, missä järjestyksessä ARC-sarjat on lisätty viestin otsaketietoihin. Tapaustunnisteen arvo voi olla väliltä 1-50. (IETF 2018b, 12.)

Tietojenkalastelu = Verkkourkintaa, jossa pyritään samaan kohteelta luottamuksellisia tietoja, kuten käyttäjätunnuksia (Metropolia 2013).

To = Sähköpostiviestin otsaketietojen kenttä, joka identifioi viestin vastaanottajan sähkö- postiosoitteen (IETF 2008a, 23-24).

Toimialuenimi = Organisaation, kuten yrityksen yksilöllistävä nimi, jota käytetään organisaation verkkotunnuksissa ja sähköpostien päätteissä @-merkin jälkeen. Se muodostuu

146 yleensä organisaation nimestä ja ylemmän tason verkkotunnuksesta, kuten com tai fi. (Microsoft 2019a.)

Toimitusjohtajahuijaus = Kohdennetun verkkourkinnan muoto, jossa hyökkääjä esiintyy esimerkiksi yrityksen toimitusjohtajana yrityksessään uskotella yrityksen muuta henkilös- töä toimimaan haluamallaan tavalla (Viestintävirasto 2016).

Troijalainen = Haittaohjelma, joka tekeytyy normaalisti toimivaksi ja luotettavaksi ohjelmaksi. Tekee haitallisia toimintoja tietokoneen taustalla käyttäjän tietämättä. (F-Secure 2019.)

TXT-tietue = Tekstitietue, eli nimipalvelun tietue, jossa jaetaan tekstimuotoista tietoa ul- koisille lähteille (Google 2019h). Tyypillinen käyttötarkoitus on esimerkiksi SPF-tietueiden julkaiseminen.

Täytäntöönpanosääntö = SPF-tietueen lopussa oleva sääntö, joka koostuu valitusta karsijasta ja mekanismista ”all”. Se luetaan tietueessa viimeisenä ja se määrittelee, miten lä- hettäjiltä tullutta sähköpostia tulisi käsitellä, jos lähettäjä ei vastaa muiden SPF-tietueessa määriteltyjen mekanismien kanssa. (Microsoft 2018a.)

UIDS = D-Fencen kehittämä teknologia, jolla voidaan tunnistaa automatisoidut roskapostittajat reaaliajassa (D-Fence 2019b).

US-ASCII = Yhdysvaltain ASCII-standardi. ASCII on tekstimuoto, jota käytetään tietotek- niikassa. Siinä kutakin merkkiä, kuten aakkosta, edustaa 7-bittinen binääriluku. (Rouse 2005c.)

UTF-8 = Suositeltu merkistökoodaus verkkosivuille ja sähköpostiin. Sallii muun muassa ääkköset ja on taaksepäin yhteensopiva ASCII-standardin kanssa. (W3schools 2019.)

Valitsin = DKIM-allekirjoituksen osa. Allekirjoittaneella toimialueella voi olla useita julkisia avaimia, ja siksi valitsimia käytetään avainavaruuden pilkkomiseen osiin. (IETF 2011a, 24.)

Validiteetti = Osoittaa, miten hyvin kyselytutkimuksen kysymykset mittaavat tutkittavaa asiaa (Taanila 2019b).

147

Valkolistaus = Mustalistauksen vastakohta, eli käytäntö, jossa tietyille listan mukaisille identiteeteille sallitaan pääsy. Roskapostin torjunnan näkökulmasta valkolistauksessa voidaan sallia sähköpostiviestien vastaanottaminen aina tietyiltä tahoilta erikseen. (Rouse 2005b.)

Vapaa ohjelmisto = Käyttäjien vapautta kunnioittava ohjelmisto, jolle on määriteltävissä neljä pääperiaatetta: vapaus käyttää ohjelmistoa halutulla tavalla, vapaus tutkia ohjelmiston lähdekoodia ja muokata sitä, vapaus levittää ohjelmistoa sekä vapaus levittää ohjelmiston muokattua versioita (GNU 2018).

Vastaavuus = Termi, jota käytetään silloin, kun sähköpostiviestin otsaketietojen ”From”- kentän osoite täsmää SPF- ja DKIM-tarkistuksissa esiintyneiden toimialuenimien kanssa (IETF 2015a, 8-10).

Vastaavuustila = Kertoo, miten tarkasti toimialuenimien tulee vastata toisiinsa, kun DMARC testaa SPF- ja DKIM-tarkistuksissa havaittujen identiteettien vastaavuutta sähkö- postiviestin otsaketietojen ”From”-kentän osoitteeseen (IETF 2015a, 17).

Verkkotunnus = Yrityksen julkiseen resurssiin, kuten verkkosivuun ohjaava nimi (Hos- tingPalvelu 2018). Saattaa olla identtinen yrityksen toimialuenimen kanssa tai sisältää sen. Monesti termejä käytetään toistensa synonyymeina. Verkkotunnus muodostuu yleensä organisaation nimestä ja ylemmän tason verkkotunnuksesta, kuten com tai fi (Microsoft 2019a).

Vinoutuminen = Otoksen tai näytteen vinoutuminen tapahtuu esimerkiksi, jos tutkimuksen otantakehikko on liian suppea tai tutkimukseen vastaamatta jättäneiden mielipiteet ovat erilaisia kuin vastanneilla (Taanila 2019d; 2019e).

Windows = Microsoftin käyttöjärjestelmätuoteperhe, jota on päivitetty useasti sen ensim- mäisen julkaistun version jälkeen (Computer Hope 2019). Käyttöjärjestelmästä on sekä kuluttaja- että yritysversioita.

X-kenttä = Muut virallisesti määrittelemättömät otsakekentät merkitään alkavaksi ”X-” merkinnällä. X-kentät sisältävät merkintöjä ja tunnisteita kaikilta sähköpostipalvelimilta ja - päätteiltä, joiden läpi posti on kulkenut. (Return Path 2019a.)

Yhdyskäytävä = SMTP-palvelin, joka ei toimi sähköpostin lopullisena kohteena. Tällöin se toimii vain välissä olevana palvelimena ja välittää viestin eteenpäin. (IETF 2008b, 7-9.)

148

Liite 2. SMTP-liikenteen suodatus Postfix-siirto-ohjelmassa

Sisäänpäin suuntautuvassa liikenteessä

Postfix-siirto-ohjelmassa lähettäjän tarkistukset voidaan määritellä konfiguraatiotiedostoon /etc/postfix/main.cf seuraavin parametrein:

“reject_unknown_sender_domain”-parametrilla vastaanottava sähköpostipalvelin hylkää SMTP-yhteyden, jos se ei itse toimi sähköpostin lopullisena vastaanottajana ja sähköpos- tin kirjekuoren ”MAIL FROM”-osoitteen toimialueella ei ole nimipalvelun MX- ja A-tietueita tai jos MX-tietue on määritetty väärin (Postfix 2019b).

”reject_non_fqdn_sender”-parametrilla yhteys hylätään, jos viestin kirjekuoren ”MAIL FROM”-osoitteen toimialuenimi ei ole FQDN-nimi (Postfix 2019b).

”reject_unknown_client_hostname”-parametrilla vastaanottava palvelin hylkää SMTP- yhteyden, jos SMTP-asiakasohjelmana toimivan lähettävän palvelimen IP-osoite ei ole osoitettavissa isäntänimeen tai isäntänimi ei ole osoitettavissa IP-osoitteeseen. Toisin sa- noen lähettäjältä puuttuu PTR- ja A-tietueet. Yhteys hylätään myös, jos isäntänimeä vastaava IP-osoite ei vastaa lähettävän palvelimen IP-osoitteeseen. (Postfix 2019b.)

SMTP-yhteyden HELO/EHLO-komennoissa esiintyvä IP-osoite tai isäntänimi tulisi myös tarkistaa. Postfix-siirto-ohjelmassa tulee ensin määritellä ”smtpd_helo_required” arvoksi ”yes”, jotta HELO/EHLO-tarkistukset suoritetaan (Postfix 2019b). Tällöin hylätään kaikki yhteydenotot, jotka eivät sisällä HELO/EHLO-komentoa. Tarkemmat tarkistukset voidaan määritellä muun muassa seuraavilla parametreilla:

”reject_invalid_helo_hostname”-parametrilla vastaanottava palvelin hylkää SMTP-yhteyden lähettävään SMTP-asiakasohjelmaan, jos HELO/EHLO-komennoissa esiintyvä isäntänimi on puutteellinen (Postfix 2019b).

”reject_non_fqdn_helo_hostname”-parametrilla yhteys hylätään, jos HELO/EHLO-komennon isäntänimi ei ole FQDN-nimi tai lähettäjän IP-osoite on virheellinen (Postfix 2019b).

“reject_unknown_helo_hostname”-parametrilla vastaanottaja hylkää yhteyden, jos HELO/EHLO-komennon isäntänimellä ei ole nimipalvelun A- tai MX-tietueita (Postfix 2019b).

149

Muita hyödyllisiä tarkistuksia Postfixissä ovat vastaanottajaosoitteelle tehtävät tarkistukset.

”reject_unauth_destination”-parametrilla vastaanottava palvelin hylkää yhteyden, ellei se itse toimi lopullisena vastaanottajana tai sähköpostin edelleen lähettäjänä (Postfix 2019b).

”reject_non_fqdn_recipient”-parametrilla yhteys hylätään, jos viestin kirjekuoren ”RCPT TO”-osoitteen toimialuenimi ei ole FQDN-nimi (Postfix 2019b).

”reject_unknown_recipient_domain”-parametrilla vastaanottava SMTP-palvelin hylkää yhteyden, jos se ei itse toimi lopullisena vastaanottajana ja viestin kirjekuoren ”RCPT TO”- osoitteella ei ole nimipalvelun A- tai MX-tietueita tai jos MX-tietue on määritetty väärin (Postfix 2019b).

”reject_unauth_pipelining”-parametrilla yhteys hylätään, jos lähettävä SMTP-asiakasohjelma lähettää SMTP-komentoja etuajassa ilman lupaa, tai jos asiakasohjelma lähettää komentoja palvelimelle tietämättä, tukeeko vastaanottava palvelin laajennettua SMTP-kanavointia. Tällä tarkoitetaan usean SMTP-komennon sisällyttämistä yhteen tietoliikenne- lähetykseen (IETF 2000). Kyseisellä parametrilla voidaan vähentää massapostitusta ohjel- mistoista, jotka väärinkäyttävät komentojen kanavointia nopeuttaakseen postin toimitusta. (Postfix 2019b.)

Samanaikaisten yhteysmäärien rajoittamista voidaan toteuttaa muun muassa seuraavin parametrein:

“smtpd_client_connection_count_limit”-parametri määrittelee yhteydenottojen maksi- mimäärän, jonka tietty SMTP-asiakasohjelma voi tehdä samanaikaisesti. Oletusarvo on 50. (Postfix 2019d.)

“smtpd_client_connection_rate_limit”-parametri määrittelee yhteydenottojen maksimi- määrän, jonka tietty SMTP-asiakasohjelma voi tehdä ”anvil_rate_unit”-parametrin määrit- telemällä aikavälillä, jonka oletusarvo on 60 sekuntia (Postfix 2019d).

”smtpd_client_message_rate_limit”-parametri määrittelee, kuinka monta sähköposti- viestin välityspyyntöä lähettävä asiakasohjelma voi tehdä ”anvil_rate_unit”-parametrin määrittelemällä aikavälillä, jonka oletusarvo on 60 sekuntia (Postfix 2019d).

150

Ulospäin suuntautuvassa liikenteessä

Postfix-siirto-ohjelmassa on ”smtpd_relay_restrictions”-parametri, joka estää tuntemattomia tahoja käyttämästä sähköpostipalvelinta avoimena välityspalvelimena. Oletuksena Postfix sallii edelleenvälitykset asiakasohjelmilta, joiden IP-osoitteet vastaavat Postfixin konfiguraatiossa määritellyn ”$mynetworks”-muuttujan kanssa. Kyseinen muuttuja listaa kaikki sallitut etäiset SMTP-asiakasohjelmat. Postfix sallii sitten viestien edelleen lähetyk- set vastaanottajille, jotka vastaavat ”$relay_domains”-muuttujan kanssa. Se sallii lähetyk- set myös paikallisille vastaanottajille. (Postfix 2019b.)

Yhteysmäärien rajoittaminen onnistuu myös lähtevässä liikenteessä. Postfixin omasta konfiguraatiosta löytyy parametreja, joilla lähtevää liikennettä voidaan rajoittaa (Steam.io 2013).

“default_destination_concurrency_limit”-parametri määrittelee samanaikaisten sähkö- postitoimituksien maksimimäärän samalle vastaanottajalle. Oletusarvo on 20. (Postfix 2019b.)

”default_destination_rate_delay”-parametri määrittelee viiveen sekunteina, joka kuluu samalle vastaanottajalle lähetettyjen yksittäisten sähköpostiviestien toimituksien välillä ja saman lähetyksen aikana. Oletusarvo on nolla sekuntia, mutta se voidaan asettaa esimerkiksi sekuntiin antamalla sille arvo ”1s”. Tällöin kaikkien samalle vastaanottajalle lähetetty- jen viestien välillä kuluu aikaa vähintään sekunti. (Postfix 2019b.)

“default_extra_recipient_limit”-parametri määrittelee maksimimäärän vastaanottajia kullekin lähetetylle viestille (Steam.io 2013). Oletusarvo on 1000 (Postfix 2019b).

151

Liite 3. Vapaaehtoiset DKIM-tunnisteet

Allekirjoitetun viestin DKIM-allekirjoitus talletetaan sähköpostiviestin otsaketietoihin ”DKIM-Signature”-kenttään (IETF 2011a, 18). Kenttä koostuu useasta tunnisteesta alla olevan esimerkkiallekirjoituksen mukaisesti. Opinnäytetyön luvussa 6.3.2 on kuvattu vain tärkeimmät ja pakolliset tunnisteet. Loput hyödylliset, mutta vapaaehtoiset tunnisteet löyty- vät selityksineen alta.

Esimerkki 12. Tyypillinen DKIM-allekirjoitus sähköpostiviestin otsaketiedoissa

c = Määrittelee käytettävät algoritmit tilanteisiin, joissa sähköpostipalvelimet joutuvat muuttamaan viestin otsaketietoja. Kyseiset algoritmit määrittelevät, millä laajuudella muutoksia voidaan tehdä. Otsaketietojen muokkaus voi ni- mittäin johtaa allekirjoituksen mitätöimiseen. Algoritmit erotellaan kauttavii- valla. Oletusvaihtoehto on ”simple/simple”, jonka ensimmäinen puolisko kertoo otsaketietoihin käytettävän algoritmin ja kauttaviivan jälkeinen puolisko sisältöosaan käytettävän algoritmin (IETF 2011a, 20). ”Simple”-algoritmin kanssa otsakekenttiä ei muuteta mitenkään. Toinen käytettävistä algorit- meista on ”relaxed”, joka taas sallii pienet otsaketietojen muokkaukset. Va- paaehtoinen tunniste. (IETF 2011a, 15-16.)

q = Kyselymenetelmät, joita käytetään lähettäjän julkisen avaimen noutamiseksi. Menetelmät erotetaan puolipisteellä. Oletusvaihtoehto on ”dns/txt”, joka on myös tällä hetkellä RFC 6376 -standardin mukaisesti ainoa pätevä arvo. Tällöin vastaanottava sähköpostipalvelin tekee nimipalvelukyselyn lä- hettäjän TXT-tietueesta. Vapaaehtoinen tunniste. (IETF 2011a, 23.)

i = Ylimääräinen tunniste, joka määrittelee vielä tarkemmin viestin lähettä- neen yksilön. Tunnisteessa käytettävän toimialuenimen tulee olla sama, kuin d-tunnisteessa, tai d-tunnisteen alitoimialue. Yllä olevassa esimerkissä viestin lähettäjänä on ollut example.net-toimialueen alitoimialue eng.example.net. Vapaaehtoinen tunniste. (IETF 2011a, 21-22.)

152

t = Aikaleima, jolloin allekirjoitus luotiin. Merkitään kuluneina sekunteina päi- vämäärän 1.1.1970 ja kellonajan 00:00:00 jälkeen. Vapaaehtoinen, mutta suositeltava tunniste. (IETF 2011a, 24.) x = Allekirjoituksen vanhenemisaika. Käyttää samaa muotoilua, kuin t-tunnisteessa. Arvon täytyy olla t-aikaleimaa suurempi, jos molemmat on sisällytetty kenttään. Allekirjoitus ei oletusarvoisesti ei vanhene. Vapaaehtoinen, mutta suositeltava tunniste. (IETF 2011a, 24.) z = Lista opinnäytetyön luvun 3.1.2 mukaisista otsaketietokentistä, jotka olivat otsaketiedoissa läsnä allekirjoituksen aikana. Otsaketiedot erotetaan pystyviivalla ”|”. Vapaaehtoinen tunniste. (IETF 2011a, 25.)

153

Liite 4. Vapaaehtoiset DMARC-tunnisteet

DMARC-tietue jakautuu useisiin tunnisteisiin DKIM-tietueiden tavoin, kuten esimerkistä 13 voidaan nähdä (IETF 2015a, 16). Opinnäytetyön luvussa 6.4.1 käydään läpi oleellisimmat tunnisteet. Loput vapaaehtoiset, mutta hyödylliset tunnisteet löytyvät alta.

_dmarc.example.net. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Esimerkki 13. Tyypillinen nimipalvelun DMARC-tekstitietue

rua = Sähköpostiosoite, johon halutaan lähetettävän DMARC:n yhteenveto- raportit. Sisältää tietoa esimerkiksi niiden viestien määrästä, joihin p-tunnisteen käytäntö otettiin käyttöön ja yleistä statistiikkaa DMARC-tarkistusten tuloksista. Vapaaehtoinen tunniste. (IETF 2015a, 19.)

ruf = Sähköpostiosoite, johon halutaan lähetettävän DMARC:n virheraportit. Sisältää yksityiskohtaista tietoa yksittäisistä hylätyistä viesteistä. Vapaaeh- toinen tunniste. (IETF 2015a, 20.)

pct = Prosenttiosuus viesteistä, joihin p-tunnisteessa määritelty käytäntö tulee käyttöönottaa. Arvo väliltä 0-100. Vapaaehtoinen tunniste. (IETF 2015a, 18-19.)

sp = Alitoimialueiden kanssa toivottu viestin vastaanottokäytäntö. Kertoo, mitä vastaanottajan tulisi tehdä viestillä, jos se läpäisee DMARC-tarkistuksen. Pätee ainoastaan toimialuenimen alitoimialueiden kanssa. Mahdolliset arvot ovat samat, kuin p-tunnisteessa. Vapaaehtoinen tunniste. (IETF 2015a, 20.)

154

Liite 5. Ensimmäisessä kyselyerässä IT-henkilöstölle kohdistettu viesti

Hei,

Tämä viesti on suunnattu yrityksenne sisäisistä IT-palveluista vastaavalle henki- lölle. Jos viesti on tullut väärälle taholle, pahoittelen asiaa ja pyytäisin teitä välittä- mään viestin eteenpäin oikealle henkilölle tai ilmoittamaan minulle sähköpostitse hänen sähköpostiosoitteensa. Kiitos!

Teen kyselytutkimusta osana Haaga-Helia -ammattikorkeakoulun opinnäytetyötä, jossa tutkin suomalaisten IT-alan yritysten käyttämiä roskapostin torjuntakeinoja. Yhtenä tutkimuksen tavoitteena on luoda mittari erikokoisten yritysten käyttämistä torjuntatekniikoista. Tulosten pohjalta yritykset voivat verrata omia käytäntöjään muihin samankokoisiin yrityksiin ja kehittää sähköpostipalveluitaan.

Linkki kyselylomakkeeseen: https://docs.google.com/forms/d/e/1FAIpQLSfQddp_moA6aIgrZtd-69hGbql- 8QaKpdLqqVERt0MC4POIGQ/viewform

Osallistumisenne on toivottavaa tarpeeksi suuren otannan keräämiseksi. Kyselylomake on lähetetty vain rajalliselle määrälle suomalaisia IT-alan yrityksiä.

Jos teillä on kysyttävää tai haluatte lisätietoja tutkimukseen liittyen, voitte vastata tähän viestiin.

Kiitollisin terveisin,

Markus Pyhäranta Tietojenkäsittelyn opiskelija Haaga-Helia -ammattikorkeakoulussa [email protected]

155

Liite 6. Ensimmäisessä kyselyerässä asiakaspalveluun tai tukeen lähetetty viesti

Hei,

Tämä viesti on tarkoitettu yrityksenne sisäisistä IT-palveluista vastaavalle henki- lölle. Olisiko mahdollista, että voisitte ohjata tämän viestin kyseiselle henkilölle yri- tyksessänne? Kiitos!

Linkki kyselylomakkeeseen: https://docs.google.com/forms/d/e/1FAIpQLSfQddp_moA6aIgrZtd-69hGbql- 8QaKpdLqqVERt0MC4POIGQ/viewform

Osallistumisenne on toivottavaa tarpeeksi suuren otannan keräämiseksi. Kyselylomake on lähetetty vain rajalliselle määrälle suomalaisia IT-alan yrityksiä.

Jos teillä on kysyttävää tai haluatte lisätietoja tutkimukseen liittyen, voitte vastata tähän viestiin.

Kiitollisin terveisin,

Markus Pyhäranta Tietojenkäsittelyn opiskelija Haaga-Helia -ammattikorkeakoulussa [email protected]

156

Liite 7. Toisessa kyselyerässä IT-henkilöstölle kohdistettu viesti

Hei,

Tämä on muistutus kyselytutkimukseen osallistumisesta, jonka lähetin teille 12.5. Jos olette jo vastanneet tutkimukseen aiemmin, voitte jättää viestin huomioimatta! Tässä tapauksessa pahoittelen ylimääräistä roskapostia.

Viesti on suunnattu yrityksenne sisäisistä IT-palveluista vastaavalle henkilölle. Jos viesti on tullut väärälle taholle, pahoittelen asiaa ja pyytäisin teitä välittämään viestin eteenpäin oikealle henkilölle tai ilmoittamaan minulle sähköpostitse hänen säh- köpostiosoitteensa. Kiitos!

Kyselytutkimus tapahtuu verkkolomakkeella, jossa on vain kahdeksan pakollista kohtaa. Pääosa kysymyksistä on monivalintakysymyksiä. Vastaaminen on täysin anonyymia ja siinä menee noin viisi minuuttia. Kiitos jo etukäteen vastaamisesta! Haluan myös kiittää niitä, jotka ovat vastanneet aiemmin mutta saavat tämän viestin turhaan uudelleen.

Linkki kyselylomakkeeseen: https://docs.google.com/forms/d/e/1FAIpQLSfQddp_moA6aIgrZtd-69hGbql- 8QaKpdLqqVERt0MC4POIGQ/viewform

Tähän mennessä kyselyyn on vastannut 54 suomalaista yritystä. Vastaamatta jättäneiden osallistuminen on kuitenkin toivottavaa tarpeeksi suuren otannan keräämiseksi. Kyselylo- make on lähetetty vain rajalliselle määrälle suomalaisia IT-alan yrityksiä. Kattavat tulokset julkaistaan niiden valmistuttua osoitteessa http://thesis.markuspyharanta.com/. Jos teillä on kysyttävää tai haluatte lisätietoja tutkimukseen liittyen, voitte vastata tähän viestiin.

Kiitollisin terveisin, Markus Pyhäranta Tietojenkäsittelyn opiskelija Haaga-Helia -ammattikorkeakoulussa [email protected]

157

Liite 8. Toisessa kyselyerässä asiakaspalveluun tai tukeen lähetetty viesti

Hei,

Viesti on tarkoitettu yrityksenne sisäisistä IT-palveluista vastaavalle henkilölle. Oli- siko mahdollista, että voisitte ohjata tämän viestin kyseiselle henkilölle yritykses- sänne? Viestiin ei tarvitse vastata. Kiitos!

Linkki kyselylomakkeeseen: https://docs.google.com/forms/d/e/1FAIpQLSfQddp_moA6aIgrZtd-69hGbql- 8QaKpdLqqVERt0MC4POIGQ/viewform

Kiitollisin terveisin,

Markus Pyhäranta Tietojenkäsittelyn opiskelija Haaga-Helia -ammattikorkeakoulussa [email protected]

158

Liite 9. Tutkimuksen kyselylomake

Kuva 36. Kyselylomakkeen johdanto

159

Kuva 37. Kyselylomakkeen kysymykset 1-4

Kuva 38. Kyselylomakkeen kysymys 5

160

Kuva 39. Kyselylomakkeen kysymys 6

161

Kuva 40. Kyselylomakkeen kysymys 7

162

Kuva 41. Kyselylomakkeen kysymys 8

163

Kuva 42. Kyselylomakkeen kysymykset 9-10

164

Liite 10. D-Fence-sähköpostiturvayhtiön perustajan sähköpostihaastattelu

Seuraavat kysymykset esitettiin sähköpostitse D-Fencen perustajalle ja hallituksen pu- heenjohtajalle (Oravala 29.5.2019). Yrityksen antamat vastaukset näkyvät kunkin kysy- myksen alapuolelta.

1. Kysymys: Mitkä ovat teidän näkökulmastanne ajankohtaisimmat sähköpostitse levite- tyt verkkouhat tällä hetkellä? Ovatko ne tietojenkalastelua, kohdennettua verkkourkintaa vai mitä?

Vastaus: Toimitusjohtajahuijaukset, jotka koko ajan paranevat lienevät tämän hetken suurin uhka.

2. Kysymys: Mikä roskapostin torjunnassa on teidän näkökulmastanne haastavinta tällä hetkellä? (esimerkiksi tietynlaiset roskapostityypit tai -lähettäjät)

Vastaus: Mainsleaze. Eli markkinointipostit, jotka saajalleen ovat usein spammiä.

3. Kysymys: Roskapostittajien käyttämät ohjelmistot kehittyvät, jolloin vanhempien torjuntatekniikoiden, kuten harmaalistauksen ja nolistingin hyödyt heikkenevät. Millaisin keinoin roskapostiin vastataan mielestänne tulevaisuudessa?

Vastaus: -

4. Kysymys: Näettekö kysynnän kasvavan pilvipalvelupohjaisille roskapostisuodattimille ja sähköpostin turvapalveluille tulevaisuudessa? Sähköpostipalvelut jatkavat siirtymis- tään pilveen, joten ovatko erilliset turvapalvelut enää tarpeellisia, jos sähköpostin palveluntarjoaja hoitaa myös roskapostin torjunnan asiakasorganisaation puolesta?

Vastaus: Nopein O 365 ratkaisuun siirtynyt “paluumuuttaja” oli 20 minuuttia MX:ien käännön jälkeen kiireellinen vaatimus D-Fence eSecin takaisinkytkennälle viestillä “ei- hän tätä kestä Erkkikään...”.

Eli näyttää siltä, että pilviympäristö ei oleellisesti eroa turvallisuuden puolesta, lisätur- valle on kysyntää, toki riippuen asiakkaan liiketoiminnasta. Keitä ovat päämiehet? Keitä ovat asiakkaat ja muut sidosryhmät? Se antaa perspektiiviä toimijan turvataso- vaatimukselle.

165

5. Kysymys: Onko teillä antaa tilastotietoja siitä, kuinka paljon asiakkaidenne sähköpos- tiliikenteestä on keskimäärin roskapostia?

Vastaus: n. 70 %

6. Kysymys: Minkälaista roskapostia pääsee eniten läpi suodattimistanne?

Vastaus: Mainsleazea. Ongelma on, että legitiimiä postiliikennettä lähetetään samojen alustapalveluiden kautta kuin sitten markkinointiviestintää >> käytännössä mahdoton torjua proaktiivisesti ilman isoa false positive –ratea.

7. Kysymys: Millaisia uhkia palvelunne torjuvat tällä hetkellä eniten?

Vastaus: -

8. Kysymys: Voisitteko tarkentaa, miten palvelunne hyödyntämä UIDS-teknologia toimii? Sanotte käyttävänne sitä lähettävän palvelimen oikeellisuuden varmistukseen SMTP- yhteyden aikana. Mitä tietoa keräätte lähettävästä palvelimesta ja mitä sillä tehdään? Vertaatteko lähettävän palvelimen tietoja tietokantoihinne tallennettuihin tietoihin tun- nistaaksenne lähettäjän aiempien havaintojen perusteella, vai mitä kyseisessä vaiheessa tapahtuu? Mikä käyttämänne ID-algoritmi on ja mikä on sen rooli bottikoneiden tunnistamisessa?

Vastaus: Emme avaa sitä tarkemmin :)

9. Kysymys: Kun olette tehneet tarkistuksen lähettävästä palvelimesta, sanotte laske- vanne sähköpostille myös spam-pistearvon. Mihin tuo pistearvo perustuu? Käytättekö kyseisessä vaiheessa esimerkiksi DNSBL-listoja, viestin sisällönsuodatusta tai bayesilaista suodatusta sähköpostin arviointiin? Perustuvatko nämä toiminnot johonkin vapaan ohjelmiston suodattimeen, kuten SpamAssassiniin? Mitä kaikkia tunnettuja torjuntatekniikoita on yhdistetty palvelussanne?

Vastaus: Käytämme niitä kaikkia, omilla painoarvoillaan, joita monitoroidaan ja sääde- tään koko ajan.

166

10. Kysymys: Palveluunne sisältyy tunkeutumisenesto, jossa väärennetyistä lähettäjä- osoitteista tapahtuvat yhteydenotot hylätään. Mihin tarkistuksiin tämä verkkotunnuksien suodatus perustuu? Tarkistatteko lähettäjätoimialueen SPF, DKIM ja DMARC- tietueet ennen viestin vastaanottoa?

Vastaus: -

11. Kysymys: Mitkä käytännön esteet ovat mielestänne suurimpia DMARC-tekniikan käyttöönotossa? Miksi sen käyttöönotto on yhä niin jälkeenjäänyttä esimerkiksi SPF- ja DKIM-tietueisiin nähden? Tutkimukseni tämänhetkiset tulokset osoittavat selvästi eniten kiinnostusta DMARC:in käyttöön kaikista niistä tekniikoista, joita vastaajat eivät olleet vielä käyttöönottaneet.

Vastaus: Näiden keskinen ongelma on, että ne eivät oikeasti toimi. Mm. SPF –konfi- geissa on jatkuvasti virheitä, yleisin lienee –all kun pitäisi olla ~all.

12. Kysymys: Palvelunne tunkeutumisenestoon sisältyy myös sähköpostijärjestelmän säännöllinen testaus ja auditointi. Mihin testeihin nämä perustuvat ja miten ne toteutetaan? Ovatko tekemänne testit esimerkiksi verrannollisia Office 365 Advanced Threat Protection (ATP) -palvelun sisältämiin simuloituihin hyökkäystyökaluihin?

Vastaus: -

13. Kysymys: Torjuntakeinojen osalta käsittelen opinnäytetyöni tietoperustassa alla esi- tettyjä tekniikoita. Puuttuuko niistä jotain, jonka itse näkisitte tärkeäksi tekniikaksi käsi- tellä tutkimuksessa?

• Roskapostintorjunta sen lähteen tai sisällön perusteella o SMTP-liikenteen suodattaminen (mm. lähettäjän olemassaolon tarkistus, IP-osoitteen tai isäntänimen tarkistukset PTR-/A-tietueista, HELO/EHLO-tarkistukset, vastaanottajan olemassaolon tarkistus, yh- teysmäärien tai viestien rajoittaminen) o DNS-pohjainen mustalistaus (DNSBL) o Harmaalistaus o Nolisting o Sähköpostin sisällönsuodatus o Bayesilainen suodatus

167

o Fyysiset roskapostin suodattimet o Pilvipalvelupohjainen roskapostisuodatus (mm. D-fence) • Lähettäjän ja viestin todentaminen sisään- ja ulospäin suuntautuvassa sähköposti- liikenteessä o Sender Policy Framework (SPF) o Sender ID o DomainKeys Identified Mail (DKIM) o Domain-based Message Authentication, Reporting & Conformance (DMARC) o Authenticated Received Chain (ARC)

Vastaus: -

14. Kysymys: Millaiset tulokset kiinnostaisivat teitä eniten tällaisessa tutkimuksessa? Ky- selytutkimuksen päätyttyä dataa on jo kertynyt kohtalaisen paljon. Onko jotain, mitä teidän mielestänne tulisi ehdottomasti käsitellä tuloksissa? Yrityksille lähettämäni kyselylomake oli tällainen: https://docs.google.com/forms/d/e/1FAIpQLSfQddp_moA6aIgrZtd-69hGbql- 8QaKpdLqqVERt0MC4POIGQ/viewform. Joudun luokittelemaan ja seulomaan dataa visuaalisesti ymmärrettävään muotoon, mutta tarkoituksenani on myös julkaista dataa raakamuodossa siitä kiinnostuneille.

Vastaus: -

168

Liite 11. Tutkimustulosten tulkinta

TULOSTEN TULKINTA 1. Johdanto Tässä taulukossa kuvataan ne tavat, joilla tutkimustuloksia tulkittiin. Esimerkkien avulla näytetään, miten tyypillisimpään vastaukseen päädyttiin. Taulukkotiedostossa esitettyjä tuloksia saa käyttää omiin tutkimuksiinsa, kunhan tekijä käyttää asiallista lähdeviitettä alkuperäisiin tuloksiin.

Tutkimuksen rajaus: Tutkimus keskittyy roskapostin torjuntaan yrityksen sisäisten sähköpostipalvelujen ylläpitäjän näkökulmasta, eikä siinä siten huomioida MUA-tason suodatusta. MUA-tason suodatuksella viitataan suodatukseen, joka tapahtuu loppukäyttäjän sähköpostiohjelmassa. Vastauksia on kerätty vain suomalaisilta IT-alan yrityksiltä.

2. Tyypillisin vastaus Kullekin yrityskoolle laskettiin niin sanottu tyypillisin vastaus, joka koostuu kyseisen yrityskoon vastaajien vastausten keskiarvoista ja tyyppivastauksista. Tyypillisin vastaus löytyy heti taulukoiden alusta, ja se voidaan nähdä tulosten yhteenvedoksi.

Tyyppivastaukset laskettiin kysymyksistä, joiden vastaukset olivat tekstimuodossa. Tällaisia olivat mm. vastaajan roolia ja yrityksen käyttämää sähköpostipalvelua kartoittavat kysymykset. Tyyppivastauksella tarkoitetaan vastauksissa yleisimmin esiintynyttä arvoa. Esimerkiksi jonossa "kissa, koira, marsu, kissa", tyyppivastaus on "kissa". Tyyppivastaus laskettiin myös yritysten käyttämiä torjuntatekniikoita kartoittavissa kysymyksissä. Niihin liittyen puhutaan tarkemmin taulukon osiossa 5.

Tyyppivastauksen laskemiseen käytettiin aina kaavaa "=INDEKSI(alue_alku:alue_loppu;MOODI.YKSI(VASTINE(alue_alku:alue_loppu;alue_alku:alue_loppu;0)))".

Keskiarvo taas laskettiin kysymyksistä, joissa vastaus oli numeromuodossa. Tällaisia olivat tyytyväisyyttä mittavat kysymykset, joissa vastaaja antoi numeerisen arvon väliltä 1- 5.

169

ESIMERKKI: TYYPILLISIN VASTAUS - ESIMERKKIYRITYSKOKO Vastaajien lkm: 4 Vastaajan rooli yrityksessä: Toimitusjohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 3.0 b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 3.5 c) kokonaisuudessa 3.3 Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SMTP-liikenteen suodatuksella Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuk-sen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla

3. Vastauksen yksillöllistäminen ja sen luotettavuus 3.1. Tunniste Tunniste Kukin vastaus kirjattiin omalle rivilleen. Jokaiselle vastaukselle annettiin oma yksilöllinen ID-tunnus. ID ID säilyy samana kussakin taulukossa, jolloin tietty yksilöllinen vastaus on helposti löydettävissä. 01 02 Esimerkkisarake ID-tunnisteista näkyy tämän kappaleen oikealla puolella. Tutkimukseen vastasi yhteensä 74 yritystä, joten ID-tunnukset ovat väliltä 01-74. 03

3.2. Vastaajan rooli yrityksessä Vastaajan rooli yrityksessä Tästä sarakkeesta laskettiin tyyppivastaus, joka kertoo vastaajien yleisimmän toimenkuvan yrityksissä. Toimenkuva Kysymys sisällytettiin kyselylomakkeeseen, jotta voidaan halutessa mitata yksittäisen vastauksen laatua ja tarkkuutta. Toimitusjohtaja Järjestelmäasiantuntija

170

Tyyppivastaus näkyy viereisessä esimerkissä alimmalla rivillä, joka on korostettu tummansinisellä taustalla. Tyyppivastaus, eli yleisimmin esiintynyt vastaus, on siis esimerkissä "Toimitusjohtaja". Toimitusjohtaja Toimitusjohtaja

4. Palvelun tyytyväisyyttä ja käyttömääriä mittaavat tiedot 4.1. Tyytyväisyys järjestelmien kykyyn: (1-5) Palvelun tyytyväisyyttä käsittelevät tiedot jaettiin kolmeen sarakkeeseen kategorioittain, jotka mittasivat tyytyväisyyttä järjestelmien kykyyn: 1. suodattaa oikeita roskapostiviestejä 2. olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 3. tyytyväisyyden keskiarvo

Tyytyväisyyden keskiarvo laskettiin sarakkeiden 1 ja 2 keskiarvosta. Lisäksi kustakin sarakkeesta laskettiin oma keskiarvonsa, joka kertoo kaikkien vastaajien tyytyväisyyden keskiarvon kussakin kategoriassa. Sarakkeiden lasketut keskiarvot on korostettu alla olevassa vasemmanpuoleisessa esimerkissä viimeisellä rivillä tummansinisellä taustalla.

4.2. Käytetyt sähköpostipalvelut Tästä sarakkeesta laskettiin tyyppivastaus, joka kertoo vastaajien vastauksissa yleisimmin esiintyvän sähköpostipalvelun.

Tyyppivastaus näkyy alla olevasta oikeanpuoleisesta esimerkistä alimmalta riviltä, joka on korostettu tummansinisellä taustalla. Tyyppivastaus, eli yleisimmin esiintynyt vastaus, on siis esimerkissä "Office 365 (Exchange Online)".

Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Suodattaa oikeita roska- Olla merkitsemättä aitoja sähköposti- Tyytyväisyyden postiviestejä viestejä roskapostiksi keskiarvo Palvelun nimi / kuvaus 5 5 5 Office 365 (Exchange Online) 4 4 4 G Suite (Gmail) 1 2 1.5 Office 365 (Exchange Online) 4 5 4.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 3.5 4.0 3.8 Office 365 (Exchange Online)

171

4.3. Palvelukohtainen tyytyväisyys Tässä kohdassa laskettiin keskiarvot kutakin palvelua käyttäneiden vastauksista. Tyytyväisyys jaettiin kolmeen kategoriaan kohdan 4.1. esittämällä tavalla.

Alla olevan vasemmanpuoleisen esimerkin keskiarvot on laskettu kohdan 4.1 taulukon vastauksista, joista kaavaan on poimittu vain tiettyä palvelua käyttäneiden vastaukset. Esimerkin perusteella voidaan siis esimerkiksi sanoa, että Office 365 -käyttäjien tyytyväisyyden keskiarvo oli 3,3 asteikolla 1-5.

4.4. Palvelun osuus vastauksista Tässä laskettiin kunkin vastausvaihtoehdoissa esitetyn palvelun osuus kaikista vastauksista. Lasku perustuu kaavaan: "=LASKE.JOS(alue_alku:alue_loppu;"palvelun_nimi")". Siinä siis lasketaan etsittävän palvelun esiintymismäärä kaavassa määritellyltä alueelta.

Lisäksi määrällisen osuuden viereen laskettiin palvelun prosenttiosuus kaikista vastauksista. Vastaajien lukumäärä on aina ilmoitettu kohdassa 2. Tyypillisin vastaus, jolloin prosenttiosuus saatiin laskettua jakamalla viereisen sarakkeen osuus vastauksien kokonaismää- rällä. Alla olevasta oikeanpuoleisesta esimerkistä näemme, että Office 365 -palvelua käytti 50 % vastaajista.

Olla merkitsemättä ai- Suodattaa oikeita roska- toja sähköpostiviestejä Tyytyväisyyden kes- Palvelu postiviestejä roskapostiksi kiarvo Palvelu Palvelun osuus vastauksista % Office 365: 3.0 3.5 3.3 Office 365: 2 50 % G Suite: 4.0 4.0 4.0 G Suite: 1 25 % Itse ylläpidetty Linux: 4.0 5.0 4.5 Itse ylläpidetty Linux: 1 25 % Itse ylläpidetty Windows: 0.0 0.0 0.0 Itse ylläpidetty Windows: 0 0 % Muu: 0.0 0.0 0.0 Muu: 0 0 %

172

5. Torjuntatekniikoiden käyttömäärät Vastaajille annettiin kyselylomakkeessa viisi vastausvaihtoehtoa, jonka he pystyivät antamaan vastaukseksi kunkin kysytyn torjuntatekniikan kohdalla. Vastausvaihtoehdot muotoiltiin näissä tuloksissa visuaalisesti seuraavasti:

a On käytössä b Ei ole käytössä, mutta haluaisimme käyttää c Ei ole käytössä, emmekä näe tarpeelliseksi d En muista tai tiedä, käytämmekö e En tunne tätä tekniikkaa

Kukin sarake kuvaa, käyttävätkö vastaajat sarakkeen otsikossa esitettyä torjuntatekniikkaa. Vastaajat ovat vastanneet kysymykseen jollakin yllä esitetyllä viidellä vaihtoeh- dolla.

Vastauksista on sitten laskettu tyyppivastaus, jolla pyrittiin selvittämään vastauksissa yleisimmin esiintynyt arvo. Tyyppivastauksia laskeva Excel-kaava ei kuitenkaan osaa ilmoittaa, jos sarakkeessa tapahtuu tasapeli vastausten välillä. Esimerkiksi, jos neljästä vastauksesta kaksi on "a" ja kaksi "b", Excel ilmoittaa tyyppivastaukseksi sen, joka tulee sarakkeessa ensimmäisenä vastaan.

Lisäksi on muita poikkeustapauksia, joita esiintyy vastausten tulkinnassa. Kunkin sarakkeen alapuolella on merkintä, joka ilmoittaa esiintyneestä poikkeamasta.

Poikkeustapaukset ja niitä kuvaavat merkinnät:

X Selitys: Vastausta "a" ei katsota tyyppivastaukseksi. Syy: Vastausten "b" ja "c" yhteenlaskettu määrä ylittää vastauksen "a" määrän.

Vaikka "b" ja "c" ovat eri vastauksia, ne molemmat silti kertovat, ettei vastaaja käytä kyseistä tekniikkaa.

173

Tällöin ne ovat samanarvoisia, kun pyritään selvittämään, onko sarakkeen tyyppivastauksena "a". Tilanne saattaa näyttää tasapeliltä, minkä vuoksi tällaiset poikkeukset merkitään aina, vaikka vastausta "a" ei olisikaan merkitty tyyppivastaukseksi".

Excel saattaa silti ilmoittaa "a":n tyyppivastaukseksi, koska se ei osaa tulkita kahden muun eri vastauksen samanarvoisuutta tulosten tulkinnassa.

X Selitys: Tasapeli vastausten suhteen, joten "a" lasketaan mukaan tyyppivastaukseen. Syy: Sarakkeesta löytyy sama määrä jotain toista vastausta, tai vastausten "b" ja "c" yhteenlaskettu määrä vastaa vastausten "a" mää- rää.

Vaikka "b" ja "c" ovat eri vastauksia, ne molemmat silti kertovat, ettei vastaaja käytä kyseistä tekniikkaa. Tällöin ne ovat samanarvoisia, kun pyritään selvittämään, onko sarakkeen tyyppivastauksena "a". Tasapeli ilmoitetaan aina, vaikka "a" olisikin ilmoitettu tyyppivastaukseksi joka tapauksessa.

Tasapeli voi siis muodostua kahdella tavalla: 1. jonkin muun vastauksen määrä vastaa vastausten "a" määrää 2. vastausten "b" ja "c" yhteenlaskettu määrä vastaa vastausten "a" mää- rää

Tasapelissä vastaus "a" lasketaan aina mukaan kohtaan 2. Tyypillisin vastaus, jos vastaus "a" on tasapelin toisena osapuolena.

174

Poikkeustapausten esimerkkejä:

Roskapostin torjunta lähteen tai sisällön perusteella Tekniikka 1 Tekniikka 2 Tekniikka 3 a c c a b c b b a c a b c a a a b c X X X Enemmistö ei käytä Enemmistö ei käytä Enemmistö ei käytä

Roskapostin torjunta lähteen tai sisällön perusteella Tekniikka 1 Tekniikka 2 Tekniikka 3 c c d c a a d a d a b a a e c c a d X X X Tasapeli Tasapeli Tasapeli

175

5.1. Roskapostin torjunta lähteen tai sisällön perusteella Tämä kohta jaettiin yhdeksään sarakkeeseen, jotka koostuivat tutkimuksen kyselylomakkeen 6. kysymyksessä mainituista torjuntatekniikoista. Seuraavan liitesivun esimer- kissä näytetään näistä vain neljä. Kyseisistä sarakkeista laskettiin sitten tyyppivastaus, joka kertoi useimmin esiintyvän vastausvaihtoehdon kyseisen sarakkeen torjuntatekniikalle.

Tyyppivastaus näkyy seuraavan liitesivun esimerkistä kunkin sarakkeen kohdalla alimmalta riviltä, joka on korostettu tummansinisellä taustalla.

Huomaa X-merkatut poikkeukset tyyppivastausten alapuolella!

5.2. Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä Tämä kohta jaettiin kuuteen sarakkeeseen, jotka koostuivat tutkimuksen kyselylomakkeen 7. kysymyksessä mainituista torjuntatekniikoista. Seuraavan liitesivun esimerkissä näytetään näistä vain neljä. Kyseisistä sarakkeista laskettiin sitten tyyppivastaus, joka kertoi useimmiten esiintyvän vastausvaihtoehdon kyseisen sarakkeen torjuntatekniikalle.

Tyyppivastaus näkyy seuraavan liitesivun esimerkistä kunkin sarakkeen kohdalla alimmalta riviltä, joka on korostettu tummansinisellä taustalla.

Huomaa X-merkatut poikkeukset tyyppivastausten alapuolella!

5.3. Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus Tämä kohta jaettiin kuuteen sarakkeeseen, jotka koostuivat tutkimuksen kyselylomakkeen 8. kysymyksessä mainituista torjuntatekniikoista. Seuraavan liitesivun esimerkissä näytetään näistä vain neljä. Kyseisistä sarakkeista laskettiin sitten tyyppivastaus, joka kertoi useimmiten esiintyvän vastausvaihtoehdon kyseisen sarakkeen torjuntatekniikalle.

Tyyppivastaus näkyy seuraavan liitesivun esimerkistä kunkin sarakkeen kohdalla alimmalta riviltä, joka on korostettu tummansinisellä taustalla.

Huomaa X-merkatut poikkeukset tyyppivastausten alapuolella!

176

Roskapostin torjunta lähteen tai sisällön perusteella Pilvipohjainen roskapostisuodatus Palvelun oletustekniikat eri palveluntarjoajalta SMTP-liikenteen suodatus Mustalistaus (DNSBL) a a c a a a a a a b a b a c c c a c c d a a c a X X

Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä Palvelun oletustekniikat SPF Sender ID DKIM a a c c a a c c a d e d a a c a a a c a a a c c X

Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus Palvelun oletustekniikat SPF Sender ID DKIM a a c c a a c b a b e b a a c a a c c a a a c b X

177

5.4. Torjuntatekniikoiden vastausmäärät Tässä laskettiin vastausvaihtoehtojen vastausmäärät numeerisessa taulukossa kullekin torjuntatekniikalle. Lasku perustuu kaavaan: "=LASKE.JOS(alue_alku:alue_loppu;"vastaus")". Siinä siis lasketaan etsittävän vastauksen esiintymismäärä kaavassa määritellyltä alueelta.

Jos ylemmissä sarakkeissa on ollut poikkeustapauksia, niiden syyt on korostettu tässä poikkeusta vastaavalla värillä. Esimerkiksi kohdan 5.3. poikkeuksen syy on korostettu seuraavan liitesivun esimerkissä punaisella.

5.5. Muut vastaajien käyttämät torjuntamenetelmät Tässä sarakkeessa näkyy vastaajien käyttämiä torjuntamenetelmiä, joita kyselytutkimuksessa ei muuten kysytty. Iso osa vastauksista oli joko tutkimuksen rajauksen ulkopuolella tai tarkensi vastaajan käyttämän pilvipalvelupohjaisen roskapostisuodatuksen nimen.

Kysymykseen vastaaminen oli vapaaehtoista, eikä siten joka rivillä ole vastausta. Vastaukset olivat vapaamuotoisia, joten niistä ei laskettu tyyppivastausta.

Vastaukset, jotka eivät kuuluneet tutkimuksen rajaukseen, on merkitty merkillä *. Merkityt vastaukset kertovat lisää vastaajien sähköpostijärjestelmistä, mutta niitä ei hyödynnetä tämän opinnäytetyön tutkimustuloksissa.

5.6. Muut torjuntatekniikat, joita vastaajat haluaisivat käyttää Tässä sarakkeessa näkyy torjuntamenetelmät, joita kyselytutkimuksessa ei kysytty ja joita vastaajat eivät vielä käytä mutta haluaisivat tulevaisuudessa. Kaikki esiintyneet vastaukset olivat tutkimuksen rajauksen ulkopuolella.

Kysymykseen vastaaminen oli vapaaehtoista, eikä siten joka rivillä ole vastausta. Vastaukset olivat vapaamuotoisia, joten niistä ei laskettu tyyppivastausta.

178

Vastausvaihtoehdot Vastausten kokonaismäärä per torjuntatekniikka: On käytössä: 5 3 0 2 Ei ole käytössä, mutta haluaisimme käyttää: 0 1 0 2 Ei ole käytössä, emmekä näe tarpeelliseksi: 0 1 4 1 En muista tai tiedä, käytämmekö: 0 0 0 0 En tunne tätä tekniikkaa: 0 0 1 0

Muut vastaajien käyttämät torjuntamenetelmät Vapaamuotoinen vastaus D-Fence eSec

Thunderbirdin sisäinen suodatus *

Muut vastaajien käyttämät torjuntamenetelmät Vapaamuotoinen vastaus

Salattu sähköposti *

179

Liite 12. Kyselyvastaukset: Mikroyritykset (1-9 henkilöä)

TYYPILLISIN VASTAUS - MIKROYRITYKSET (1-9 HENKILÖÄ) Vastaajien lkm: 29 Vastaajan rooli yrityksessä: Toimitusjohtaja Yrityksen käyttämä sähköpostipalvelu: G Suite (Gmail) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4.4 b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 3.8 c) kokonaisuudessa 4.1 Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla Sähköpostin sisällönsuodatuk- sella Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla

180

Tunniste Vastaajan rooli yrityksessä Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Olla merkitsemättä Suodattaa oikeita aitoja sähköposti- roskapostivies- viestejä roskapos- Tyytyväisyyden ID Toimenkuva tejä tiksi keskiarvo Palvelun nimi / kuvaus 01 Asiantuntija 5 5 5 Office 365 (Exchange Online) 02 Toimitusjohtaja 4 4 4 G Suite (Gmail) 03 Yrittäjä, Toimitusjohtaja 1 2 1.5 Muu: Webhotellin sähköpostipalvelu 04 Yrittäjä 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 05 IT-Päällikkö 3 5 4 Muu: Ulkopuolisen tarjoama sähköpostipalvelin, itse ylläpitämä 06 Toimitusjohtaja 4 4 4 G Suite (Gmail) 07 Presidentti 5 5 5 Muu: D-Fence Email Security 08 IT-asiantuntija, kyberturva 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 09 Tekninen johtaja 5 5 5 G Suite (Gmail) 10 Verkkosivuvastaava 1 4 2.5 Muu: Webhotellin sähköpostipalvelu (Linux-pohjainen) 11 Toimitusjohtaja 1 2 1.5 Muu: Mac Mail / Outlook 12 Operatiivinen johtaja 4 4 4 Office 365 (Exchange Online) 13 Toimitusjohtaja 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 14 Yrittäjä 3 4 3.5 Office 365 (Exchange Online) 15 Toimitusjohtaja 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 16 Järjestelmänvalvoja 1 2 1.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 17 Tietohallintojohtaja 4 2 3 G Suite (Gmail) 18 Toimitusjohtaja 5 4 4.5 G Suite (Gmail) 19 IT-päällikkö 4 4 4 Office 365 (Exchange Online) 20 IT-johtaja 5 5 5 Muu: Office 365 Hybrid 21 Vähän kaikkia 4 4 4 G Suite (Gmail) 22 Toimitusjohtaja 5 3 4 G Suite (Gmail) 23 Asiantuntija 5 5 5 Office 365 (Exchange Online) 24 Teknologiajohtaja 4 3 3.5 G Suite (Gmail) 25 Yrittäjä 4 4 4 G Suite (Gmail) 26 Toimitusjohtaja 4 4 4 G Suite (Gmail) 27 Osakkeenomistaja 5 5 5 G Suite (Gmail)

181

28 Toimitusjohtaja 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 29 Palvelutuotantojohtaja 3 4 3.5 Muu: Sigmatic/Nebula IMAP-sähköpostipalvelu Keskiarvo tai tyyppivastaus: Toimitusjohtaja 3.9 4.0 3.9 G Suite (Gmail)

Olla merkitsemättä Suodattaa oikeita aitoja sähköposti- roskapostivies- viestejä roskapos- Tyytyväisyyden Palvelu tejä tiksi keskiarvo Palvelun osuus vastauksista % Palvelukohtainen Office 365: 4.2 4.4 4.3 5 17 % tyytyväisyys: G Suite: 4.4 3.8 4.1 11 38 % Itse ylläpidetty Linux: 4.0 4.2 4.1 6 21 % Itse ylläpidetty Windows: 0.0 0.0 0.0 0 0 % Muu: 2.7 3.9 3.3 7 24 %

182

Roskapostin torjunta lähteen tai sisällön perusteella ID Pilvipohjainen roskaposti- Palvelun oletus- suodatus eri palveluntar- SMTP-liiken- Mustalistaus Harmaalis- Sähköpostin sisällön- Bayesilainen Fyysiset roskaposti- tekniikat joajalta teen suodatus (DNSBL) taus Nolisting suodatus suodatus suodattimet 01 a c a a a c a a c 02 a c c c c c c c c 03 a b b c c e b b c 04 a c a a a a a a a 05 a d d a d d a d d 06 a c c c c c c c c 07 a a a a a a a a a 08 a c a c c c a a c 09 a c a c c c c c a 10 d d d d d d d d d 11 a c d a e e a a e 12 a c e c c e e e e 13 a a a a a c a a c 14 a c c c c e e e c 15 c c a a a a a a a 16 a b a c a b a a b 17 a a d d d d c c c 18 a c c c c c c c c 19 a a a a a a a a c 20 a c c c c c a c c 21 a c c c c c c c c 22 a c c c c c c c c 23 a a b a a b a c c 24 a b a a a a a a b 25 a c c c c c c c c 26 a c c c c c c a c 27 a c c c c c c c c 28 a a a c c c c c c 29 a c d d d d a a d a c a c c c a a c X X

183

Vastausten kokonaismäärä per torjuntatekniikka: a 27 6 11 10 9 5 14 12 4 b 0 3 2 0 0 2 1 1 2 c 1 18 10 16 15 14 11 12 18 d 1 2 5 3 4 4 1 2 3 e 0 0 1 0 1 4 2 2 2

184

Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus ID Palvelun oletustekniikat SPF Sender ID DKIM DMARC ARC Palvelun oletustekniikat SPF Sender ID DKIM DMARC ARC 01 a a c a a c a a c a a c 02 a c c c c c a c c c c c 03 a c c c c c a a c a c c 04 a a c a a c a a c a a c 05 a d d d d a a d d d d a 06 a c c a c c a c c a c c 07 a a a a a a a a a a a a 08 a a a a a a a a a a a a 09 a a c c c c a a c c c c 10 d d d d d d d d d d d d 11 d d e d e e d d d d d d 12 a c b c c c a e e e e e 13 a c a c c c a a a b c c 14 a e e e e e a e e e e e 15 a a a a a a a a c a a c 16 a a a a a a a a a a a b 17 a a d d d d a a d d d d 18 a c c a a c a a c a c c 19 a a d b b b a a d b b b 20 a a a a a c a a a a a c 21 a a c a a c a a c a a c 22 a a b a b b a a b a b b 23 a a a b b b a a a b b b 24 a a c c c c a a d d d d 25 a c c c c c a c c c c c 26 a c c c c c a c c c c c 27 a c c c c c a c c c c c 28 a b b b b b a b b b b b 29 a d d d d d a d d d d d a a c a c c a a c a c c X

185

Vastausten kokonaismäärä per torjuntatekniikka: a 27 14 7 11 9 5 27 17 6 12 8 3 b 0 1 3 3 4 4 0 1 2 4 4 5 c 0 9 12 9 10 15 0 5 12 5 9 14 d 2 4 5 5 4 3 2 4 7 6 6 5 e 0 1 2 1 2 2 0 2 2 2 2 2

186

Muut vastaajien käyttämät torjuntamenetelmät Muut torjuntatekniikat, joita vastaajat haluaisivat käyttää ID Vapaamuotoinen vastaus Vapaamuotoinen vastaus 01 02 03 04 05 06 07 Lähettävän palvelimen standardin mukaiseen toimintaan perustuvia mekanismeja- ja tarkistuksia. 08 D-Fence Email Security 09 10 11 12 13 14 Salattu sähköposti * 15 16 17 18 Thunderbirdin sisäinen suodatus * 19 20 F-Secure MSG, Mimecast 21 22 PGP-salaus * 23 F-Secure Server and Email Security 24 25 26 Thunderbirdin roskapostisuodatus (bayesian, oppiva) * 27 28 29

187

Liite 13. Kyselyvastaukset: Pienet yritykset (10-49 henkilöä)

TYYPILLISIN VASTAUS - PIENET YRITYKSET (10-49 HENKILÖÄ) Vastaajien lkm: 34 Vastaajan rooli yrityksessä: Teknologiajohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4.1 b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 3.9 c) kokonaisuudessa 4.0 Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SMTP-liikenteen suodatuksella Mustalistauksella (DNSBL) Sähköpostin sisällönsuodatuk- sella Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla

188

Tunniste Vastaajan rooli yrityksessä Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Olla merkitsemättä aitoja sähköposti- Suodattaa oikeita viestejä roskapos- Tyytyväisyyden ID Toimenkuva roskapostiviestejä tiksi keskiarvo Palvelun nimi / kuvaus 30 IT-manageri 5 5 5 Office 365 (Exchange Online) 31 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) 32 Teknologiajohtaja 5 5 5 Office 365 (Exchange Online) 33 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) 34 Ohjelmistokehittäjä, perustaja 5 5 5 G Suite (Gmail) 35 Teknologiajohtaja 4 3 3.5 Office 365 (Exchange Online) 36 Tietoturvapäällikkö 4 4 4 Office 365 (Exchange Online) 37 Teknologiapäällikkö 4 4 4 Office 365 (Exchange Online) 38 Tietohallintojohtaja 3 4 3.5 Office 365 (Exchange Online) 39 Toimitusjohtaja 3 5 4 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu 40 IT-manageri 4 2 3 Office 365 (Exchange Online) 41 IT-asiantuntija 5 5 5 Office 365 (Exchange Online) 42 Toimitusjohtaja 5 5 5 Muu: D-Fence 43 IT-päällikkö 5 5 5 G Suite (Gmail) 44 IT-päällikkö 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 45 IT-päällikkö 4 4 4 Office 365 (Exchange Online) 46 Järjestelmäarkkitehti 3 5 4 Muu: Oma Exchange, jonka edustapalvelimena Postfix 47 Perustaja, suunnittelija 3 4 3.5 Office 365 (Exchange Online) 48 IT-helpdesk 4 5 4.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 49 Teknologiajohtaja 4 4 4 G Suite (Gmail) 50 Operaatiojohtaja 4 4 4 G Suite (Gmail) 51 Perustaja 2 5 3.5 G Suite (Gmail) 52 Varapresidentti 4 4 4 Office 365 (Exchange Online) Muu: Useita järjestelmiä; mm. Exchange, IceWarp, Postfix, 53 IT-päällikkö 3 3 3 Exim Vanhempi järjestelmäsuunnit- 54 telija 4 4 4 Office 365 (Exchange Online) 55 IT-johtaja 4 4 4 G Suite (Gmail)

189

56 Tekninen arkkitehti 5 5 5 G Suite (Gmail) 57 Tekninen johtaja 5 3 4 Office 365 (Exchange Online) 58 Järjestelmäasiantuntija 4 4 4 G Suite (Gmail) 59 Tietoturvajohtaja 5 5 5 G Suite (Gmail) 60 Toimitusjohtaja 3 3 3 Office 365 (Exchange Online) 61 Palvelinylläpitäjä 4 5 4.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 62 Järjestelmäasiantuntija 4 4 4 Office 365 (Exchange Online) 63 Johtaja 4 4 4 Office 365 (Exchange Online) Keskiarvo tai tyyppivastaus: Teknologiajohtaja 4.0 4.2 4.1 Office 365 (Exchange Online)

Olla merkitsemättä aitoja sähköposti- Suodattaa oikeita viestejä roskapos- Tyytyväisyyden Palvelu roskapostiviestejä tiksi keskiarvo Palvelun osuus vastauksista % Palvelukohtainen Office 365: 4.1 3.9 4.0 18 53 % tyytyväisyys: G Suite: 4.2 4.6 4.4 9 26 % Itse ylläpidetty Linux: 4.0 4.7 4.3 3 9 % Itse ylläpidetty Windows: 3.0 5.0 4.0 1 3 % Muu: 3.7 4.3 4.0 3 9 %

190

Roskapostin torjunta lähteen tai sisällön perusteella ID Pilvipohjainen roskaposti- Palvelun oletus- suodatus eri palveluntarjo- SMTP-liikenteen Mustalistaus Sähköpostin sisällön- Bayesilainen Fyysiset roska- tekniikat ajalta suodatus (DNSBL) Harmaalistaus Nolisting suodatus suodatus postisuodattimet 30 a a d d d d a d d 31 a c a a a c a a c 32 a c a a a a a d c 33 a c a a a a a e c 34 a c c c c c c c c 35 a c d c c c c c c 36 a a c a c a a c a 37 a c c c c c c c c 38 a c c c c c c c c 39 a a a c c e b e c 40 a c d a b d a d c 41 a c a c c c a c c 42 a a e e e e e e e 43 a c a d d d d d c 44 a c c a a a a a a 45 a c c a a c a c c 46 c a a a b c a a c 47 a e e e e e e e e 48 a c a a a c a a c 49 a d d d d d d d d 50 a c c c c c c c c 51 a c c c c c c c c 52 a c e d d d d e e 53 a a a a a b a a b 54 a c d d d d d d d 55 a c a a a b c b c 56 a c d d d d d d d 57 a c c c a c a a c 58 a c c c c c c c c 59 a c a a c c d d c 60 a c d d d d d d d 61 a c a a d d a a c

191

62 a a a a a a a a c 63 a d a a d a a a d a c a a c c a c c

Vastausten kokonaismäärä per torjuntatekniikka: a 33 7 14 15 10 6 16 9 2 b 0 0 0 0 2 2 1 1 1 c 1 24 10 10 11 14 8 10 22 d 0 2 7 7 9 9 7 9 6 e 0 1 3 2 2 3 2 5 3

192

Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus ID Palvelun oletustekniikat SPF Sender ID DKIM DMARC ARC Palvelun oletustekniikat SPF Sender ID DKIM DMARC ARC 30 a d d a d d a d d a d d 31 a a c c c c a a c c c c 32 a a a a a a a a a a a a 33 a a d a b e a a d a b e 34 a c c c c c a c c c c c 35 a c c c c c a c c c c c 36 a a c a a c a a c b b c 37 a a c a c c a a c a c c 38 a d d d d d a a b a b e 39 a b e b b e a a e b b e 40 a d e d e e a d e d e e 41 a a e a b e a a e a b e 42 a e e e e e a e e e e e 43 a c e c c e a c e c c e 44 a a a a d d a a a a b d 45 a a c a c c a a c a c c 46 c a c b b c a a c b b c 47 a e e e e e a e e e e e 48 a a c c a c a a c a c c 49 a d d d d d a d d d d d 50 a c c c c c a d d d d d 51 a c c c c c a c c c c c 52 a a d d d d a a d d d d 53 a a a a a e a a a a a e 54 a a d d d d a a d d d d 55 a a b a a b a a c a c c 56 a d d d d d a d d d d d 57 a a b b e e a a b b e e 58 a c c c c c a a c a c c 59 a a a a a d a a a a a d 60 a d d d d d a d d d d d 61 a a d a e e a a d a e e 62 a a c c a c a a c c c c 63 a d d d d d a d d d d d

193

a a c a d c a a c a c c X

Vastausten kokonaismäärä per torjuntatekniikka: a 33 18 4 12 7 1 34 21 4 14 3 1 b 0 1 2 3 4 1 0 0 2 4 7 0 c 1 6 12 9 9 12 0 4 12 6 11 12 d 0 7 10 8 9 10 0 7 10 8 8 10 e 0 2 6 2 5 10 0 2 6 2 5 11

194

Muut vastaajien käyttämät torjuntamenetelmät Muut torjuntatekniikat, joita vastaajat haluaisivat käyttää ID Vapaamuotoinen vastaus Vapaamuotoinen vastaus 30 31 32 33 34 35 36 37 38 39 40 41 Office 365 Advanced Threat Protection 42 43 44 45 46 47 48 49 50 51 52 53 Joillain palvelimilla käytössä MagicSpam 54 55 56 57 58 59

195

60 61 62 63

196

Liite 14. Kyselyvastaukset: Keskisuuret yritykset (50-249 henkilöä)

TYYPILLISIN VASTAUS - KESKISUURET YRITYKSET (50-249 HENKILÖÄ) Vastaajien lkm: 6 Vastaajan rooli yrityksessä: Teknologiajohtaja Yrityksen käyttämä sähköpostipalvelu: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4.3 b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 4.7 c) kokonaisuudessa 4.5 Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla Pilvipohjaisella roskapostisuodatuksella SMTP-liikenteen suodatuksella Mustalistauksella (DNSBL) Harmaalistauksella Nolisting-tekniikalla Sähköpostin sisällönsuodatuksella Fyysisillä roskapostisuodattimilla Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla Sender ID -tekniikalla DKIM-tekniikalla DMARC-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla Sender ID -tekniikalla DKIM-tekniikalla DMARC-tekniikalla

197

Tunniste Vastaajan rooli yrityksessä Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Olla merkitsemättä ai- Suodattaa oikeita toja sähköpostivies- Tyytyväisyyden ID Toimenkuva roskapostiviestejä tejä roskapostiksi keskiarvo Palvelun nimi / kuvaus 64 Teknologiajohtaja 5 5 5 Office 365 (Exchange Online) 65 Tietohallintojohtaja 5 5 5 Muu: D-Fence 66 IT-manageri 5 5 5 G Suite (Gmail) 67 Sisäisen IT:n yhteyshenkilö 4 5 4.5 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu 68 Tietohallintopäällikkö 4 5 4.5 Office 365 (Exchange Online) 69 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) Keskiarvo tai tyyppivastaus: Teknologiajohtaja 4.5 4.8 4.7 Office 365 (Exchange Online)

Olla merkitsemättä ai- Suodattaa oikeita toja sähköpostivies- Tyytyväisyyden Palvelu roskapostiviestejä tejä roskapostiksi keskiarvo Palvelun osuus vastauksista % Palvelukohtainen Office 365: 4.3 4.7 4.5 3 50 % tyytyväisyys: G Suite: 5.0 5.0 5.0 1 17 % Itse ylläpidetty Linux: 0.0 0.0 0.0 0 0 % Itse ylläpidetty Windows: 4.0 5.0 4.5 1 17 % Muu: 5.0 5.0 5.0 1 17 %

198

Vastausten kokonaismäärä per torjuntatekniikka: a 6 3 3 4 3 2 3 1 2 b 0 0 0 0 0 0 0 0 0 c 0 3 1 1 1 2 1 3 2 d 0 0 1 0 1 1 1 1 1 e 0 0 1 1 1 1 1 1 1

199

Vastausten kokonaismäärä per torjuntatekniikka: a 6 4 2 3 3 0 6 5 3 3 2 1 b 0 0 0 0 0 0 0 0 0 0 1 0 c 0 1 2 2 2 3 0 0 1 1 1 2 d 0 1 1 1 1 1 0 1 2 2 2 2 e 0 0 1 0 0 2 0 0 0 0 0 1

Muut vastaajien käyttämät torjuntamenetelmät Muut torjuntatekniikat, joita vastaajat haluaisivat käyttää ID Vapaamuotoinen vastaus Vapaamuotoinen vastaus 64 Office 365 Advanced Threat Protection 65 66 67 68 Azure Advanced Threat Protection 69

200

Liite 15. Kyselyvastaukset: Suuryritykset (250 henkilöä tai enemmän)

TYYPILLISIN VASTAUS - SUURYRITYKSET (250+ henkilöä) Vastaajien lkm: 5 Vastaajan rooli yrityksessä: Tietohallintojohtaja/-päällikkö Yrityksen käyttämä sähköpostipalvelu: Office 365 tai G Suite Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4.0 # b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 4.5 # c) kokonaisuudessa 4.3 # Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SMTP-liikenteen suodatuksella Mustalistauksella (DNSBL) Harmaalistauksella Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla DMARC-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla DMARC-tekniikalla

# Koska Office 365- ja G Suite -käyttäjiä oli yhtä paljon, tyytyväisyys laskettiin molempien palveluiden tyytyväisyyksien keskiarvosta.

201

Tunniste Vastaajan rooli yrityksessä Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Olla merkitsemättä ai- Suodattaa oikeita toja sähköpostivies- Tyytyväisyyden ID Toimenkuva roskapostiviestejä tejä roskapostiksi keskiarvo Palvelun nimi / kuvaus 70 IT-päällikkö 5 5 5 G Suite (Gmail) 71 Järjestelmäasiantuntija 4 4 4 Office 365 (Exchange Online) 72 ICT-pääsuunnittelija 3 4 3.5 Office 365 (Exchange Online) 73 Tietohallintojohtaja 4 5 4.5 G Suite (Gmail) 74 Tietohallintopäällikkö 4 4 4 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu Keskiarvo tai tyyppivastaus: #PUUTTUU! 4.0 4.4 4.2 G Suite (Gmail) X Tasapeli Office 365- ja G Suite -palveluiden välillä -> Molem- * Tietohallinto-työntekijät tyypillisimpään vastaukseen mat tyypillisimpään vastaukseen

Olla merkitsemättä ai- Suodattaa oikeita toja sähköpostivies- Tyytyväisyyden Palvelu roskapostiviestejä tejä roskapostiksi keskiarvo Palvelun osuus vastauksista % Palvelukohtainen Office 365: 3.5 4.0 3.8 2 40 % tyytyväisyys: G Suite: 4.5 5.0 4.8 2 40 % Itse ylläpidetty Linux: 0.0 0.0 0.0 0 0 % Itse ylläpidetty Windows: 4.0 4.0 4.0 1 20 % Muu: 0.0 0.0 0.0 0 0 %

202

Vastausten kokonaismäärä per torjuntatekniikka: a 5 1 2 2 2 0 1 0 0 b 0 0 0 0 0 1 0 0 0 c 0 4 2 1 2 3 3 3 4 d 0 0 1 2 1 1 1 2 1 e 0 0 0 0 0 0 0 0 0

203

Vastausten kokonaismäärä per torjuntatekniikka: a 5 4 1 2 2 0 5 3 0 2 2 0 b 0 0 0 0 0 0 0 1 1 1 1 1 c 0 0 3 1 1 3 0 0 3 1 1 3 d 0 1 1 2 2 2 0 1 1 1 1 1 e 0 0 0 0 0 0 0 0 0 0 0 0

Muut vastaajien käyttämät torjuntamenetelmät Muut torjuntatekniikat, joita vastaajat haluaisivat käyttää ID Vapaamuotoinen vastaus Vapaamuotoinen vastaus 70 71 72 73 74

204

Liite 16. Kyselyvastaukset: Kaikki yritykset

TYYPILLISIN VASTAUS - KAIKKI YRITYKSET Vastaajien lkm: 74 Vastaajan rooli yrityksessä: Toimitusjohtaja Yrityksen sisäiset sähköpostipalvelut perustuvat: Office 365 (Exchange Online) Tyytyväisyys palvelun kykyyn asteikolla 1-5: a) suodattaa oikeita roskapostiviestejä 4.1 b) olla merkitsemättä aitoja sähköpostiviestejä roskapostiksi 4.1 c) kokonaisuudessa 4.1 Roskapostin torjunta lähteen tai sisällön perusteella toteutettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SMTP-liikenteen suodatuksella Mustalistauksella (DNSBL) Sähköpostin sisällönsuodatuk- sella Viestin aitouden ja lähettäjän todennus saapuvassa liikenteessä varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla Verkkotunnuksien ja lähtevän sähköpostin todennuksen suojaus varmistettiin seuraavilla tekniikoilla: Palvelun oletustekniikoilla SPF-tekniikalla DKIM-tekniikalla

205

Tunniste Vastaajan rooli yrityksessä Tyytyväisyys järjestelmien kykyyn: (1-5) Käytetyt sähköpostipalvelut Olla merkitsemättä aitoja sähköposti- Suodattaa oikeita viestejä roskapos- Tyytyväisyyden ID Toimenkuva roskapostiviestejä tiksi keskiarvo Palvelun nimi / kuvaus 01 Asiantuntija 5 5 5 Office 365 (Exchange Online) 02 Toimitusjohtaja 4 4 4 G Suite (Gmail) 03 Yrittäjä, Toimitusjohtaja 1 2 1.5 Muu: Webhotellin sähköpostipalvelu 04 Yrittäjä 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 05 IT-Päällikkö 3 5 4 Muu: Ulkopuolisen tarjoama sähköpostipalvelin, itse ylläpitämä 06 Toimitusjohtaja 4 4 4 G Suite (Gmail) 07 Presidentti 5 5 5 Muu: D-Fence Email Security 08 IT-asiantuntija, kyberturva 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 09 Tekninen johtaja 5 5 5 G Suite (Gmail) 10 Verkkosivuvastaava 1 4 2.5 Muu: Webhotellin sähköpostipalvelu (Linux-pohjainen) 11 Toimitusjohtaja 1 2 1.5 Muu: Mac Mail / Outlook 12 Operatiivinen johtaja 4 4 4 Office 365 (Exchange Online) 13 Toimitusjohtaja 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 14 Yrittäjä 3 4 3.5 Office 365 (Exchange Online) 15 Toimitusjohtaja 5 5 5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 16 Järjestelmänvalvoja 1 2 1.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 17 Tietohallintojohtaja 4 2 3 G Suite (Gmail) 18 Toimitusjohtaja 5 4 4.5 G Suite (Gmail) 19 IT-päällikkö 4 4 4 Office 365 (Exchange Online) 20 IT-johtaja 5 5 5 Muu: Office 365 Hybrid 21 Vähän kaikkia 4 4 4 G Suite (Gmail) 22 Toimitusjohtaja 5 3 4 G Suite (Gmail) 23 Asiantuntija 5 5 5 Office 365 (Exchange Online) 24 Teknologiajohtaja 4 3 3.5 G Suite (Gmail) 25 Yrittäjä 4 4 4 G Suite (Gmail) 26 Toimitusjohtaja 4 4 4 G Suite (Gmail) 27 Osakkeenomistaja 5 5 5 G Suite (Gmail)

206

28 Toimitusjohtaja 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 29 Palvelutuotantojohtaja 3 4 3.5 Muu: Sigmatic/Nebula IMAP-sähköpostipalvelu 30 IT-manageri 5 5 5 Office 365 (Exchange Online) 31 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) 32 Teknologiajohtaja 5 5 5 Office 365 (Exchange Online) 33 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) 34 Ohjelmistokehittäjä, perustaja 5 5 5 G Suite (Gmail) 35 Teknologiajohtaja 4 3 3.5 Office 365 (Exchange Online) 36 Tietoturvapäällikkö 4 4 4 Office 365 (Exchange Online) 37 Teknologiapäällikkö 4 4 4 Office 365 (Exchange Online) 38 Tietohallintojohtaja 3 4 3.5 Office 365 (Exchange Online) 39 Toimitusjohtaja 3 5 4 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu 40 IT-manageri 4 2 3 Office 365 (Exchange Online) 41 IT-asiantuntija 5 5 5 Office 365 (Exchange Online) 42 Toimitusjohtaja 5 5 5 Muu: D-Fence 43 IT-päällikkö 5 5 5 G Suite (Gmail) 44 IT-päällikkö 4 4 4 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 45 IT-päällikkö 4 4 4 Office 365 (Exchange Online) 46 Järjestelmäarkkitehti 3 5 4 Muu: Oma Exchange, jonka edustapalvelimena Postfix 47 Perustaja, suunnittelija 3 4 3.5 Office 365 (Exchange Online) 48 IT-helpdesk 4 5 4.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 49 Teknologiajohtaja 4 4 4 G Suite (Gmail) 50 Operaatiojohtaja 4 4 4 G Suite (Gmail) 51 Perustaja 2 5 3.5 G Suite (Gmail) 52 Varapresidentti 4 4 4 Office 365 (Exchange Online) 53 IT-päällikkö 3 3 3 Muu: Useita järjestelmiä; mm. Exchange, IceWarp, Postfix, Exim Vanhempi järjestelmäsuunnit- 54 telija 4 4 4 Office 365 (Exchange Online) 55 IT-johtaja 4 4 4 G Suite (Gmail) 56 Tekninen arkkitehti 5 5 5 G Suite (Gmail) 57 Tekninen johtaja 5 3 4 Office 365 (Exchange Online) 58 Järjestelmäasiantuntija 4 4 4 G Suite (Gmail)

207

59 Tietoturvajohtaja 5 5 5 G Suite (Gmail) 60 Toimitusjohtaja 3 3 3 Office 365 (Exchange Online) 61 Palvelinylläpitäjä 4 5 4.5 Itse ylläpitämämme Linux-pohjainen sähköpostipalvelu 62 Järjestelmäasiantuntija 4 4 4 Office 365 (Exchange Online) 63 Johtaja 4 4 4 Office 365 (Exchange Online) 64 Teknologiajohtaja 5 5 5 Office 365 (Exchange Online) 65 Tietohallintojohtaja 5 5 5 Muu: D-Fence 66 IT-manageri 5 5 5 G Suite (Gmail) 67 Sisäisen IT:n yhteyshenkilö 4 5 4.5 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu 68 Tietohallintopäällikkö 4 5 4.5 Office 365 (Exchange Online) 69 Teknologiajohtaja 4 4 4 Office 365 (Exchange Online) 70 IT-päällikkö 5 5 5 G Suite (Gmail) 71 Järjestelmäasiantuntija 4 4 4 Office 365 (Exchange Online) 72 ICT-pääsuunnittelija 3 4 3.5 Office 365 (Exchange Online) 73 Tietohallintojohtaja 4 5 4.5 G Suite (Gmail) 74 Tietohallintopäällikkö 4 4 4 Itse ylläpitämämme Windows-pohjainen sähköpostipalvelu Keskiarvo tai tyyppivastaus: Toimitusjohtaja 4.0 4.2 4.1 Office 365 (Exchange Online)

Olla merkitsemättä aitoja sähköposti- Suodattaa oikeita viestejä roskapos- Tyytyväisyyden Palvelu roskapostiviestejä tiksi keskiarvo Palvelun osuus vastauksista % Palvelukohtainen Office 365: 4.1 4.1 4.1 28 38 % tyytyväisyys: G Suite: 4.3 4.3 4.3 23 31 % Itse ylläpidetty Linux: 4.0 4.3 4.2 9 12 % Itse ylläpidetty Windows: 3.7 4.7 4.2 3 4 % Muu: 3.2 4.1 3.6 11 15 %

208

Roskapostin torjunta lähteen tai sisällön perusteella ID Pilvipohjainen roska- Palvelun oletus- postisuodatus eri palve- SMTP-liikenteen Mustalistaus Sähköpostin sisällön- Bayesilainen Fyysiset roskaposti- tekniikat luntarjoajalta suodatus (DNSBL) Harmaalistaus Nolisting suodatus suodatus suodattimet 01 a c a a a c a a c 02 a c c c c c c c c 03 a b b c c e b b c 04 a c a a a a a a a 05 a d d a d d a d d 06 a c c c c c c c c 07 a a a a a a a a a 08 a c a c c c a a c 09 a c a c c c c c a 10 d d d d d d d d d 11 a c d a e e a a e 12 a c e c c e e e e 13 a a a a a c a a c 14 a c c c c e e e c 15 c c a a a a a a a 16 a b a c a b a a b 17 a a d d d d c c c 18 a c c c c c c c c 19 a a a a a a a a c 20 a c c c c c a c c 21 a c c c c c c c c 22 a c c c c c c c c 23 a a b a a b a c c 24 a b a a a a a a b 25 a c c c c c c c c 26 a c c c c c c a c 27 a c c c c c c c c 28 a a a c c c c c c 29 a c d d d d a a d 30 a a d d d d a d d 31 a c a a a c a a c 32 a c a a a a a d c

209

33 a c a a a a a e c 34 a c c c c c c c c 35 a c d c c c c c c 36 a a c a c a a c a 37 a c c c c c c c c 38 a c c c c c c c c 39 a a a c c e b e c 40 a c d a b d a d c 41 a c a c c c a c c 42 a a e e e e e e e 43 a c a d d d d d c 44 a c c a a a a a a 45 a c c a a c a c c 46 c a a a b c a a c 47 a e e e e e e e e 48 a c a a a c a a c 49 a d d d d d d d d 50 a c c c c c c c c 51 a c c c c c c c c 52 a c e d d d d e e 53 a a a a a b a a b 54 a c d d d d d d d 55 a c a a a b c b c 56 a c d d d d d d d 57 a c c c a c a a c 58 a c c c c c c c c 59 a c a a c c d d c 60 a c d d d d d d d 61 a c a a d d a a c 62 a a a a a a a a c 63 a d a a d a a a d 64 a c a a a a a a c 65 a a e e e e e e e 66 a c c c c c c c c 67 a a d a d d d d d

210

68 a c a a a c a c a 69 a a a a a a a c a 70 a c c c c c c c c 71 a c d d d d d d d 72 a c c a a c c c c 73 a c a a c c c c c 74 a a a d a b a d c a c a a c c a c c

Vastausten kokonaismäärä per torjuntatekniikka: a 71 17 30 31 24 13 34 22 8 b 0 3 2 0 2 5 2 2 3 c 2 49 23 28 29 33 23 28 46 d 1 4 14 12 15 15 10 14 11 e 0 1 5 3 4 8 5 8 6

211

212

35 a c c c c c a c c c c c 36 a a c a a c a a c b b c 37 a a c a c c a a c a c c 38 a d d d d d a a b a b e 39 a b e b b e a a e b b e 40 a d e d e e a d e d e e 41 a a e a b e a a e a b e 42 a e e e e e a e e e e e 43 a c e c c e a c e c c e 44 a a a a d d a a a a b d 45 a a c a c c a a c a c c 46 c a c b b c a a c b b c 47 a e e e e e a e e e e e 48 a a c c a c a a c a c c 49 a d d d d d a d d d d d 50 a c c c c c a d d d d d 51 a c c c c c a c c c c c 52 a a d d d d a a d d d d 53 a a a a a e a a a a a e 54 a a d d d d a a d d d d 55 a a b a a b a a c a c c 56 a d d d d d a d d d d d 57 a a b b e e a a b b e e 58 a c c c c c a a c a c c 59 a a a a a d a a a a a d 60 a d d d d d a d d d d d 61 a a d a e e a a d a e e 62 a a c c a c a a c c c c 63 a d d d d d a d d d d d 64 a a a a a c a a a a a c 65 a a e a a e a a d d d d 66 a c c c c c a a a a a a 67 a d d d d d a d d d d d 68 a a a a a e a a a a b e 69 a a c c c c a a c c c c

213

70 a a c c c c a a c c c c 71 a d d d d d a d d d d d 72 a a c a a c a a c a a c 73 a a c a a c a a c a a c 74 a a a d d d a b b b b b a a c a c c a a c a c c

Vastausten kokonaismäärä per torjuntatekniikka: a 71 40 14 28 21 6 72 46 13 31 15 5 b 0 2 5 6 8 5 0 2 5 9 13 6 c 1 16 29 21 22 33 0 9 28 13 22 31 d 2 13 17 16 16 16 2 13 20 17 17 18 e 0 3 9 3 7 14 0 4 8 4 7 14

214

215

28 29 30 31 32 33 34 35 36 37 38 39 40 41 Office 365 Advanced Threat Protection 42 43 44 45 46 47 48 49 50 51 52 53 Joillain palvelimilla käytössä MagicSpam 54 55 56

216

57 58 59 60 61 62 63 64 Office 365 Advanced Threat Protection 65 66 67 68 Azure Advanced Threat Protection 69 70 71 72 73 74

217