Rakenna tapaus osoitettujen ohjausparannusten ympärille
A DMARC Business case voi selittää näkyvyyden, lähettäjän hallinnan ja suojauksen tietyltä luvattomalta verkkotunnuksen käytöltä ilman, että keksitään kuinka paljon petoksia estettiin. Vahvin tapaus yhdistää havaitun ongelman ehdotettuun ohjausmuutokseen, tunnistaa lailliset lähetystyönkulut, joihin se voi vaikuttaa, ja määrittää, kuinka tulos varmistetaan. Se ei muunna jokaista hylättyä viestiä estetyksi taloudelliseksi tappioksi tai lupaukseksi, jonka todennus eliminoi yrityssähköpostin kompromissi.
RFC 9989 toteaa, että DMARC käsittelee täsmällisen verkkotunnuksen tiettyjä muotoja huijausta, eivät visuaalisesti samankaltaisia verkkotunnuksia, näyttönimihyökkäyksiä tai sisältöanalyysiä. Nämä rajat kuuluvat liiketoimintatapaukseen, eivät vain tekniseen liitteeseen. Tässä artikkelissa ehdotetaan näyttöön perustuvaa suunnittelumenetelmää. Mitään käytäntöä ei muutettu, lähettäjä testattu, tappioarvioita tai taloudellisia sitoumuksia ei tehty.
Kuvaile perusongelmaa sen peittorajoilla
Aloita verkkotunnuksista ja laillisista lähetystyönkuluista, joista organisaatio tietää. Kirjaa ylös mitkä palvelut ovat omistettuja, mitkä ovat ratkaisemattomia ja millä todennuspoluilla on todisteita. Pidä määritetty tarkoitus erillään havaituista vastaanottimen tuloksista. Luettelo SPF ja DKIM tietueet eivät ole todiste siitä, että jokainen työnkulku käyttää niitä oikein, kun taas ohittava näyte ei kata kaikkia posteja ja vastaanottajia.
RFC 9990 määrittää aggregaattiraportoinnin, joka voi antaa havaintoja todennuksesta. Nämä raportit ovat arvokkaita todisteita, mutta niiden lähde ja ajanjakso on ilmoitettava. Puuttuvat raportit eivät todista liikenteen puuttumista. Tuntemattomiin lähettäjiin voi kuulua luvaton toiminta, unohdetut lailliset järjestelmät tai epätäydellinen tulkinta. Luokittele ne todisteilla ennen kuin käytät niiden laskelmia liiketoiminnan perusteluissa.
Erota tavoitteet taloudellisista vaateista
Hyödyllisiä tavoitteita voivat olla omistajien määrittäminen laillisille lähettäjille, ratkaisemattomien todennusvirheiden vähentäminen, tarkistetun käytännön luominen ja muutoksen todentamisen toistettavuuden parantaminen. Jokaisella tulisi olla määritelty mitta, perusjakso ja todisteiden lähde. Tavoite voi olla toiminnallinen tai turvallisuuteen liittyvä ilman rahallista lukua. Liiketoiminnasta ei tule heikkoa vain siksi, että se kieltäytyy valmistamasta estettyjä tappioita.
Jos taloudellinen malli tarvitaan, käytä hyväksyttyjä organisaation syöttöjä ja esitä oletuksia. Henkilöstön aika, tilauskustannukset ja toteutuspanos voivat olla mitattavissa asianmukaisilla tietueilla, mutta niitä ei mitattu tässä. Hylättyjen viestien määrällä kerrottu hypoteettinen menetys ei ole puolustettavissa oleva arvio säästöistä. Viesti ei ehkä koskaan saavuttanut henkilöä, johtanut toimintaan tai aiheuttanut vahinkoa ilman ehdotettua politiikkaa. Kontrafaktuaali tarvitsee todisteita, ei retorista varmuutta.
Rakenna lähettäjäkohtainen valmiusmatriisi
Luo kullekin lailliselle työnkululle rivi liiketoiminnalle, omistajalle, näkyvällä toimialueelta, odotetulla kirjekuorella ja allekirjoitustunnuksella, nykyisellä todisteella, ratkaisemattomilla virheillä ja muutosriippuvuudella. Merkitse aiottu kohdistettu todennuspolku alle RFC 9989. Erota toimittajan väite, että ominaisuus on käytössä, luotettavan vastaanottimen havainnosta todellisesta valtuutetusta näytteestä. Tätä luonnosta varten ei otettu näytteitä.
Matriisin tulee tunnistaa, mitkä työnkulut ovat valmiita ehdotettuun käytäntöön ja mitkä tarvitsevat korjausta tai dokumentoitua poikkeusta. Vältä käsittelemästä suurta yhteenlaskettua läpäisyprosenttia todisteena siitä, että pieni mutta kriittinen työnkulku on turvallinen. Pienikokoinen laskutus- tai palautusprosessi voi olla kaupallisesti tärkeä, vaikka sillä olisi vain vähän vaikutusta nimittäjään. Valmiudessa on siksi otettava huomioon liiketoiminnallinen vaikutus ja kattavuus, ei vain kokonaisprosentti.
Määritä käytännön ero ja valtuutus
Kirjoita ehdotettu muutos täsmällisenä käytäntöerona asianomaiseen verkkotunnukseen, suunniteltuun toimintaan, edellytyksiin ja käyttöönottopäätökseen. Käytännön tulee heijastaa nykyistä standardia ja todellista vastaanottimen soveltuvuutta kopioitujen vanhojen oletusten sijaan. Tunnista, kuka omistaa DNS julkaisun, kuka hyväksyy liiketoimintariskin ja kuka vahvistaa tuloksen. Tekninen suositus ei sinänsä ole valtuutus tuotannon muuttamiseen.
Dokumentoi pysäytys- ja palautuskriteerit ennen suoritusta. Käytännön säätö voi vaikuttaa lailliseen postiin, jos valmiusoletukset ovat vääriä, kun taas DNS arvon palauttaminen ei välttämättä korvaa välimuistissa olevia havaintoja tai kumoa jo käsiteltyä postia. Älä lupaa riskitöntä käyttöönottoa. Säilytä aiempi konfiguraatio ja siihen liittyvät huoltotiedot, jotta valtuutettu käyttäjä voi tehdä perustellun palautuspäätöksen, jos todelliset todisteet sen edellyttävät.
Määrittele muutoksen jälkeiset todisteet oikealla rajalla
Suunnittele kerätäsi arvovaltaisia julkaisutodisteita, luotettavia vastaanotettujen viestien havaintoja edustavia työnkulkuja varten ja koota trendejä sopivan määritellyn ajanjakson aikana. RFC 8601 selittää miksi Authentication-Results todisteiden on tultava luotettavalta vastaanottajalta. Kopioitu passirivi ilman alkuperää ei riitä osoittamaan, että aiottu polku on toiminut muutoksen jälkeen.
Tarkista myös palveluntarjoajan toimitusdiagnostiikka, jos mahdollista, mutta säilytä niiden merkitys. SendGrid tapahtumaviittaus määrittelee toimituksen onnistuneeksi toimitukseksi vastaanottavalle palvelimelle, ei postilaatikon sijoitteluksi tai ihmisen lukemiseksi. Tällaiset todisteet voivat auttaa erottamaan todennusmuutokset muista toimitusongelmista ilman, että se todistaa liiketoiminnan tulosten lisääntyneen. Kirjaa muistiin muut samanaikaiset muutokset, jotka voisivat selittää havaitun trendin.
Yritystapauksen laskentataulukko
Luo osiot havaitulle lähtötilanteelle, kattavuuden rajoituksille, toimintaongelmalle, ehdotetulle käytäntöerolle, lähettäjän valmiudelle, omistajille, hyväksynnöille, odotetuille hyödyille, toteutusponnisteluille, riskeille ja todentamissuunnitelmalle. Pidä mitatut arvot, oletukset ja mittaamattomat tulokset näkyvästi erillään. Sisällytä päätöskenttä ratkaisemattomille kriittisille lähettäjille ja tietty kriteeri jatkamiselle tai keskeyttämiselle. Tehtävätaulukon tulee tehdä epävarmuudesta toimintakykyinen eikä peitellä sitä.
Kysy jokaisen väitetyn edun osalta, mitkä todisteet tukisivat sitä ja mitkä todisteet olisivat sen vastaisia. Parempi lähettäjän omistajuus voidaan osoittaa valmiin inventaarion ja hyväksyntöjen avulla. Parannettu linjaus kattavuus edellyttää vertailukelpoisia havaintoja ja vakaita määritelmiä. Estetty petos tai rahallinen menetys vaatii paljon vahvemman syy-yhteyden, eikä niitä tule päätellä pelkästään protokollien laskelmista. Tämä ehdotettu kehys ei sisällä varsinaista ROI-laskentaa tai valmistettua suorituskykytilastoa.
Kuvitteellinen diagnoosi: houkutteleva estetty-tappioluku
Kuvitteellinen projektiryhmä näkee monia viestejä luvattomaksi katsomassaan raporttiluokassa ja ehdottaa tämän määrän kertomista keskimääräisellä petosmäärällä. Arvioija hylkää laskelman, koska tietojoukko ei määritä, kuinka monta viestiä olisi toimitettu, luettu, uskottu tai toimittu. Se ei myöskään vielä ratkaise, onko jokainen luokan lähde luvaton.
Ehdotettu tarkistus keskittyy todennettavissa oleviin tuloksiin: lähettäjän omistajuuden loppuun saattaminen, laillisten virheiden ratkaiseminen, käytäntömuutoksen hyväksyminen ja muutoksen jälkeisten todisteiden säilyttäminen. Jos organisaatiolla on myöhemmin itsenäisesti tukemia tapaus- ja taloustietoja, pätevä omistaja voi arvioida, onko lisävaatimus perusteltu. Tämä skenaario on kuvitteellinen; raporttien määrää, petosmääriä, estettyjä tappioita tai projektin säästöjä ei havaittu tai laskettu.
Ilmoita, mitä DMARC ei korvaa
The IC3 pilvi-sähköpostin BEC:n neuvonta, julkaistu vuonna 2020, tukee riippumatonta epätavallisten yrityspyyntöjen ja tilin suojausten todentamista. Nämä hallintalaitteet ovat edelleen merkityksellisiä, koska vaarantunut valtuutettu tili voi lähettää todennettua postia ja eri verkkotunnus voi esiintyä yrityksenä epäonnistumatta omassa todennuksensa. DMARC -liiketoimintatapauksessa tulee tunnustaa täydentävät hallintalaitteet sen sijaan, että vaadittaisiin niiden korvaamista.
Luettelo vaatii lähettäjäkohtaisen valmiusmatriisin, käytäntöeron, hyväksyntietueen ja muutoksen jälkeiset tulokset. Ne alkuperäiset esineet pysyvät avoimina. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos tarjoaa todisteiden puitteet ja kuvitteellisen harjoituksen, ei valmistunutta käyttöönottoa tai taloudellista takuuta. Julkaiseminen edellyttää valtuutettua toiminnallista näyttöä ja väitteitä, jotka rajoittuvat siihen, mitä todisteet todella osoittavat.