[ Raportit ja tutkinta ]

Priorisoi lähettäjän ongelmat liiketoimintavaikutusten ja todisteiden perusteella

Rakenna triage-jono, joka erottaa liiketoimintakriittiset epäonnistumiset, vahvistamattomat lähteet ja puutteelliset todisteet sen sijaan, että luokittelee pelkän vikamäärän mukaan.

EmailAuth -tutkimusryhmä · 3 min lukuaika

[Avainkohdat]

  • Pidä valtuutus, tekninen vika ja liiketoiminnalliset seuraukset erillään.
  • Kiireellisyys ei muuta epävarmaa diagnoosia tosiasiaksi.
  • Suorita palautus, väärinkäyttöanalyysi ja attribuutio erillisenä omistamana työnä.
Tällä sivulla

Raportissa, joka sisältää 50 000 tuntematonta vikaa ja viisi epäonnistunutta laskua, on kaksi erilaista ongelmaa. Volyymillä on väliä, mutta se ei kerro, mitkä viestit on valtuutettu tai mikä vika eniten vaikuttaa liiketoimintaan. Tehokas lähettäjäjono yhdistää havaitut todennustodistukset vahvistetun yrityksen omistajan ja nimenomaisen vaikutustenarvioinnin kanssa.

Tässä oppaassa ehdotetaan operatiivista triagemenetelmää. Prioriteettitunnisteet ovat suosituksia, eivät määrittämiä arvoja DMARC eikä väite, että kojelauta voi päätellä tuloja tai valtuutuksia IP-osoitteen perusteella.

Pidä kolme kysymystä erillään

Viitteet: RFC 9989 §5.3.5, RFC 9989 §5.4.

Ensinnäkin, onko suoratoisto sallittu? Toiseksi, mikä todennus tai linjaus todisteet tukevat ongelmaa? Kolmanneksi, mitä seurauksia sillä on lailliseen työnkulkuun? Tallenna tuntemattomat vastaukset sen sijaan, että täytä ne oletuksilla.

Tuttu palveluntarjoajan nimi määrittää infrastruktuurikontekstin, ei tilin omistajuutta. Suuri vikojen määrä muodostaa raportoidut havainnot, ei välttämättä toimitusmenetystä. Läpäisevä DMARC tulos muodostaa tasaisen todennuspolun, ei sitä, että viesti olisi haluttu tai vaaraton.

Luo kompakti todistekortti

Viitteet: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.10, RFC 9990 §3.1.1.11.

Kirjaa jokaiselle numerolle tekijän verkkotunnus, lähderyhmä, arvioidut identiteetit, vastaanottajan kattavuus, aikaväli ja viestien määrä. Lisää ehdokassovellus, vahvistettu omistaja, tukiloki tai valvottu viesti, nykyinen käytäntö ja raportoitu sijoitus. Huomaa tietojen laatuongelmat ja tietosuojarajoitukset.

Pidä luottamus erillään kiireellisyydestä. Kriittiseen palveluun vaikuttava selittämätön muutos saattaa ansaita kiireellisen tutkimuksen jo ennen kuin sen syy on varmistunut. Kiireellisyys on syy hankkia todisteita nopeasti, ei lupa väittää, että vahvistamaton selitys on totta.

Käytä jonoa, jossa on selkeät seuraavat toiminnot

Aseta vahvistettu häiriö välttämättömään valtuutettuun sähköpostiin palautusjonon yläosaan. Seuraavaksi tutki tärkeitä reittejä koskevia uskottavia riskejä puutteellisilla todisteilla. Seuraa vahvistettua luvatonta liikennettä väärinkäyttötyössä ja pidä omistamattomat lähteet attribuutiojonossa. Nämä virrat voivat toimia rinnakkain sen sijaan, että kaikki työ pakotettaisiin yhteen virheiden lukumäärän luokitukseen.

Nimeä jokaisen kohteen seuraava toiminto ja omistaja. Esimerkkejä ovat valvotun laskunäytteen hankkiminen, sovelluksen lähetystilin vahvistaminen, a. vertailu DKIM valitsin käyttöönottotietueen kanssa tai tarkistamalla, onko raportoitu lähde jaettu infrastruktuuri. Vältä epämääräisiä kohteita, kuten DMARC pisteiden parantamista.

Vertaa kahta kuvaavaa asiaa

Synteettisessä ongelmassa A on viisi epäonnistunutta laskuviestiä, vahvistettu sovelluksen omistaja, äskettäinen reitin muutos ja asiakasraportit puuttuvista laskuista. Ongelma B sisältää 50 000 vikaa tuntemattomista lähteistä ilman todisteita siitä, että ne ovat valtuutettuja. Tutki A välittömästi toipumisen varalta, mutta säilytä B väärinkäytön analysointia ja kontrollin todentamista varten.

Älä ratkaise B:tä lisäämällä sen IP-osoitteet SPF. Älä myöskään hylkää sitä: äänenvoimakkuus voi olla merkki asiaankuuluvasta hyökkäyksestä tai raportointitaakasta. Jos A:n asiakasvalituksia ei voida sitoa raportoituun aikaväliin, säilytä tämä suhde alustavana, kunnes viesti tai hakemus tukevat sitä. Tämä esimerkki on päätösharjoitus, ei havaittu tapahtuma.

Määritä, mikä sulkee kunkin ongelmaluokan

Laillisen lähettäjän ongelma sulkeutuu, kun aiottu kokoonpano on vahvistettu, edustajaposti näyttää vaaditun tasatun passin ja yrityksen omistaja vahvistaa työnkulun palautumisen. Raporttiin perustuvassa seurannassa tulisi käyttää vertailukelpoisia ikkunoita ja tunnustaa osallistuvien vastaanottajien rajat.

Tuntemattomasta lähteestä peräisin oleva kohde sulkeutuu eri tavalla: siitä voi tulla valtuutetun lähettäjän ongelma, tuettu luvaton luokitus tai dokumentoitu ratkaisematon havainto, jossa on tarkistuskäynnistin. Kirjaa luokitustodisteet muistiin äläkä väitä, että ne viittaavat muuhun kuin se tukee.

Tarkista toistuvista jonomerkinnöistä puuttuva omistajuus, heikko käyttöönotto tai hallitsematon delegoitu DNS . Pitkän aikavälin parannus on pienempi kuilu liiketoiminnallisen tarkoituksen ja todennustodistusten välillä, ei vain vähemmän punaisia ​​rivejä raportissa.

Sitoudu johtopäätökseen ja seuraavaan toimintaan

Synteettiselle ongelmalle A seuraava toimenpide on korreloida viisi laskun virhettä reitin muutokseen ja asiakastodisteisiin. Säilytä B:lle 50 000 havaintoa attribuutio-/väärinkäyttöanalyysissä ilman lähetyslupaa. Älä muunna suhteellisia lukuja automaattisiksi vakavuuspisteiksi tai vahvistetuiksi hyökkäysten määräksi.

[ Takeaway ]

Pidä valtuutus, tekninen vika ja liiketoiminnalliset seuraukset erillään. Kiireellisyys ei muuta epävarmaa diagnoosia tosiasiaksi. Suorita palautus, väärinkäyttöanalyysi ja attribuutio erillisenä omistamana työnä.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

IT / Mail Admin

Pidä todisteiden johtama jono

Todennustulokset, attribuutio ja prioriteetti vastaavat erilaisiin kysymyksiin.

Seuraavat vaiheet

  1. Ennätysväli ja kattavuus.
  2. Vahvista tilin omistajuus.
  3. Käytä reittikohtaisia ​​sulkutestejä.

CISO / SecOps

Säilytä epävarmuus rehellisesti

Triage-tunnisteet eivät saa muuttaa oletuksia luottamusmyönneiksi.

Seuraavat vaiheet

  1. Erottele kiireellisyys luottamuksesta.
  2. Tarkista luvaton liikenne itsenäisesti.
  3. Tarkastuspoikkeukset ja toistuvat puutteet.

Perustaja / ei-tekninen

Valitse seurauksen mukaan

Pieni kriittinen työnkulku voi ansaita huomiota ennen suurta tuntematonta virtaa.

Seuraavat vaiheet

  1. Nimeä yritysten omistajat.
  2. Kuvaile todellista asiakasvaikutusta.
  3. Edellyttää konkreettista seuraavaa toimenpidettä.

[ UKK ]

Usein kysytyt kysymykset

Pitäisikö virheiden määrän määrittää prioriteetti?

Käytä sitä vahvistetun valtuutuksen, liiketoimintavaikutusten, kiireellisyyden ja todisteiden luottamuksen rinnalla.

Voiko palveluntarjoajan nimi muodostaa valtuutuksen?

Ei. Vahvista todellinen tili, sovellus ja yrityksen omistaja.

Mitä todistekortin tulee sisältää?

Sisällytä aikaväli, määrät, identiteetit, vastaanottajan kattavuus, omistaja, vaikutus, todisteet ja konkreettinen seuraava toimenpide.

Voiko epävarma asia olla vielä kiireellinen?

Kyllä. Kiireellisyys voi oikeuttaa nopean tutkinnan, vaikka syytä jää nimenomaisesti vahvistamatta.

Minne tuntemattomien lähteiden pitäisi mennä?

Pidä ne attribuutiojonossa tietyn tutkinnan omistajan kanssa, ei automaattisesti laillisen lähettäjän luettelossa.

Osoittaako DMARC passi turvallisen sisällön?

Ei. Se määrittää asiaankuuluvan kohdistetun todennustuloksen, ei viestin tarkoitusta tai toivottavuutta.

RFC 9989 §5.4

Milloin laillisen lähettäjän ongelma on suljettu?

Kun määritykset ja edustajan todennustodistus ovat samaa mieltä ja asianomaisen liiketoiminnan työnkulku on vahvistettu.

Miten suuria luvattomia virtoja tulisi käsitellä?

Tutki väärinkäyttöä ja hallitse kattavuutta erillään laillisten lähettäjien korjaamisesta ilman, että annat näiden lähteiden valtuutuksen DNS ssä.

[ Lähteet ]

Lähteet

  1. RFC 9989

    Osat §5.3.5 · §5.4

  2. RFC 9990

    Osat §3.1.1.10 · §3.1.1.11 · §3.1.1.8 · §3.1.1.9

[ Sanasto ]

Sanasto

Todisteiden luottamus
Kuinka vahvasti saatavilla olevat tosiasiat tukevat tiettyä ominaisuutta tai diagnoosia? se eroaa operatiivisesta kiireellisyydestä.
Tasattu passi
Onnistunut todennettu polku, joka täyttää tekijän verkkotunnuksen suhteen sovellettavien DMARC sääntöjen mukaisesti.

RFC 9989 §5.3.5

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