[ DMARC ja politiikka ]

Kuinka kauan postia tulee tarkkailla ennen DMARC -käytännön muuttamista?

Valitse havaintoikkuna yrityksen lähetysjaksoista, raportoinnin kattavuudesta ja ratkaisemattomista reiteistä. Puhdas viikko ei voi luoda valmiutta jokaiselle toimialueelle.

EmailAuth -tutkimusryhmä · 7 min lukuaika

[Avainkohdat]

  • Käytä liikematkaa ja kriittisen reitin kattavuutta, älä lähtölaskentaa.
  • Erottele havaittu liikenne, kontrolloidut testit ja ratkaisemattomat aukot.
  • Käytä postituslistan ohjeita sen ilmoitettuun verkkotunnuksen laajuuteen.
Tällä sivulla

Hyödyllinen tarkkailujakso päättyy, kun tiimillä on tarpeeksi näyttöä tietyn poliittisen päätöksen tekemiseen. Kalenteri auttaa organisoimaan työn, mutta se ei voi kertoa, onko palkkajärjestelmää, katastrofipalautuspalvelua tai vuosiuudistusprosessia testattu.

Aloita ehdotetusta muutoksesta ja sähköpostista, johon se voi vaikuttaa. Selvitä sitten, mitä nykyiset todisteet kattavat, mitä niistä puuttuu ja kuka korjaa jokaisen aukon. Poliittista päätöstä on helpompi puolustaa, kun se nimeää nämä rajat.

Rakenna kalenteri yrityksestä

Listaa lähetettävät tapahtumat sen sijaan, että valitset vakiopäivien lukumäärän. Haastattele rahoituksen, asiakastuen, HR:n, markkinoinnin ja sovellusten omistajia. Sisällytä epätavalliset reitit: vara-alue, manuaalinen laskutus, delegoitu postilaatikko tai toimittajan hätäilmoitusprosessi.

Tallenna jokaiselle tapahtumalle sen odotettu tiheys, palvelutili, näkyvä toimialueelta, reitti ja omistaja. Käyttää lähettäjän inventaario pitää nämä tiedot liitettynä palveluun selittämättömän lähde-IP:n sijaan.

Sovellus voi olla toiminnallisesti tärkeä, vaikka se lähettää hyvin vähän postia. Volyymin pitäisi vaikuttaa tutkimuksen tärkeysjärjestykseen, mutta se ei saa päättää mitkä palvelut ansaitsevat todentamisen.

Merkitse havaittu, testattu ja tuntematon erikseen

Havaittu raporttirivi ja kontrolloitu viestitesti vastaavat eri kysymyksiin. Under RFC 9990 §3.1 ja RFC 9989 §5.3.8, raportit osoittavat, mitä osallistuvat vastaanottajat ovat tallentaneet raportointijaksojensa aikana. Testillä voidaan tutkia tiettyä palvelua ja sen identiteettejä, vaikka sen tavanomaista liiketapahtumaa ei olisi tapahtunut.

Säilytä kolme todistetta:

  • Tila: Havaittu ja testattu; Merkitys: Nimetyllä reitillä on raporttitodisteet ja edustava vastaanotetun viestin tarkistus; Seuraava vaihe: Säilytä todisteet ja seuraa muutoksia
  • Tila: Testattu, ei vielä havaittu rutiinikäytössä; Merkitys: Hallittu ajo toimi, mutta säännöllinen liiketapahtuma jää odottamatta; Seuraava vaihe: Varmista, että testi edustaa tuota tuotantopolkua
  • Tila: Tuntematon tai ratkaisematon; Merkitys: Omistajuutta, reittiä tai todennusta ei ole määritetty; Seuraava vaihe: Tutki ennen kuin käsittelet palvelun valmiina

Tämä on ehdotettu työmatriisi, ei protokollaraportointimuoto. Se estää testitulosta tulemasta hiljaa todisteeksi jokaisesta tulevasta toimituspolusta.

Käytä kattavuusesimerkkiä, älä lähtölaskentaa

Harkitse tätä kuvitteellista yritystä, joka suunnittelee muutosta laskutusverkkotunnukseensa:

  • Flow: Laskukuitit; Normaali poljinnopeus: päivittäin; Todisteet kymmenen päivän jälkeen: rutiiniraportit ja todennettu vastaanotettu esimerkki
  • Flow: Maksuhäiriöilmoitukset; Normaali poljinnopeus: Tapahtumalähtöinen; Todisteet kymmenen päivän jälkeen: Kontrolloitu testi tuotannon lähetysreitin kautta
  • Flow: Kuukausittaiset tiliotteet; Normaali poljinnopeus: kuukausittain; Todisteet kymmenen päivän jälkeen: Edustajaa ei vielä ole
  • Flow: Palautusalueen viestit; Normaali poljinnopeus: Vain vikasietotilassa; Todisteet kymmenen päivän kuluttua: Kokoonpano tiedossa; vikasietoreitti testaamaton

Kymmenen terveellistä päivää peittävät ensimmäisen virtauksen hyvin. He eivät vastaa kahteen viimeiseen riviin. Kalenterin pidentäminen ilman tutkimussuunnitelmaa voi silti jättää palautusalueen testaamatta.

Tiimi voisi järjestää turvalausetestin ja dokumentoidun palautusharjoituksen ja määrittää sitten, kuvaavatko testit riittävästi puuttuvia tuotantotapahtumia. Jos testi häiritsisi asiakkaita, tallenna rajoitus ja valitse myöhempi päätöskohta. Tuloksena pitäisi olla selkeä kattavuusarvio.

Käytä standardiohjeita oikeaan verkkotunnukseen

RFC 9989 RFC 9989 §5.1.7 selittää, että poljinnopeuden lähettäminen voi vaatia useiden kuukausien raportin kulutuksen ennen kuin sen omistaja on varma todennuksesta. Se neuvoo myös olemaan hylkäämättä verkkotunnuksia, joiden käyttäjät voivat lähettää viestejä Internetin postituslistoille.

Niille verkkotunnuksille, jotka kuitenkin harkitsevat hylkäämistä, Ohjeet RFC 9989 §7.4 suosittelee vähintään kuukautta olematonta, minkä jälkeen yhtä pitkää karanteeniaikaa viestien asettelujen vertailun kanssa. Kyseessä on erityinen yhteentoimivuusohje, ei yleinen kahden kuukauden hyväksymissääntö. Näiden ajanjaksojen täyttäminen ei takaa, että jokainen laillinen reitti on turvallinen.

Hallittu tapahtuma-alue ja työntekijän kirjeenvaihtoalue tarvitsevat erilaisia ​​arviointeja. Valitse käytäntö toimialueen todellista käyttöä varten, mukaan lukien epäsuora toimitus, sen sijaan, että hylkäät jokaisen valvontaprojektin automaattisen kohteen.

Tarkista läpäisyprosentin takana oleva nimittäjä

Korkea läpäisyaste voi hallita yksi terve palvelu. Kysy, mitkä vastaanottajat ovat lähettäneet raportteja, mitkä ajanjaksot ovat edustettuina ja näkyvätkö tärkeitä lähettäjiä.

Aggregaattiraportointi ei ole täydellinen loki kaikista lähetetyistä viesteistä. Vastaanottajan osallistuminen, raportin toimittaminen ja käsittely vaikuttavat käytettävissä olevaan näyttöön. Käyttää koosteraporttiopas erottaa raaka autentikointi, linjaus, vakuutusten käsittely ja puuttuva kattavuus.

Samoin tuntematon lähde ei ole automaattisesti haitallinen. Säilytä epävarmuus, kunnes omistajuus ja sitä tukeva näyttö oikeuttavat johtopäätöksen. Älä paranna valmiusprosenttia yksinkertaisesti merkitsemällä uudelleen selittämättömät viat.

Aseta päätösportti ja tarkistuspäivämäärä

Ennen kuin muutat käytäntöä, vaadi nimetyiltä omistajilta kriittisiä palveluita, edustavia henkilöllisyystodisteita, ratkaistuja seurannaisvikoja ja epäsuorien reittien arviointia. Vahvista raportointipolku ja käytännön palautusmenettely.

Under RFC 9989 §5.3.5, soveltuvan käytännön mukaan arvioitu viesti voi läpäistä DMARC yhden kulkevan kohdistetun todennuspolun kautta. Se ei korvaa laajempia täysimääräisiä osallistumisvaatimuksia RFC 9989 §8, jotka sisältävät tasattuja SPF ja DKIM, raportointi ja politiikan julkaisu. Under RFC 9989 §7.4, verkkotunnukset, joissa käytetään hylkäämistä, eivät saa riippua yksinomaan SPF stä, ja niissä on käytettävä kelvollisia DKIM allekirjoituksia.

Jos todisteet ovat puutteellisia, nimeä puuttuva koe ja aseta päivämäärä sen suorittamiselle. Jos tunnettu rajoitus hyväksytään, määritä vastuullinen päätöksentekijä ja työnkulku, johon se vaikuttaa. "Odota vielä viikko" on hyödyllinen vain silloin, kun viikon odotetaan tuottavan erityisiä todisteita.

Pidä havaintopöytäkirja elossa

Käytännön muutoksen jälkeen tarkkaile päätöksen kannalta merkityksellisiä palveluita ja vastaanottimia, tutki uudet viat ja säilytä määritysaikajana. Uusi toimittaja, avaimen muutos tai yhdyskäytävä voi mitätöidä aiemman oletuksen.

Hyödyllinen havaintojakso on siis sidottu dokumentoituun kysymykseen: olemmeko nähneet ja varmistaneet oikeutetut virrat, joihin tämä muutos voi vaikuttaa, ja ymmärrämmekö jäljellä olevan epävarmuuden? Kun vastaus muuttuu, avaa päätös uudelleen sen sijaan, että luottaisi vanhaan päivämäärään.

Kirjaa päätös, joka voidaan tarkistaa

Merkitse kymmenen päivän ottelun kuukausittaiset tiliotteet ja palautusaluerivit ratkaisemattomiksi. Lisäviikko auttaa vain, jos se tuottaa tietyn tapahtuman tai testin; suunniteltu harjoitus ei ole todiste sen onnistumisesta. Tapaus tukee kattavuuden suunnittelua yleisen odotusajan sijaan. Valvontajaksoa, vikasietoharjoitusta tai viestitestiä ei suoritettu.

[ Takeaway ]

Käytä liikematkaa ja kriittisen reitin kattavuutta, älä lähtölaskentaa. Erottele havaittu liikenne, kontrolloidut testit ja ratkaisemattomat aukot. Käytä postituslistan ohjeita sen ilmoitettuun verkkotunnuksen laajuuteen.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Ylläpidä palvelukohtaista kattavuusmatriisia.

Erottele havaittu tuotantoliikenne, kontrolloidut testit ja ratkaisemattomat oletukset.

Seuraavat vaiheet

  1. Säilytä raportointijaksot ja edustavat vastaanotettujen viestien todisteet.
  2. Sisällytä testisuunnitelmaan vähäiset ja epäsuorat reitit.
  3. Tarkista raporttien kerääminen ennen hiljaisuuden tulkitsemista.

CISO / SecOps

Hyväksy näyttöön perustuva poliittinen päätös.

Valmiusportin tulee kuvata toimialueen tarkoitus, testatut reitit ja jäljellä olevat yhteentoimivuusrajat.

Seuraavat vaiheet

  1. Käytä RFC 9989 :n toimialuekohtaisia ​​yhteentoimivuusohjeita.
  2. Kirjaa ylös hyväksytyt rajoitukset ja vastuulliset päätökset.
  3. Uudelleenarviointi lähetyspalveluihin tehtyjen olennaisten muutosten jälkeen.

Perustaja / ei-tekninen

Osta epävarmuus kriittisistä virroista.

Pidempi kalenteri on arvokas, kun se tallentaa yritystapahtuman tai sulkee tunnetun aukon.

Seuraavat vaiheet

  1. Vaadi laskutus-, palkanlaskenta- ja palautusvirrat kattavuussuunnitelmassa.
  2. Kysy, mitä seuraavan tarkkailuviikon odotetaan tuovan esiin.
  3. Määritä ratkaisemattomille yrityspalveluille omistajat.

[ UKK ]

Usein kysytyt kysymykset

Riittääkö seitsemän tai kolmekymmentä päivää aina DMARC tarkkailuun?

Ei. Yhdistä ikkuna lähetysjaksojen, kriittisten reittien, raportoinnin kattavuuden ja sovellettavien yhteentoimivuusohjeiden mukaan. Pelkästään kulunut aika ei pysty vahvistamaan valmiutta.

RFC 9989 §5.1.7 RFC 9989 §7.4

Määrääkö RFC 9989 kuukauden ilman mitään ja kuukauden karanteenia jokaiselle verkkotunnukselle?

Ei. Kohdassa 7.4 annetaan vertailuohjeet verkkotunnuksille, joiden käyttäjät saattavat lähettää viestejä postituslistoille ja jotka kuitenkin harkitsevat hylkäämistä. Se ei ole yleinen valmiustodistus.

RFC 9989 §7.4

Miten arvioimme neljännesvuosittaisen hakemuksen ennen sen seuraavaa suunniteltua ajoa?

Järjestä tarvittaessa kontrolloitu edustava testi, kirjaa, mitä tuotantopolkua se käyttää, ja säilytä aukko, kunnes sen kattavuus on perusteltua. Vältä käsittelemästä asetusten kuvakaappausta hiljaa toimitustestinä.

Voiko yksi terve suuren volyymin lähettäjä piilottaa kriittisen epäonnistumisen?

Kyllä. Pieni epäonnistunut palvelu voi kadota verkkotunnuksen laajuiseen prosenttiosuuteen. Tarkista kriittiset virrat erikseen ja pidä niiden omistajat ja todisteet näkyvissä.

Sisältävätkö koontiraportit kaikki organisaatiomme lähettämät sähköpostit?

Ei. Ne kuvastavat osallistuvien vastaanottajien havaintoja ja onnistuneesti kerättyjä raportteja. Kuvaile kattavuutta sen sijaan, että käsittelet kokoelmaa yleisenä lähteenä lokina.

RFC 9990 §3.1 RFC 9989 §5.3.8

Muodostaako yksi linjattu ohituspolku täyden DMARC osallistumisen?

Se voi täyttää viestitason hyväksymisehdon. Täyteen osallistumiseen liittyy lisävaatimuksia, kuten yhdenmukaistettu SPF ja DKIM , raportointi ja käytäntöjen julkaiseminen.

RFC 9989 §5.3.5 RFC 9989 §8

Mitä meidän tulee tehdä, kun suunniteltu havaintojakso päättyy ratkaisemattomiin virtoihin?

Nimeä puuttuvat todisteet, määritä omistaja ja päätä, viivytetäänkö, muutetaanko ehdotettua laajuutta vai hyväksytäänkö dokumentoitu rajoitus. Itse päivämäärä ei sulje löytöä.

Pitäisikö tarkkailu lopettaa politiikan muutoksen jälkeen?

Ei. Ylläpidä keräämistä ja palvelutason tarkistusta. Uudet reitit, DNS muokkaukset, avaimet ja sovellustilit voivat muuttaa aiemman päätöksen taustalla olevia todisteita.

[ Lähteet ]

Lähteet

  1. RFC 9989

    Osat §5.1.7 · §5.3.5 · §5.3.8 · §7.4 · §8 · §3.2.2

  2. RFC 9990

    Osat §3.1

[ Sanasto ]

Sanasto

Tekijän verkkotunnus
Viestin otsikkokentässä oleva toimialue, jota käytetään DMARC -viiteidentiteettinä.

RFC 9989 §3.2.2

Täysi DMARC osallistuminen
Verkkotunnuksen omistajien vaatimuksiin kuuluvat yhdenmukaistettu SPF ja DKIM , raporttien kerääminen ja analysointi sekä käytäntöjen julkaiseminen yhden viestin hyväksymisehdon lisäksi.

RFC 9989 §8

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta