[ Alueelliset vaatimukset ]

Tutki pankkitoimialueen todennusta selkeällä kokonaisuuden ja verkkotunnuksen rajoilla

Tutki pankkien verkkotunnuksia käyttämällä nimenomaisia ​​instituutio-, brändi-, tytäryhtiö- ja sivukonttoreiden kartoituksia käsittelemättä näytesivustoja koko lähettäjäperustana.

EmailAuth -tutkimusryhmä · 8 min lukuaika

[Avainkohdat]

  • Käytä lainkäyttöalueelle sopivaa pankkiväestöä ja säilytä sen rajoitukset.
  • Erillinen institutionaalinen ja verkkotunnuksen painotus, mukaan lukien jaetut tuotemerkit ja haarat.
  • Älä päättele asiakkaan riskiä tai vaatimustenmukaisuutta pelkästään julkisen DNS perusteella.
Tällä sivulla

Määritä pankkikokonaisuus ennen sen toimialueen mittaamista

Pankkitoimialueen tutkimuksessa on erotettava lisensoitu laitos, holdingyhtiö, brändi, sivukonttori ja teknologiapalvelun tarjoaja. Nämä yksiköt voivat jakaa verkkosivuston tai operoida eri verkkotunnuksia, ja niiden suhteet voivat muuttua fuusioiden tai uudelleenbrändäyksen kautta. DNS havainto brändin julkisella verkkosivustolla ei automaattisesti kuvaa koko oikeuslaitoksen sähköpostitilaa. Entiteetti-verkkotunnuskuvaus on siksi osa todisteita, ei alustava hylättävä yksityiskohta.

Tämä käsikirjoitus ehdottaa menetelmää ilman pankkipopulaatioiden keräämistä tai verkkotunnusten skannausta. Se ei väitä todellisen laitoksen turvallisuudesta, vaatimustenmukaisuudesta, vakavaraisuudesta tai asiakasriskistä. Tavoitteena on tuottaa toistettava kartoitus ja teknisesti rajattu tulos pikemminkin kuin moniselitteisistä tuotenimistä rakennettu sarjataulukko.

Käytä valitulle lainkäyttöalueelle sopivaa viranomaista

Yhdysvaltain vakuutettujen pankkien osalta FDIC BankFind API -dokumentaatio erottaa laitostiedot sijainti- tai sivuliikkeen tiedoista. Se on hyödyllinen virallinen lähderakenne, ei maailmanlaajuinen luettelo kaikista pankeista tai rahoituspalveluista. Toisen lainkäyttöalueen kattavan tutkimuksen on säilytettävä asianmukainen viranomainen ja sen kattavuus. Älä sekoita eri sääntelyjoukkoja yhden määrittelemättömän pankkinimittäjän alle.

FDIC-dokumentaatiossa todetaan myös, että laitokset ilmoittavat ensisijaiset Internet-osoitteet ja että linkitetyt sivustot ovat FDIC:n hallinnan ulkopuolella. Sen vastuuvapauslauseke on tärkeä tulkinnan kannalta: lueteltu verkkosivusto on lähteiden tukema kartoitusvihje, ei jokaisen sivun tuki tai kattava luettelo lähettäjän verkkotunnuksista. Säilytä kentän alkuperä ja vahvistuspäivä sen sijaan, että käsittelet verkkosivuston kenttää täydellisenä turvallisuusvahvistuksena.

Rakenna suhdemalli tasaisen nimiluettelon sijaan

Luo erilliset tunnisteet oppilaitokselle, tarvittaessa emoryhmälle, haaralle tai sijainnille ja julkiselle brändille. Linkitä jokainen näyteverkkotunnus tiettyä suhdetta tukevaan entiteettiin ja lähteeseen. Tallenna fuusioiden, uudelleennimettyjen tuotemerkkien ja käytöstä poistettujen verkkotunnusten voimaantulopäivät. Yhdelle riville, joka on merkitty tutulla pankkiryhmällä, voi piiloutua useita lisensoituja tahoja ja erilaisia ​​toiminnallisia vastuita.

Määritä, kuinka jaetut verkkotunnukset painotetaan. Jokaisen haaran laskeminen erilliseksi todennusasennukseksi voi antaa suurelle haaraverkostolle suhteettoman vaikutuksen. Vain emoverkkotunnuksen laskeminen voi jättää pois tytäryhtiöt, joilla on itsenäiset lähetysjärjestelyt. Kumpikaan lähestymistapa ei ole luonnostaan ​​oikea vastaus jokaiseen kysymykseen; tutkimuksessa on valittava yksikkö ja selitettävä sen seuraukset ennen mittarin laskemista.

Erottele näytesivustot lähettäjältä

Laitos voi käyttää erillisiä verkkotunnuksia työntekijöiden postiin, asiakasilmoituksiin, korttipalveluihin, kyselyihin, markkinointiin, rekrytointiin ja ulkoistettuun viestintään. Julkisen verkkosivuston näyte ei yleensä tunnista kaikkia niitä. Älä luo uskottavia aliverkkotunnuksia tai etsi asiakasviestejä täyttääksesi tämän aukon ilman valtuutettua tutkimusaluetta. Kartoituksen tulee kertoa, onko verkkotunnus näytesivusto, riippumattomasti todistettu lähettäjä vai ratkaisematon ehdokas.

RFC 7208 arvioi SPF käyttämällä asianmukaista SMTP identiteettiä. RFC 9989 arvioi DMARC linjaus näkyvälle From-toimialueelle ja määrittää käytännön haun. Nämä säännöt tekevät rajoituksesta konkreettisia: yhdellä verkkoalueella julkaiseminen ei voi vahvistaa toisen toimialueen tai toimittajan ohjaamaa reittiä pitkin lähetettyjen viestien todennusta.

Säilytä hallinnan ja vaikuttavuuden epävarmuus

Rekisteröintitiedot voivat auttaa dokumentoimaan verkkotunnuksen suhteen, mutta niitä ei pidä käsitellä todisteena nykyisestä toiminnan hallinnasta. RFC 9083 määrittää RDAP-objektit, roolit ja tapahtumat; RFC 9537 kuvaa muokkaustiedot, jos niitä on toteutettu. Yksityisyyden suojan tai puutteellisen vastauksen tulisi pysyä näkyvyysrajoituksena, ei väitteenä, että pankki piilottaa omistajuuden.

Samoin jaettu DNS -isäntä tai lähettävä palveluntarjoaja ei vahvista, että laitokset jakavat suojauskäytännön tai järjestelmänvalvojan tilin. Kirjaa havaittu riippuvuus erilleen päätellystä kontrollista. Jos omistajuutta tai lähettäjän määritystä ei voida tukea, merkitse suhde ratkaisemattomaksi ja sulje se pois ilmoitetun säännön perusteella sen sijaan, että väität tutun palvelun nimen perusteella.

Suunnittele DNS mittaus itsenäisesti

Pysäytä yhdistetty verkkotunnusluettelo ja määritä tarkat omistajien nimet, tietuetyypit, ratkaisukonteksti, aikaleimat, uudelleenyritykset ja jäsennysversiot. Erota tarkan nimen haku nykyisestä sovellettavien käytäntöjen löydöstä. Säilytä käsittelemättömät vastaukset ja virheluokat, jotta toinen analyytikko voi toistaa tuloksen. Epäonnistunutta kyselyä ei pitäisi kuvata pankiksi, jolla ei ole todennusta ilman asiaankuuluvia todisteita ja laajuutta.

Pidä arvovaltaiset ja rekursiiviset havainnot erillään keräyspisteistä. Säilytä useita TXT tietueita ja merkkijonot ennen protokollan valintaa. Luokituksen tulee tunnistaa se, mitä havaittiin otosnimessä, ei koko laitoksen hyväksyntää tai epäonnistumista. Tässä työssä ei kerätty DNS kyselyitä, SMTP koettimia tai vastaanotettujen viestien näytteitä.

Vältä kuluttajariskien ja vaatimustenmukaisuuden päätelmiä

DNS julkaisu ei yksinään näytä, paljastettiinko asiakkaiden taloudellisia tietoja, onko tapahtunut petoksia tai onko laitos noudattanut lakisääteistä vaatimusta. Nämä johtopäätökset vaativat erilaisia ​​todisteita ja perusteellisen tarkastelun. Puuttuva tai virheellinen politiikkahavainto voi oikeuttaa tutkimuksen piiriin kuuluvan teknisen havainnon ilman, että siitä tulee väite pankin palveluiden turvallisuudesta.

Älä luokittele laitoksia yksinkertaistetulla todennuspisteellä, elleivät mitta, painotus ja rajoitukset ole avoimia ja perusteltuja. Täytäntöönpanoa vaativa käytäntö ei todista, että jokainen laillinen stream on linjassa tai että kaikki toisena henkilönä esiintyminen on estetty. Tutkimuksessa tulee välttää vihjailemasta, että alhaisempi havaittu asetus ennustaa suoraan asiakkaan taloudellisen tappion.

Entiteetti-toimialue-kartoituslaskentataulukko

Luo sarakkeita lainkäyttöalueelle, auktoriteetin lähteelle, lähdepäivämäärälle, laitoksen tunnisteelle, entiteettityypille, emosuhteelle, brändille, haarasuhteelle ja näyteverkkotunnukselle. Lisää verkkotunnuslinkkien todisteet, voimaantulopäivät, kartoitusvarmuus, verkkotunnuksen rooli, kyselysuunnitelma ja poissulkemiset. Säilytä suhdetaulukko, kun yksi-moneen-vastauksia ei voida esittää todenmukaisesti yhdellä rivillä.

Julkaisupaketin tulee sisältää kartoitus, lähteen alkuperä, normalisoidut kyselyn syötteet, raakahavainnot ja luokittelusäännöt. Arvioijan tulee pystyä seuraamaan julkaistua löytöä takaisin laitokseen ja tarkkaan verkkotunnukseen arvaamatta, mikä tuotemerkki tai tytäryhtiö on tarkoitettu. Arkaluonteiset asiakastiedot, tilitiedot ja yksityiset työntekijätiedot ovat tarpeettomia tälle menetelmälle, eikä niitä saa kerätä sen kaunistamiseksi.

Kuvitteellinen diagnoosi: ryhmän verkkosivustosta tulee jokainen tytäryhtiö

Kuvitteellinen tutkija valitsee pankkiryhmän julkiset verkkosivut ja raportoi jokaisen tytäryhtiön tuloksena noudattamansa politiikan. Kartoituskatsauksessa havaitaan, että lähdeluettelo erottaa useita instituutioita, kun taas verkkotunnuksen todisteet tukevat vain ryhmän verkkosivustoa. Korjausehdotus on julkaista kapeampi verkkosivuhavainto ja merkitä laajempi lähettäjätila mittaamattomaksi.

Ryhmä voisi myöhemmin hankkia valtuutetun tytäryhtiön verkkotunnuksen todisteita ja laajentaa soveltamisalaa tarkistetulla tietojoukon versiolla. Sen ei pitäisi täyttää aukkoja arvatuilla nimillä tai viitata tietoturvavirheeseen, koska kartoitus on epätäydellinen. Tämä skenaario on kuvitteellinen, eikä se sisällä todellista pankki-, verkkotunnus-, skannaus- tai vaatimustenmukaisuusväittämää.

Julkaisun tila

Luettelo edellyttää entiteetti-verkkotunnuskuvauksen julkaisemista ja eron tekemistä näyteverkkotunnuksien ja laajemman lähettäjän välillä. Alkuperäinen kartoitus jää avoimeksi. Ihmisten asiantuntija-arvio, lähteiden soveltuvuus, tuotantoreitit, saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Tämä luonnos tarjoaa pankkikohtaisen tutkimussuunnitelman, ei täytettyä aineistoa tai instituutioita koskevia havaintoja.

[ Takeaway ]

Julkaise entiteetti-toimialue-suhde ja laajuus ennen pankkitoimialueen todennushavainnon tulkintaa.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

Pankkialan tutkija

Tunnista säännelty yhteisö

Brändi tai toimiala ei välttämättä ole sama laskentayksikkö kuin instituutio.

Seuraavat vaiheet

  1. Säilytä viranomaisen tunnisteet.
  2. Seuraa sulautumisen ja nimeämisen päivämäärät.

Domain analyytikko

Sido web-verkkotunnuksen näyte

Ensisijainen verkkosivusto ei ole täydellinen postiluettelo.

Seuraavat vaiheet

  1. Nimeä verkkotunnuksen roolit.
  2. Pidä ratkaisemattomat tekijät näkyvissä.

Toimituksellinen arvioija

Vältä tukemattomia riskivaatimuksia

DNS tulokset eivät osoita taloudellista menetystä tai vaatimustenmukaisuuden epäonnistumista.

Seuraavat vaiheet

  1. Tarkista väitteille arkaluontoinen kielenkäyttö.
  2. Vaadi todisteita laajemmista lähettäjän kiinteistövaatimuksista.

[ UKK ]

Usein kysytyt kysymykset

Kattavatko FDIC-tiedot kaikki pankit maailmanlaajuisesti?

Ei. Sen laitos- ja sijaintitiedot ovat lainkäyttöaluekohtainen esimerkki; muut väestöt tarvitsevat asianmukaisia ​​lähteitä.

FDIC BankFind Suite: API-dokumentaatio

Ovatko FDIC-verkkosivustolinkit täydellinen lähettäjän luettelo?

Ei. Asiakirjoissa sanotaan, että ensisijaiset Internet-osoitteet ovat laitoksen ilmoittamia ja sisältävät rajoituksia linkitettyjen sivustojen vastuulle.

FDIC BankFind Suite: API-dokumentaatio

Voiko jokainen haara laskea itsenäiseksi käyttöönotoksi?

Vain selkeästi haarapainotetussa mallissa; jaetut verkkotunnukset luovat muuten toistuvia teknisiä havaintoja.

Muodostaako emosivusto sivutodennuksen?

Ei. Yhdistyksen on tuettava jokaista vaadittua entiteettiä ja verkkotunnussuhdetta.

Voiko RDAP todistaa nykyisen operatiivisen omistuksen?

Ei itsestään. Roolien, tapahtumien ja editointirajojen on pysyttävä näkyvissä.

RFC 9083 : JSON-vastaukset RDAP:lle

Todistaako puuttuva vakuutus asiakkaan taloudellisen riskin?

Ei. DNS todisteet eivät osoita altistumista, petoksia tai lainmukaisuutta.

Tarkistettiinko pankit tai luokiteltiinko ne paremmuusjärjestykseen?

Ei. Alkuperäistä laitostietoaineistoa tai teknisiä havaintoja ei kerätty.

Mitkä julkaisutodisteet ovat avoinna?

Entiteetti-verkkotunnusten kartoitus ja selkeä ero verkkotunnusten ja laajemman lähettäjän välillä pysyvät avoinna.

[ Lähteet ]

Lähteet

  1. RFC 9989: DMARC

    Osat §4.7 DMARC käytäntötietueen muoto · §4.8 Muodollinen määritelmä · §4.10 DNS Tree Walk · §5.3.2 Määritä, onko DMARC mekanismi käytössä · §4.4 Tunnisteen kohdistus selitetty · A.6 pct-tunnisteen poistaminen

  2. RFC 7208 : Lähettäjäkäytäntökehys

    Osat §2.4 MAIL FROM Identity · §3.2 Useita DNS tietueita · §4.5 Tietueiden valitseminen · §4.6.4 DNS -haun rajat · §5.2 sisältää · §6.1 uudelleenohjaus · §8 Tulosten käsittely

  3. RFC 9083 : JSON-vastaukset RDAP:lle

    Osat §4 Yleiset tietorakenteet · §5.1 Entity Object Class · §5.3 Domain Object Class

  4. RFC 9537 : Redakoidut kentät RDAP-vastauksissa

    Osat §3 Muokkausmenetelmät · §4 Muokattu RDAP-vastaus

  5. FDIC BankFind Suite: API-dokumentaatio

    Osat Yleiskatsaus · API-määrittelytiedostot: Institution and Location API-määritykset · Olet poistumassa FDIC.gov:sta: ensisijaisen Internet-osoitteen vastuuvapauslauseke

[ Sanasto ]

Sanasto

Laitosyksikkö
Valitun viranomaisen tunnistama pankkiyksikkö, joka on erillinen sivukonttorista tai brändistä.

FDIC BankFind Suite: API-dokumentaatio

Ensisijainen verkkosivuston kartoitus
Lähteen tukema linkki julkiselle verkkosivustolle, ei täydellinen lähettäjän kiinteistöväite.

FDIC BankFind Suite: API-dokumentaatio

Lähettäjän kiinteistö
Varsinaisten lähetystyönkulkujen ja identiteettien joukko, jotka edellyttäisivät erillistä valtuutettua näyttöä.
Attribuution epävarmuus
Rajoitus julkisen verkkotunnuksen tai riippuvuuden yhdistämisessä toiminnan ohjaukseen.

RFC 9537 : Redakoidut kentät RDAP-vastauksissa

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