Saapuva viesti voi läpäistä verkkotunnuksen todennuksen ja silti pyytää vastaanottajaa tekemään jotain vaarallista. Se voi myös epäonnistua todennus, koska laillinen reitti katkesi. Käsittele todennusta viestin yhtenä mitattuna ominaisuutena ja käytä sitten vastaanottavan järjestelmän muita ohjausobjekteja ja organisaation liiketoiminnan vahvistusprosessia. Näiden vaiheiden romahtaminen tuottaa sekä väärää varmuutta että tarpeettomia häiriöitä.
Tunnista kolme päätöstä
Ensimmäinen päätös on tekninen: osuiko todennettu tunniste soveltuvan tekijän verkkotunnuksen kanssa DMARC säännöt? Toinen on toimiva: miten tämän vastaanottavan ympäristön tulisi käsitellä viestiä ottaen huomioon käytännöt ja muut signaalit? Kolmas on yrityskohtainen: onko pyydetty toimenpide laillinen ja valtuutettu? RFC 9989 määrittää toimialuepohjaisen todennuksen ja käytännön; se ei muuta ohimenevää viestiä hyväksynnäksi laskun maksamiseen. DMARC -spesifikaatio.
Kirjaa nämä päätökset erillisiin kenttiin. Laskun muutospyynnössä todennuskenttä voi olla läpäissyt, käsittelykentän karanteeni odottaa tarkistusta ja liiketoimintakenttää vahvistamaton. Nämä arvot ovat yhteensopivia. Vastaanottaja voi käyttää DMARC ulkopuolisia signaaleja, ja työntekijän tulee noudattaa riippumatonta hyväksyntätyönkulkua, vaikka posti on todennettu.
Käytä tuloksia luotetusta rajasta
An Authentication-Results -otsikko on hyödyllinen vain, kun sen alkuperä ymmärretään. Hyökkääjät voivat lisätä viestiin otsikkotekstiä. Vastaanottavan organisaation on erotettava luotetun todennuspalvelun tuottamat tulokset epäluotetuista väitteistä. RFC 8601 kuvaa tämän luottamuksen rajan. Todennuksen tulokset.
Säilytä raakaviesti ja luotettavan vastaanottavan järjestelmän lokit. Vertaa näkyvää Lähettäjä-verkkotunnusta jokaiseen vahvistettuun verkkotunnukseen DKIM allekirjoitusverkkotunnus ja SPF identiteetti todella arvioitu. Vältä käsittelemästä näyttönimeä, vastauskenttää tai edelleenlähetettyä kuvakaappausta todennettuna tekijän verkkotunnuksena. Jos viesti välitettiin, tallenna alkuperäinen arviointipiste ja myöhemmät muunnokset ennen kuin päätät, mitä todisteita sovelletaan.
Vertaa kolmea synteettistä pyyntöä
Harkitse kolmea hypoteettista maksunmuutosviestiä. Ensimmäinen väittää brand.testin, mutta sillä on vain ohimenevä evil.test-allekirjoitus eikä SPF hyväksyntää; oletettu ainoa todennettu tunniste epäonnistuu tiukasti linjaus. Toinen käyttää brand-pay.testiä sekä From- että sen läpäisevässä DKIM identiteetissä, joten sen mallinnettu todennus menee läpi samankaltaisesta huolenaiheesta huolimatta. Kolmas käyttää brand.testiä johdonmukaisesti ja myös läpäisee, jolloin tilin väärinkäyttö tai luvaton pyyntö on mahdollista.
Ehdotettu liiketoimi kussakin tapauksessa on: pidä muutos ja vahvista se itsenäisesti. Nämä ovat keksittyjä todennussyötteitä, eivät salaus- tai vastaanotintuloksia. Kirjoitetuissa tapauksissa oletetaan, että ilmoitetut identiteetit ovat ainoita saatavilla olevia todennettuja tunnisteita, ne eristävät tiukan tarkan toimialueen vastaavuuden eivätkä toteuta täyttä DMARC etsintää. Viestiä, allekirjoitusta tai vastaanottajan testiä ei suoritettu. Se osoittaa, miksi liiketoimintoa ei voida laskea pelkän todennusloogisen arvon perusteella.
Suunnittelun käsittely ilman tarkistusta
Valitse valtuutetut testiviestit kullekin ohjauspolulle ja kirjaa ylös, hylkäsikö, karanteeniin, toimittiko vai korjasiko järjestelmä ne myöhemmin. Toimittajan ominaisuustunniste ei ole osoitus määrittämästäsi toiminnasta. Sisällytä poikkeuksia ja salli säännöt testissä, koska ne voivat muuttaa tehokasta tulosta. Vältä laajaa sallittujen luetteloa vain saadaksesi rikkinäisen laillisen reitin kulkemaan läpi.
Käytä rahoituspyyntöjä varten aiemmin luotua yhteydenottokanavaa. FBI suosittelee maksupyyntöjen ja tilitietojen muutosten tarkistamista itsenäisesti. Älä käytä epäilyttävän viestin antamia yhteystietoja itsenäisenä kanavana. FBI:n yrityssähköpostin kompromissiohjeet.
Lopeta tarkistus kaikilla kolmella päätöksellä, todisteilla jokaisesta ja kaikista ratkaisemattomista asioista. Tämän ansiosta postitiimi voi korjata todennuksen, kun taas talous säilyttää maksun lykkäyksen, tai turvallisuus voi tutkia ohimenevän mutta epäilyttävän viestin väittämättä, että DMARC on viallinen.
Lähde ja toteutusraja
RFC 9989 kohdat 4.4, 5.3.5 ja 5.4 erottaa todennus, kohdistus ja käsittely; passi ei tue viestin sisältöä. Tässä esitetyt operatiiviset päätökset ovat laajoja suosituksia ja eksplisiittisesti hypoteettisia esimerkkejä, eivät uusia asiakkaan, palveluntarjoajan tai historiallisen laitteiston testejä. Jokainen todellinen muutos vaatii oman valtuutetun laajuutensa, säilytetyt todisteet ja vastuullisen päätöksen.