DMARC-, DKIM-, SPF- en DNSSEC-monitoring laten bouwen
SPF, DKIM en DMARC instellen is een middag werk. Weten wie er namens uw domein verstuurt is dat niet. De rapportages die daar antwoord op geven komen dagelijks binnen als XML van tientallen ontvangende partijen, en zolang niemand ze leest, blijft uw beleid op p=none staan en beschermt het niets.
Waarom p=none de eindstand blijft
De drie e-mailstandaarden werken samen. SPF zegt welke servers namens uw domein mogen versturen, DKIM zet een handtekening onder het bericht, en DMARC bepaalt wat een ontvanger moet doen als een van die twee niet klopt. Daarnaast staat DNSSEC, dat de DNS-antwoorden zelf ondertekent zodat ze onderweg niet kunnen worden vervalst. Ze staan op de lijst van open standaarden waarvoor het principe pas toe of leg uit geldt, en internet.nl toetst er publiek op.
De inrichting is niet het probleem. Het probleem is de stap van p=none naar quarantine en uiteindelijk reject. Zolang u niet weet welke systemen namens u versturen, is die stap een gok: zet u het beleid te vroeg strak, dan verdwijnen facturen, wachtwoordherstelmails of nieuwsbrieven uit een marketingpakket dat niemand op het lijstje had staan.
De enige bron die dat inzichtelijk maakt zijn de DMARC-rapportages. Ontvangende partijen sturen dagelijks een overzicht van wat zij namens uw domein hebben gezien, in XML, per verzendende server. Bij tien domeinen zijn dat honderden bestanden per week. Ze met de hand openen gebeurt twee weken lang, en daarna niet meer. Daarom blijft het beleid op p=none staan. U kunt uw domein publiek laten toetsen op internet.nl.
Hoe wij dit bouwen
De volgorde is: eerst zien, dan aanscherpen. Elk voorstel om het beleid strakker te zetten voordat de verzenders in kaart zijn, is een voorstel om post kwijt te raken.
Niet alleen uw hoofddomein maar ook de domeinen die u ooit heeft geregistreerd en nooit gebruikt. Juist die worden misbruikt, omdat er geen beleid op staat en niemand ernaar kijkt.
Adressen instellen waar de rapportages binnenkomen en die stroom laten lopen, nog zonder iets aan het beleid te veranderen. Na enkele weken heeft u een beeld waarop u kunt beslissen.
Elke sprint eindigt met iets dat u zelf kunt narekenen, en we beginnen bij het verwerken en leesbaar maken van de rapportages. Zonder dat scherm is aanscherpen een gok.
Per domein van p=none naar quarantine en daarna reject, met een percentage dat u opvoert. Bij elke stap ziet u wat er zou zijn afgewezen voordat het echt gebeurt.
Wat de koppeling concreet doet
Het verwerken van rapportages is de kern; de monitoring op DNS-records is wat voorkomt dat het stilletjes weer stukgaat.
Rapportages verwerkt en leesbaar
De dagelijkse XML van ontvangende partijen ingelezen en samengebracht tot één beeld: welke verzender, welk domein, hoeveel berichten, en of SPF en DKIM klopten. Dat is de informatie waarop u een beleidsbeslissing neemt.
Onbekende verzenders eruit gelicht
Een verzendende server die u niet herkent, is een marketingpakket dat een afdeling zelf heeft aangeschaft, of iemand die uw domein misbruikt. Het onderscheid daartussen is precies wat u wilt zien voordat u strakker zet.
Effect van een beleidswijziging vooraf
Wat zou er zijn afgewezen als u nu op reject had gestaan. Die vraag stelt u vóór de wijziging, niet erna, en het antwoord bepaalt of u er klaar voor bent.
Bewaking van uw DNS-records
Een SPF-record dat door een beheerder wordt aangepast en daarmee te lang wordt, of een DKIM-sleutel die verloopt, breekt uw e-mail zonder waarschuwing. Doorlopende controle met een melding op het moment dat het gebeurt.
DNSSEC-status per domein
Of de zone is ondertekend en of de ondertekening geldig blijft. Een verlopen of gebroken ondertekening maakt uw domein voor sommige resolvers onbereikbaar, en dat merkt u pas als klanten bellen.
Historie voor verantwoording
Welk beleid stond wanneer op welk domein, en hoe zag het verkeer er toen uit. Bij een audit of een toets op open standaarden is dat de onderbouwing; bij een incident is het de tijdlijn.
Voor wie wij bouwen
Het aantal domeinen en het aantal afdelingen dat zelf iets aanschaft, bepalen hoe rommelig het is. Vier situaties.
Overheid en publieke organisaties
Hier gelden de open standaarden via het principe pas toe of leg uit, en internet.nl maakt de score publiek. Dat maakt het zichtbaar op een manier die elders ontbreekt. Loopt er ook een bredere beveiligingsbeoordeling mee, zie dan ICT-beveiligingsassessment.
Organisaties met veel domeinen
Merken, campagnes en oude domeinen die nooit zijn opgeheven. De niet-gebruikte domeinen zijn het grootste risico, want daar staat vaak helemaal geen beleid op. Loopt er ook een breder risicoregister mee, zie dan IT-risicomanagement.
Financiële dienstverlening en zorg
Waar phishing namens uw naam directe schade oplevert. Hier is de stap naar reject geen compliancevraag maar een schadebeperkingsvraag, en dus urgenter. Valt u onder de meldplicht van de Cyberbeveiligingswet, dan hoort een incident daar thuis; zie incidentmeldportaal.
Beheerpartijen en agencies
U beheert domeinen voor meerdere klanten en heeft dezelfde monitoring per klant nodig met een harde scheiding ertussen. Standaardpakketten zijn vaak op één organisatie gebouwd.
Technologie en koppelingen
Rapportages komen in wisselende kwaliteit binnen, dus het inlezen moet fouttolerant zijn. En de DNS-controle kijkt vanaf meerdere plekken, want een record dat vanaf uw kantoor klopt kan elders anders worden beantwoord.
Waarom Appfront
Zien komt vóór aanscherpen
Iedereen kan p=reject instellen. De vraag is of u weet wat er dan stopt. Wij bouwen eerst het inzicht en pas daarna de stap.
De verrassing zit bij uw eigen afdelingen
In de praktijk is de onbekende verzender vaker een marketingpakket dan een aanvaller. Beide wilt u zien, en het onderscheid maakt uit voor wat u eraan doet.
Het gaat later stil weer stuk
Een beheerder past een SPF-record aan, een sleutel verloopt, een zone wordt overgezet. Zonder doorlopende bewaking merkt u dat als klanten bellen.
Eerlijk over wat dit niet oplost
DMARC beschermt uw domein tegen misbruik van uw naam. Het beschermt u niet tegen phishing vanaf lijkende domeinen of tegen een gecompromitteerd account. Dat zijn andere maatregelen.
Security en privacy
DMARC-rapportages bevatten meer dan techniek. De aggregaterapportages zijn geaggregeerd en daarmee redelijk onschuldig, maar forensicrapportages kunnen fragmenten van afzonderlijke berichten bevatten, inclusief afzender, ontvanger en onderwerp. Dat zijn persoonsgegevens, en veel ontvangende partijen sturen ze om die reden niet of beperkt. Zet ze alleen aan als u weet waarom, en bewaar ze korter dan de aggregaterapportages.
Daarnaast is dit dossier zelf interessant voor een aanvaller: het beschrijft precies welke systemen namens u versturen, welke domeinen zwak staan en welk beleid nog op p=none staat. Dat is een aanvalskaart. Toegang zetten we daarom krap en per rol, en bij beheerpartijen strikt per klant gescheiden. Verder bewaren we per domein welke beleidswijziging wanneer is doorgevoerd en door wie, want bij een incident is de eerste vraag wat er kort daarvoor is veranderd. Hoe wij zelf met beveiliging omgaan staat in ons informatiebeveiligingsbeleid; meldingen van buitenaf lopen via ons CVD-beleid.
Veelgestelde vragen over DMARC en DNSSEC
SPF geeft aan welke servers namens uw domein mogen versturen. DKIM zet een cryptografische handtekening onder een bericht, zodat de ontvanger kan vaststellen dat het onderweg niet is gewijzigd. DMARC bindt die twee aan uw domeinnaam en zegt wat een ontvanger moet doen als het niet klopt: niets, in quarantaine, of weigeren. Zonder DMARC blijven de eerste twee vrijblijvend.
Omdat niemand de rapportages leest. Dat is geen verwijt: het zijn dagelijkse XML-bestanden van tientallen partijen, en bij meerdere domeinen zijn het er honderden per week. Zonder verwerking weet u niet welke systemen namens u versturen, en dan is aanscherpen het risico dat er post verdwijnt. Het inzicht is de voorwaarde, niet de instelling.
Dat legitieme post wordt geweigerd zonder dat iemand het merkt. Denk aan facturen uit een boekhoudpakket, wachtwoordherstel uit een applicatie, of een nieuwsbrief uit een tool die een afdeling zelf heeft aangeschaft. Wij bouwen daarom een simulatie: u ziet wat er zou zijn afgewezen voordat het echt gebeurt.
Ze staan op de lijst van open standaarden waarvoor voor overheden het principe pas toe of leg uit geldt, en internet.nl toetst er publiek op. Voor andere organisaties zijn ze niet wettelijk verplicht maar wel gangbaar, en ontvangende partijen worden strenger. Of en hoe het voor u geldt, stelt u vast met uw eigen adviseur; wij bouwen de monitoring.
SPF, DKIM en DMARC staan allemaal in DNS. Wie die DNS-antwoorden kan vervalsen, omzeilt ze. DNSSEC ondertekent de antwoorden zodat dat niet kan. Het is dus geen los onderwerp maar de basis eronder. Let wel op: een verlopen of gebroken ondertekening maakt uw domein voor sommige resolvers onbereikbaar, dus bewaking is hier belangrijker dan bij de andere drie.
Dat kan, maar wij adviseren de bewaking en het beheer gescheiden te houden: het systeem dat controleert of iets klopt, is beter niet hetzelfde systeem dat het wijzigt. In de praktijk bouwen wij de monitoring en de simulatie, en blijft het aanpassen van records bij uw eigen beheerder of provider, met een melding uit het systeem als er iets moet.
Ja, en dat is meestal de reden om het te laten bouwen. Elke klant houdt zijn eigen domeinen en rapportages, met daarboven een overzicht van welke klant welk beleid heeft en waar het zwak staat. De scheiding tussen klanten is daarbij een ontwerpeis: dit dossier beschrijft precies waar iemand kwetsbaar is. De koppeling met uw eigen systemen loopt via integraties.
Dat hangt af van het aantal domeinen, of forensicrapportages meemoeten en of er meerdere klanten gescheiden moeten draaien. Het verwerken van de aggregaterapportages met het verzendersoverzicht is doorgaans snel bruikbaar en levert het meeste op; de DNS-bewaking en de simulatie kosten meer. Wij geven een onderbouwde inschatting na de verkenning.
DMARC-monitoring laten bouwen?
Vraag uw beheerder welk DMARC-beleid er op uw hoofddomein staat. Is het antwoord p=none, dan is er nooit iemand door de rapportages gegaan, en dan weet u waar dit project begint. Wij bouwen dit als losse toepassing en als onderdeel van een breder traject maatwerk software.