Enhancing Email Security: Stop Sender Fraud with SPF, DKIM, and DMARC

Er is geen ontkomen aan: u moet de e-mail van uw bedrijf beschermen.

In 2013 werden dagelijks meer dan 100 miljard zakelijke e-mails verzonden en ontvangen. Slechts een op de vijf van alle in 2013 verzonden e-mails was legitiem, en 92% van alle illegale e-mails bevatte links naar potentieel schadelijke inhoud.

Er zijn echter tekenen van verbetering; deze maand is de eerste in de afgelopen 12 jaar waarin minder dan de helft van de e-mails van Symantec’s klanten spam was.

U kunt drie e-mailbeveiligingsstandaarden (en andere initiatieven) bedanken voor de vermindering van spam: SPF, DKIM, en DMARC. Beveiligingsrisico’s blijven echter bestaan. Onlangs kreeg ik een verhaal te horen over een CFO die het slachtoffer was geworden van een phishing-poging. De poging mislukte, maar als hij geslaagd was, zou hij de organisatie 50.000 dollar hebben gekost.

Over deze e-mailstandaarden bestaat nog veel verwarring. Ik hoop dat ik wat duidelijkheid kan verschaffen met deze post, en u door te lopen hoe SPF, DKIM, en DMARC te implementeren.

Sender Policy Framework (RFC 4408)

Sender Policy Framework, of SPF, is de oude man op de e-mail authenticatie partij. SPF is een open standaard die een methode specificeert om vervalsing van afzenderadressen te voorkomen, volgens openspf.org. Het gaat niet om het tegenhouden van spam; het gaat om het controleren en tegenhouden van pogingen tot vervalsing van afzenderadressen.

SPF stelt u in staat om de legitieme e-mailbronnen van uw domein te identificeren en voorkomt dat niet-geautoriseerde bronnen duizenden of zelfs miljoenen illegale e-mails vanaf uw domein verzenden.

Er zijn vier typen e-mailmisbruik die gewoonlijk in verband worden gebracht met e-mailafzendervervalsing:

• Spam (ongevraagde bulkmail &ongevraagde commerciële e-mail)
• Fraudeurs (419 scams)
• Malware (adware, zero days, virussen, trojaanse paarden, enzovoort)
• Malware (adware, zero days, virussen, trojaanse paarden, enzovoort)
• Phishers (spear-phishing)

U wilt om voor de hand liggende redenen niet dat het domein van uw organisatie met een van deze zaken wordt geassocieerd. SPF zal helpen om ervoor te zorgen dat de e-mails van uw organisatie daadwerkelijk van u afkomstig zijn.

DomainKeys Identified Mail (RFC 6376, vervangt RFC 4871 en RFC 5672 die nu verouderd zijn)

DKIM, of DomainKeys Identified Mail, is een TXT-record dat in uw Domain Name System (DNS) wordt gepubliceerd. Het gaat om iets waar alle IT-beheerders van moeten leren houden: sleutels – publieke sleutels om specifiek te zijn.

Voordat we in DKIM duiken, is het belangrijk dat we begrijpen wat sleutels zijn en hoe ze werken. Sleutels, in dit geval public-key cryptografie, bestaan uit een publieke (bij iedereen bekend) en een private (vaak geheime sleutels genoemd) sleutel. Openbare en particuliere sleutels zijn wiskundig met elkaar verbonden, waardoor veilige communicatie over openbare kanalen mogelijk wordt.

Deze sleutels zijn als een verzegeling op een doorzichtige enveloppe. Je verbergt niet noodzakelijkerwijs het bericht; je verifieert alleen met 100% zekerheid zowel de afzender als het bericht.

Nou, terug naar DKIM.

“Technisch gezien biedt DKIM een methode voor het valideren van een domeinnaamidentiteit die is gekoppeld aan een bericht door middel van cryptografische authenticatie,” aldus dkim.org. Met andere woorden, DKIM gebruikt sleutels om er zeker van te zijn dat een e-mail afzender is wie hij zegt dat hij is.

Met DKIM worden publieke en private sleutelparen gegenereerd om mailservers en communicatie geauthenticeerd te houden. Elke uitgaande SMTP-server (Simple Mail Transfer Protocol) heeft de juiste privésleutel en prefix nodig om overeen te komen met een openbaar DNS-record dat de ontvangende mailserver vervolgens verifieert.

Heeft u zich ooit afgevraagd waarom het slotpictogram in Gmail verschijnt wanneer u berichten ontvangt van eBay, Paypal of uw bank? Dat komt door DKIM en een beetje DMARC (waar we het zo meteen over zullen hebben). Hieronder ziet u bij mailed-by de SPF match en bij signed-by de DKIM match. DKIM en DMARC zijn nog niet essentieel, maar net als IPv6 gaat het snel van testlab naar beter-horen.

Domain-based Message Authentication, Reporting, and Conformance (RFC 7489)

DMARC, of Domain-based Message Authentication, Reporting, and Conformance, helpt verzenders en ontvangers samen te werken om veiliger e-mailcommunicatie tot stand te brengen. DMARC is door een groep organisaties in het leven geroepen om misbruik van e-mail te beperken “door een aantal reeds lang bestaande operationele, inzet- en rapportageproblemen met betrekking tot e-mailauthenticatieprotocollen op te lossen”, aldus dmarc.org.

DMARC stelt de verzender van het bericht in staat aan te geven dat zijn berichten zijn beschermd met SPF en/of DKIM. Een DMARC beleid past duidelijke instructies voor de ontvanger van het bericht te volgen als een e-mail niet SPF of DKIM authenticatie passeren-bijvoorbeeld, weigeren of junk it.

Ook, DMARC stuurt een rapport terug naar de afzender over berichten die PASS en / of FAIL DMARC evaluatie.

Hoe SPF, DKIM, en DMARC te implementeren

Nu we een beter begrip hebben van elk van deze drie standaarden (en waarom ze belangrijk zijn), laten we eens kijken hoe u uw e-mailbeveiliging kunt verbeteren door ze te implementeren.

Noot: Laten we voor deze stap-voor-stap-doorloop doen alsof u de IT-verantwoordelijke bent bij 301 Moved, een klein webdesignbedrijf dat Google Apps gebruikt.

De laatste tijd hebt u wat problemen met Russische spambots. Uw eindgebruikers hebben geklaagd over het ontvangen van e-mail bounce-meldingen van adressen die ze nooit hebben gezien of berichten naar hebben verzonden. U realiseert zich dat iemand duidelijk frauduleuze e-mails vanaf uw domein verstuurt.

Dus hoe stopt u ze?

Note: Ik voeg het standaard BIND-formaat in platte tekst bij en een screenshot van hoe het record er in GoDaddy DNS uitziet. In GoDaddy, gebruiken alle records voor het top-level domein 301Moved.com de host “@,” jouw host zal waarschijnlijk anders zijn. Voor het doel van deze oefening, zal ik alleen uitgaande mail bespreken, niet hoe we deze standaarden behandelen in relatie tot inkomende mail van externe afzenders.

Het implementeren van SPF

Stap Een: Google’s gids voor het configureren van SPF records om te werken met Google Apps is een goede plek om te beginnen. Volgens deze instructies voegen we een nieuw TXT-record toe aan onze openbare DNS.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved gebruikt ook Zendesk, een ticketsysteem dat e-mail rechtstreeks vanaf uw domein verstuurt. U moet ervoor zorgen dat ook daarvandaan geen spam wordt verzonden.

Stap twee: zoek het SPF-record van Zendesk en voeg het toe.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

Het is belangrijk op te merken dat we geen tweede SPF-record toevoegen, want dat zou de boel kapotmaken; in plaats daarvan combineren we ze in één record, waardoor het langer wordt naarmate er meer afzenders worden toegevoegd.

Note: Je kunt maar één SPF record per domein of subdomein toevoegen.

Je weet ook dat 301 Moved een oude email gateway heeft die wat legacy dingen afhandelt, dus laten we hun IP blok ook toevoegen. 301 Moved gebruikt het “IP4” mechanisme om het IP blok te definiëren dat het bezit-198.51.100.0/24 (192.51.100.0-254).

Gebruik Dmarcian’s SPF Surveyor om uw SPF records te bekijken.

Stap Drie: Voeg afzonderlijke IPv4-adressen toe, en netblocks in Classless Inter-Domain Routing (CIDR) notatie. 198.51.100.0 voor een enkel IP-adres (geen /32 nodig) en 198.51.100.0/24 voor subnetten.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Door de oude e-mailgateway toe te voegen wordt ervoor gezorgd dat uitgaande e-mail van de gateway SPF-geautoriseerd is.

De bovenstaande mechanismen worden het meest gebruikt, maar er zijn er acht in totaal – inclusief de rare en deprecated. Deze mechanismen definiëren alleen het bereik van de overeenkomst, niet de acties zelf.

De qualifiers in de volgende sectie zijn waar PASS, SOFTFAIL en FAIL kunnen worden gedefinieerd-een overeenkomst zou resulteren in een van de drie (PASS, SOFTFAIL en FAIL) acties die worden getriggerd.

• ALL: Komt overeen met alles wat nog niet door een ander mechanisme is gedefinieerd
• A: Als de domeinnaam een adresrecord (A of AAAA) heeft dat kan worden herleid tot het adres van de afzender, komt deze overeen.
• IP4: Als de afzender zich in een bepaald IPv4-adresbereik bevindt, komt deze overeen.
• IP6: Als de afzender zich in een bepaald IPv6-adresbereik bevindt, komt deze overeen.
• MX: Als de domeinnaam een MX-record heeft dat naar het adres van de afzender verwijst, zal het overeenkomen (d.w.z. de mail komt van een van de inkomende mailservers van het domein).
• PTR: Als de domeinnaam (PTR-record) voor het adres van de klant zich in het gegeven domein bevindt en die domeinnaam naar het adres van de klant verwijst (voorwaarts-bevestigde omgekeerde DNS), zal het overeenkomen. Dit mechanisme is verouderd en dient niet langer te worden gebruikt.
• EXISTS: Als de gegeven domeinnaam naar een willekeurig adres converteert, komt deze overeen (ongeacht het adres waarnaar wordt geconverteerd). Dit wordt zelden gebruikt. Samen met de SPF macrotaal biedt het meer complexe matches zoals DNSBL-queries.
• INCLUDE: Als de included (een verkeerde benaming) policy de test doorstaat, komt dit mechanisme overeen. Dit wordt typisch gebruikt om policies van meer dan één ISP op te nemen.

Naar boven komen de qualifiers. Er zijn een miljoen manieren om deze te combineren met een blacklist en/of een whitelist model, maar voor onze doeleinden hier, gaan we alleen de drie lookup mechanismen die we hierboven noemden opnemen met een enkele qualifier aan het eind om een whitelist te maken. Onze vier kwalificeerders zijn:

• + voor een PASS resultaat. Dit kan worden weggelaten; bijvoorbeeld, +mx is hetzelfde als mx.
• ? voor een NEUTRAL resultaat, geïnterpreteerd als NONE (geen beleid).
• ~ (tilde) voor SOFTFAIL, een hulpmiddel bij het debuggen tussen NEUTRAL en FAIL. Typisch worden berichten die een SOFTFAIL terugsturen aanvaard maar gelabeld.
• – (min) voor FAIL, de mail moet geweigerd worden (zie hieronder).

Stap Vier: Pas het SOFTFAIL beleid toe.

Voorlopig gebruikt 301 Moved de tilde voor SOFTFAIL. Door het gebruik van de tilde, alle e-mail die niet overeenkomt met Google, Zendesk of het IP-blok vermeld zou SOFTFAIL. Mail zal nog steeds worden afgeleverd, maar het zal waarschijnlijk worden verzonden naar de Spam of Junk map. Dit is echter geheel afhankelijk van de mailserver van de ontvanger. Dit wordt door geen enkele standaard bepaald.

Een “-” (min) zou in deze situatie niet-matchende mail volledig afwijzen (en waarschijnlijk terugsturen). U kunt dit inschakelen zodra u meer inzicht krijgt in uw uitgaande mail (wacht op DMARC), en zodra u meer vertrouwd bent met uw mailinfrastructuur.

SPF is geweldig omdat de mailservers zelf niet hoeven te worden gewijzigd. Headers blijven hetzelfde. Gewoon een eenvoudige TXT record (de werkelijke, dedicated SPF record type was nooit zo populair en is nu deprecated) en u kunt instrueren de meeste van de mailservers in de wereld die uw naam moet flashing around.

Aan het eind van de dag, de ontvangende SMTP-server controleert de afzender IP tegen uw SPF record dat het opgevraagd, het past dan het beleid op basis van uw instructies. Met andere woorden, u machtigt uzelf, en uw providers, om (meestal) betrouwbare e-mail te verzenden omdat u een toegangscontrolelijst (ACL) openbaar maakt.

Echter, berichten kunnen onderweg nog steeds worden gewijzigd, en listige vervalsers en phishers kunnen SPF op een aantal interessante manieren omzeilen (misschien een onderwerp voor een andere dag). Het is SMTP: End-to-end TLS is niet gegarandeerd, dus we moeten altijd uitgaan van cleartext. Met berichten kan worden geknoeid of ze kunnen worden vervalst.

Maar nu naar binnen…

Implementeren van DomainKeys Identified Mail

Wanneer mail wordt verstuurd, ondertekent 301Moved.com de mail (zonder encryptie) met de prive sleutel. Vanaf nu, zal elke wijziging aan het bericht, inclusief body, headers of attachments de handtekening verbreken en het bericht ongeldig maken. We kijken weer naar Google, met behulp van hun artikel Authenticeer e-mail met DKIM

Stap Vijf: Voeg de openbare sleutel toe aan uw DNS-record.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Elk DKIM-record heeft een unieke selector prefix, wat betekent dat we er meer dan één kunnen publiceren. In plaats van ze te combineren tot één record, zoals we met SPF hebben gedaan, kunt u unieke selectors gebruiken en zo veel publieke sleutels publiceren als u nodig hebt. Hierdoor kunnen we een groot aantal DKIM geauthoriseerde servers toevoegen zonder bovengrenzen.

U zult zien dat de prefix hierboven “google” is, de standaard die Google Apps gebruikt bij het genereren van een DKIM record voor u om te publiceren. U kunt dit wijzigen in Google, en de meeste andere instellingen, dus als u het voorvoegsel “dkimawesome” wilt, is er niets dat u tegenhoudt.

Sommige cloud providers doen het anders. In plaats van het genereren van unieke sleutelparen voor elke cloud tenant, ondertekenen ze alle uitgaande e-mail voor alle domeinen met dezelfde sleutel – terwijl ze u in plaats daarvan een Canonical Name (CNAME) voor hun sleutel laten publiceren.

Zendesk doet dit, we CNAME twee verschillende sleutels op onze DNS naar hun DNS. Zendesk heeft een geweldig help artikel- Digitaal ondertekenen van uw e-mail met DKIM of DMARC (Plus en Enterprise)

Stap zes (indien van toepassing): CNAME de sleutels op uw DNS naar hun DNS. Elke DNS query op zoek naar zendesk1._domainkey.301Moved.com zal door uw DNS worden omgeleid naar zendesk1._domainkey.zendesk.com. Zendesk serveert vervolgens de DKIM keys direct.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

We kunnen zien hoe dit er bij andere servers uitziet door lokaal de nslookup tool (voor Unix of Windows) te gebruiken.

Niet alle uitgaande afzenders ondersteunen DKIM. Google Apps uiteraard wel, maar uw oude mailservers mogelijk niet.

Implementing Domain-based Message Authentication, Reporting, and Conformance

DMARC, oftewel Domain-based Message Authentication, Reporting, and Conformance, is het laatste hulpmiddel dat we hebben om kwaadaardige e-mail te bestrijden. Voor mailservers die luisteren, geeft DMARC door hoe ze SPF en DKIM moeten behandelen, en hoe ze aan u moeten rapporteren, waardoor u het broodnodige inzicht krijgt in uw leveringspercentages en de naleving van records.

En ja, DMARC is nog een TXT record.

Stap Zeven: Stel een DMARC-beleid op, identificeer het mailto-adres, stel de uitlijningsmodus in en identificeer het percentage berichten waarop het beleid moet worden toegepast (maak u geen zorgen, dit is eenvoudiger dan het klinkt).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Het bovenstaande beleid wordt aangeduid als p=none. We wijzigen de mail flow nog helemaal niet – we stellen alleen de policy en de bijbehorende rapportage in. Het adres waar de XML rapporten over de DMARC status naar toe worden gestuurd is rua=.

De ontvangende mail servers sturen XML attachments die laten zien hoe berichten van -en die claimen van- uw domein het hebben gedaan in de SPF, DKIM en DMARC gauntlet die de meeste moderne mail servers opleggen.

Deze rapporten laten per envelop zien of SPF geslaagd, mislukt of soft mislukt is. Ze laten zien of DKIM is mislukt, mislukte uitlijning of geslaagd – en hoe de bovenstaande beleidsregels zijn toegepast.

Tot slot tonen deze rapporten de uiteindelijke afleveringsstatus van het bericht. Er zijn enkele geweldige hulpmiddelen om je te helpen deze te ontleden. Zelfs als u geen beleid op berichten toepast, is het net als bij firewall-, DNS- en IDS/IPS-logboeken altijd goed om iets te hebben waar u naar terug kunt kijken.

De adkim=r specificeert ontspannen DKIM alignment mode, “r” staat voor relaxed en “s” staat voor strict. Relaxed mode staat toe dat geauthenticeerde DKIM d= domeinen binnen een gemeenschappelijk Organizational Domain in de mail header-From: adres de DMARC check PASSEN. Strict mode vereist een perfecte match tussen het DKIM d= domein en het header-From adres van een e-mail. Denk aan subdomeinen, als u die gebruikt.

aspf=r doet precies hetzelfde, behalve voor SPF checks.

De pct=100 is het percentage van berichten dat daadwerkelijk volgens het DKIM beleid wordt behandeld. Dit percentage wordt willekeurig gekozen en de ontvangende mail server zal dit beleid toepassen op dit percentage van de berichten van uw domein. We gebruiken nu 100 omdat we nog geen policy toepassen.

Voordat we een policy toepassen, zullen we dit terugbrengen tot 5 zodat slechts 1 op de 20 berichten een policy krijgt als we de p= policy vlag op quarantine of reject zetten. Op deze manier, als we het helemaal verkloten, zal 95% van onze email nog steeds worden afgeleverd, in plaats van 0% als we beginnen met pct=100.

Boodschappen die de DMARC check niet doorstaan, of de adkim= en aspf= afstemmingsmodi die we hierboven hebben ingesteld, worden dan soft gebounced, zoals hierboven, voor een quarantaine beleid, of helemaal gebounced als ze op reject staan.

Het is erg belangrijk om op te merken dat DMARC het bericht PASST als SPF of DKIM beide voldoen, en het bericht alleen FAIL-stuurt als SPF en DKIM beide voldoen. Op die manier kunnen SPF-only en DKIM-only berichten DMARC PASSEN, maar berichten zonder SPF/DKIM zullen altijd FAIL zijn. Dit is goed nieuws als u mail systemen heeft die alleen SPF, of alleen DKIM ondersteunen.

Gebruik Dmarcian’s DMARC Inspector om uw DMARC records te bekijken.

Dmarcian is een betaalde tool waarmee u uw DMARC rapporten eenvoudig kunt beheren, er zijn vele anderen, maar Dmarcian is toevallig mijn favoriet.

Update: We hebben een paar (DMARC compliant!) emails ontvangen met vragen over de subdomain policy sp=none. Met een policy die sp=none bevat, geef je geen DMARC policy op voor subdomeinen. Dit wordt handmatig gedaan door een geschikt DMARC record op te zetten voor elk specifiek subdomein of opgenomen in het hoofd DMARC record met een sp=quarantine of sp=reject.

Minimale Config

Als u dit wilt uitproberen, raad ik u aan om heel open te beginnen en eenvoudig te blijven totdat u genoeg DMARC rapporten heeft om iets te gaan afdwingen.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Definieer grote providers met een “include:” en alle IP blokken waarvandaan u mail mag versturen met een “IP4 “of “IP6.” Gebruik “MX” om je inkomende mail servers te autoriseren. En tenzij je mail direct vanaf dezelfde box/server stuurt die je website host (slechte, slechte praktijk trouwens) kun je het “A” mechanisme overslaan dat hierboven werd genoemd. De “?” past geen beleid toe op uw berichten, maar zorgt ervoor dat uw SPF record daar komt zodat DMARC het kan herkennen.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Geef de juiste selector, “google” in dit geval, en de juiste sleutel. Vergeet niet dat je er meer dan een kunt publiceren.

Note: Publiceer deze sleutel niet, anders kan ik je mail DKIM-ondertekenen.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

Voor DMARC hebben we geen policy toegepast, we zijn in relax mode, maar we vragen om de XML rapporten naar een mailbox te sturen waar we toegang toe hebben. Van daaruit geeft DMARC ons vrij snel (niet real time) feedback over hoe we de verschillende policies in alle drie de records kunnen aanscherpen.

Maar wacht, hoe zit het met TLS?

Transport Layer Security, of TLS, maakt geen deel uit van de DMARC standaard, en het is ook geen DNS record.

In plaats daarvan is TLS gewoon een volwassen Secure Socket Layer (SSL) die mailservers kunnen gebruiken om berichten naar elkaar te versturen over openbare verbindingen. Het is SMTP verpakt in TLS, zoals je veel andere dingen kunt doen binnen/over TLS-SNMP over TLS en FTP over TLS zijn veel voorkomende voorbeelden. TLS versleutelt berichten alleen onderweg, niet in rust.

Als we een DKIM-ondertekend bericht over TLS sturen, is het de hele tijd ondertekend, maar alleen versleuteld als het van uw Google Apps naar hun Cisco Ironport hopt, of waar uw e-mail dan ook doorheen gaat. TLS beschermt berichten in rust zeker niet, hoewel het ook wordt gebruikt voor uw HTTPS://-sessie naar webmail terwijl u datzelfde bericht leest, maar nogmaals, dat is in transit.

TLS is iets dat u waar mogelijk zou moeten gebruiken, maar wees ook klaar om cleartext te spreken met andere openbare mailsystemen. Zelfs in 2015 ondersteunen sommige mailservers geen STARTTLS (serverspeak voor het beginnen van de TLS-handshake).

U kunt het gebruik van TLS afdwingen bij bepaalde externe domeinen in Google Apps met een eenvoudige configuratiewijziging. Het is een goede zaak om het in te schakelen voor geassocieerde externe bedrijven, partners en andere organisaties, maar dwing TLS pas af als u zeker weet dat het betrouwbaar is en wordt ondersteund door alle mailservers op dat specifieke domein.

Het belang van e-mailbeveiliging en het vermijden van afzenderfraude

Of u nu een ervaren IT-beheerder bent of net begint, deze drie standaarden zijn even belangrijk. Toegegeven, wat elk van hen doet, en hoe ze samenwerken kan een beetje onoverzichtelijk worden, maar de implementatie ervan is relatief ongecompliceerd en de voordelen zijn uw tijd meer dan waard.