AdES

Ades Baseline Profiles

Xades v2.1

Pades v2.1

Cades v2.2

Asic v2.2

Digitale handtekeningen

De AdES Baseline Profiles kunnen worden toegepast op de ondertekening van XML-, CMS-, PDF- en ZIP-bestanden met geavanceerde en/of gekwalificeerde elektronische handtekeningen, zegels of tijdstempels.

Een digitale handtekening geeft de ontvanger van een digitaal document of bericht zekerheid dat het afkomstig is van de ondertekenaar en dat deze de inhoud van het bericht onderschrijft. De Advanced Electronic Signature (AdES) standaard voorziet in het digitaal tekenen van documenten met een geavanceerde of gekwalificeerde digitale handtekening.

Als een verzender een document tekent met een digitale (AdES) handtekening, dan moet de ontvanger die ook kunnen verifiëren.  Dat wordt soms bemoeilijkt doordat AdES verschillende configuraties toestaat, waardoor een verzender opties kan gebruiken die de ontvanger niet kan verifiëren.  De AdES Baseline Profiles voorzien in afspraken zodat verzender en ontvanger dezelfde AdES basisconfiguratie gebruiken.

De Advanced Electronic Signatures (AdES) standaarden bevatten meerdere opties die in een handtekening kunnen worden gebruikt. Als een verzender een AdES configuratie gebruikt die niet door de ontvanger wordt ondersteund, dan kan de ontvanger de handtekening niet verifiëren.

Om te garanderen dat de ontvanger de AdES handtekening van de ondertekenaar altijd kan valideren is het noodzakelijk om afspraken te maken over het gebruik van de AdES opties. Een dergelijke selectie van opties wordt een profiel genoemd. De AdES Baseline Profiles beschrijven profielen voor het ondertekenen van XML-documenten (XAdES), PDF-documenten (PAdES), CMS-documenten (CAdES) en documentcontainers/ZIP (ASiC).

ETSI

Nee

AES

Advanced Encryption Standard

FIPS 197

Versleuteling

Versleutelingstechniek voor de bescherming van de vertrouwelijkheid van de opgeslagen en verzonden data.

De AES-standaard is een versleutelingstechniek voor de bescherming van de vertrouwelijkheid van opgeslagen en verzonden data en is de vervanger van de verouderde DES standaard. AES wordt wereldwijd op zeer veel verschillende wijzen gebruikt. Voorbeelden van het gebruik zijn:

• In programma's zoals WinRAR, WinZip, PowerArchiver, e.d. wordt AES als encryptie aangeboden.

• AES wordt toegepast voor beveiliging (WPA2) in draadloze netwerken (Wifi).

• AES wordt toegepast voor het versleutelen van gegevens voor verzending over het internet, https verkeer etc.

• In hardware voor netwerken wordt veelvuldig gebruikt gemaakt van AES.

AES is ontwikkeld door het National institute of technology and standards (NIST), een federaal agentschap binnen het U.S. Departement of Commerce en is inmiddels ook opgenomen door ISO.

NIST

Nee

ASN.1

Abstract syntax notation one

ISO/IEC 8824-1:2015

Datastructuren

Beschrijving van data die binnen een netwerk (geautomatiseerd) verzonden of ontvangen worden.

Abstract syntax notation one (ASN.1) wordt veel gebruikt voor het beschrijven van X.509 certificaten en toepassing daarvan. Voorbeeld van een toepassing is RSA public key voor beveiliging van het transactieverkeer in de elektronische handel. Hiernaast is deze standaard een syntax om data in telecommunicatie en computer netwerken te representeren, te coderen, over te brengen en te decoderen.

ASN is een standaard manier voor het beschrijven van data die binnen een netwerk verzonden of ontvangen worden en maakt het mogelijk om grote hoeveelheden gegevens geautomatiseerd te valideren aan de hand van specificaties met behulp van software tools.

ISO

Nee

CAA

Certification Authority Authorization Resource Record

RFC 8659

Digitale certificaten

CAA kan worden toegepast binnen DNSSEC om fraude met certificaten te voorkomen.

In de afgelopen jaren zijn er wereldwijd diverse incidenten geweest waarbij een partij PKI-certificaten kon aanvragen (en krijgen) voor andermans domeinen. Het ging hier met name om fouten in het uitgifteproces. Toepassing van de standaard CAA verkleint de kans dat iemand een certificaat kan aanvragen voor domeinen van bijvoorbeeld overheidsinstellingen of banken. De CAA-standaard biedt verder de mogelijkheid aan CA's om melding te maken van foutief aangevraagde certificaten. Hierdoor krijgen domeineigenaren meer inzicht in eventuele foutieve of frauduleuze aanvragen voor het domein.

CAA is een DNS-record dat domeineigenaren extra controle geeft over SSL-certificaten die worden uitgegeven voor diens domeinen. Met het CAA record geeft een domeineigenaar aan welke certificate authority (CA) certificaten uit mag geven voor diens domeinen. Een domein eigenaar kan dit zelf regelen zonder dat hier medewerking vanuit de CA voor nodig is. Zo kan de eigenaar van een domein zelf bepalen welke CA's certificaten mogen uitgeven voor zijn of haar domeinen. CA's moeten bij uitgifte van een certificaat verplicht het CAA record van het betreffende domein controleren. Het gebruik van CAA betekent overigens niet dat de gebruiker vastzit aan een CA.

CAA is alleen effectief als het DNS waarin het CAA-record geadministreerd wordt, is beschermd met DNSSEC. Zonder DNSSEC-bescherming kan een aanvaller het DNS-verkeer omleiden, waardoor het CAA-record niet meer effectief is. De CAA-specificatie adviseert dan ook uitdrukkelijk het gebruik van CAA in combinatie met DNSSEC. 

IETF

Nee

DKIM

Domain Keys Identified Mail

RFC 6376

E-mail

DKIM kan worden toegepast op alle domeinnamen waarvandaan wordt gemaild én op alle mailservers waarmee e-mail wordt verstuurd en ontvangen.

Het gebruik van DKIM verkleint de kans op misbruik van e-mailadressen doordat ontvangers betrouwbaar echte e-mails van phishingmails of spam kunnen onderscheiden. Ook kunnen ontvangers controleren of de inhoud van de e-mail door derden is gemanipuleerd.

DKIM is een techniek waarmee e-mailberichten kunnen worden gewaarmerkt. Een domeinnaamhouder kan in het DNS-record van de domeinnaam aan geven met welke sleutel e-mail namens de betreffende domeinnaam ondertekend moet worden. Een ontvangende mailserver kan de publieke sleutel in het DKIM-record van de domeinnaamhouder gebruiken om te controleren of de gebruiker van het betreffende domein, die een e-mail verstuurt, als afzender te controleren. Hierdoor kan de authenticiteit van de e-mail worden bepaald.

IETF

Ja

DMARC

Domain-based Message Authentication, Reporting and Conformance

RFC 7489

E-mail

DMARC kan worden toegepast op alle domeinnamen, ook op domeinen waarvan niet wordt gemaild, én op alle mailservers waarmee e-mail wordt ontvangen.

DMARC geeft de verzendende partij de mogelijkheid om beleid te formuleren wat er met e-mails moet gebeuren wanneer de echtheidswaarmerken niet kloppen. Het geeft ook rapportagemogelijkheden voor legitieme en niet-legitieme uitgaande e-mailstromen.

DMARC maakt het mogelijk om beleid in te stellen over de manier waarop een e-mailprovider om moet gaan met e-mail waarvan niet kan worden vastgesteld dat deze afkomstig is van het vermelde afzenderdomein. Hierdoor kunnen organisaties voorkomen dat anderen e-mails versturen namens het e-maildomein van de organisatie. Het gebruik van DMARC kan daarmee ingezet worden voor het verminderen en/of voorkomen van misbruik van de domeinnaam middels e-mail. Ook kan door het gebruik van de standaard worden voorkomen dat e-mailmailingen door e-mailproviders onterecht voor spam worden aangezien.

IETF

Ja

DNSSEC

Domain Name System Security Extensions

RFC 4033

RFC 4034

RFC 4035

Domeinen

DNSSEC kan worden toegepast op alle domeinnamen én op DNS-resolvers die clients van organisaties direct of indirect van DNS-antwoorden voorzien.

Met DNSSEC kan de ontvanger de echtheid van de domeinnaaminformatie (waaronder IP-adressen) controleren. Dit voorkomt bijvoorbeeld dat een aanvaller het IP-adres ongemerkt manipuleert (DNS-spoofing) en daarmee verstuurde e-mails omleidt naar een eigen mailserver of gebruikers misleidt naar een frauduleuze website.

Een domeinnaamhouder kan met DNSSEC een digitale handtekening toevoegen aan DNS-informatie. Aan de hand van deze handtekening kan een internetgebruiker (onderwater en volledig automatisch m.b.v. speciale software) de inhoud en de ontvangen DNS-informatie valideren. Hierdoor is met grote waarschijnlijkheid vast te stellen dat het antwoord van de DNS onderweg niet is gemanipuleerd door derden.

IETF

Ja

ETSI TS 119 312

Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms

v1.1.1 (2014-11)

Digitale handtekeningen

ETSI 119 312 wordt toegepast bij het digitaal ondertekenen van een document of transactie.

De standaard is van belang voor het waarborgen van de authenticiteit van een document via het toevoegen van een digitale handtekening.

De ETSI TS 119 312 standaard definieert algoritmes en sleutellengtes. De algoritmes worden gebruikt voor het plaatsen van een hash over een document of transactie, en is de eerste stap naar de digitale ondertekening van een bericht. Daarnaast beschrijft de standaard andere aspecten zoals algoritmen en methoden voor 'Signature schemes' , 'Key pair generation' en 'Random number generation'.

ETSI

Nee

HTTPS en HSTS

HyperText Transfer Protocol Secure en HTTP Strict Transport Security

Versie 1.2:

RFC 2818

RFC 6797

Websites

HTTPS en HSTS kunnen worden toegepast op de communicatie tussen clients (zoals webbrowsers) en servers voor alle websites en webservices.

HTTPS en HSTS zorgen samen voor beveiligde verbindingen met websites, met als doel de veilige uitwisseling van gegevens tussen een webserver en client (vaak een webbrowser). Dit maakt het voor cybercriminelen moeilijker om verkeer om te leiden naar valse websites en om de inhoud van webverkeer te onderscheppen.

Bezoekers van een website kunnen een beveiligde verbinding met een website herkennen aan HTTPS in de URL (HTTPS://). De website-identiteitsknop (het hangslot) wordt in de adresbalk weergegeven zodra een bezoeker een beveiligde website bezoekt.

HTTPS zorgt voor het gebruik van HTTP over een met TLS beveiligde verbinding. Dit betekent dat het webverkeer door middel een certificaat wordt versleuteld.

HSTS zorgt ervoor dat een webbrowser, na het eerste contact over HTTPS, bij vervolgbezoek de website altijd direct over HTTPS opvraagt.

IETF

Ja

IPv6 en IPv4

Internet Protocol

Version 4: RFC 791

Version 6: RFC 2460

Netwerken

IPv6 en IPv4 kunnen in combinatie (‘dual stack’) worden toegepast op communicatie tussen toepassingen in (een) netwerk(en).

Internet Protocol (IP) maakt communicatie van data tussen ICT-systemen binnen een netwerk, zoals internet, mogelijk. IPv6 heeft een veel grotere hoeveelheid beschikbare IP-adressen ten opzichte van de voorganger IPv4 en verbeterde beveiliging. Dit maakt verdere groei en innovatie van het internet mogelijk. 

IPv6 is niet backwards compatible. Dit wil zeggen dat een IPv4-systeem niet een IPv6-systeem kan bereiken, of andersom. Om die reden moet een organisatie bij de aanschaf van een ICT-product/-dienst beide versies uitvragen. 

De standaard bepaalt dat ieder ICT-systeem binnen het netwerk een uniek nummer (IP-adres) heeft. Hierdoor kunnen ICT-systemen elkaar herkennen en onderling data uitwisselen.

IETF

Ja

IP Sec

Security Architecture for the Internet Protocol

RFC 4301

RFC 4309

RFC 6040

RFC 7619

Netwerken

Beveiliging van IP verbindingen.

De standaard maakt het mogelijk om IP verbindingen te encrypten. Hierdoor is het netwerk beveiligd waardoor gevoelige data kan worden uitgewisseld. Vooral relevant voor VPN's. In andere gevallen is beveiliging op transport niveau meer toepasselijk. Het voordeel van vercijfering op IP niveau is dat er geen applicaties hoeven te worden gewijzigd.

De IPsec standaard definieert een basis architectuur voor het toevoegen van services op het gebied van security voor de IP laag. Het kan zowel in IPv4 omgevingen als in IPv6 omgevingen gebruikt worden.

IETF

Nee

OAuth

Open Authorisation

Version 2.0: RFC 6749

Toegang

OAuth 2.0 is een autorisatiestandaard voor web gebaseerde applicaties die gegevens uitwisselen met behulp van API’s.

Met OAuth 2.0 kunnen gebruikers of organisaties een programma of website toegang geven tot specifieke gegevens, die opgeslagen zijn op een ander systeem, zonder hun gebruikersnaam en wachtwoord uit handen te geven. OAuth 2.0 wordt als standaard vaak gebruikt voor de autorisatie van gebruikers op mobiele telefoons, tablets, wearables en internet of things apparaten. Een bekend voorbeeld is de mogelijkheid om bij een bepaalde onlinedienst in te loggen gebruikmakend van een Google- of Facebook-account.

OAuth 2.0 maakt gebruik van 'tokens' waardoor vertrouwelijke gegevens als een gebruikersnaam of wachtwoord niet afgegeven hoeven te worden. Elk token geeft slechts toegang tot specifieke gegevens van één website voor een bepaalde duur.

OAuth 2.0 is een generieke standaard die meestal nog profielen (aanvullende afspraken) vereist voor toepassing in specifieke domeinen.

IETF

Nee

OIDC

OpenID Connect

Versie 1.0: Specification

Toegang

OpenID Connect kan toegepast worden bij het beschikbaar stellen van federatieve authenticatiediensten.

OpenID Connect (OIDC) is een open en gedistribueerde manier om één authenticatiedienst naar keuze te kunnen hergebruiken bij meerdere (semi-)overheidsdienstverleners, bij gebruik vanuit onder andere webapplicaties en mobiele apps. Belangrijkste redenen om op OIDC in te zetten is de actieve ontwikkelingen van mobile-first ondersteuning van digitale diensten.

OIDC bouwt voort op OAuth. Het maakt het mogelijk om andere authenticatievoorzieningen middels een routeringsvoorziening te ontsluiten. Bovendien geeft het de mogelijkheid om meerdere attributen of andere type identifiers mee te geven.

OIDC is een generieke standaard die meestal nog profielen (aanvullende afspraken) vereist voor toepassing in specifieke domeinen.

OpenID Foundation

Nee

RPKI

Resource Public Key Infrastructure

RFC 6480

Netwerken

RPKI kan worden toegepast door netwerkaanbieders en houders van blokken IP-adressen bij het aanbieden van netwerkconnectiviteit, ter beveiliging van het BGP (Border Gateway Protocol). Dit geldt zowel voor het publiceren van ROA's (Route Origin Authorisations) als voor het valideren en het 'droppen' van invalide routes.

Resource Public Key Infrastructure (RPKI) is een standaard met als doel om zogenaamde route hijacks te voorkomen. Bij een route hijack wordt internetverkeer omgeleid naar de systemen van een niet geautoriseerd netwerk. Een hijack kan het gevolg zijn van een simpele typefout van een netwerkbeheerder die daarmee onbedoeld internetverkeer omleidt, of het gevolg zijn van een doelgerichte aanval op de infrastructuur van het internet om bijvoorbeeld websites onbereikbaar te maken of om gegevens van internetgebruikers afhandig te maken.

Met RPKI kan de rechtmatige houder van een blok IP-adressen een autoritatieve, digitaal getekende verklaring publiceren met betrekking tot de intenties van de routering vanaf haar netwerk. Deze verklaringen kunnen andere netwerkbeheerders cryptografisch valideren en vervolgens gebruiken om filters in te stellen die onrechtmatige routering negeren. Het netwerk valt terug op het 'oude' onbeveiligde routering als RPKI wegvalt.

IETF

Nee

SAML

Security Assertion Markup Language

Versie 2.0

Toegang

SAML kan worden toegepast op de uitwisseling van authenticatie- en autorisatiegegevens om gebruikers na eenmalig inloggen toegang te geven tot meerdere diensten.

Security Assertion Markup Language (SAML) is een standaard voor het veilig uitwisselen van authenticatie- en autorisatiegegevens van gebruikers tussen verschillende organisaties. SAML maakt het mogelijk om op een veilige manier via het internet toegang te krijgen tot diensten van verschillende organisaties, zonder dat je per dienst eigen inloggegevens nodig hebt, of bij elke dienst apart moet inloggen.

Bij SAML spelen drie partijen een rol: de ‘gebruiker’, de ‘Identity Provider (IdP)’ en de ‘Service Provider (SP)’. De IdP regelt het authenticatieproces van de gebruiker en kan na succesvolle authenticatie aan de SP gegevens verstrekken over de identiteit, attributen en rechten van een gebruiker.

OASIS

Nee

SCIM

System for Cross-domain Identity Management

RFC 7642

RFC 7643

RFC 7644

Toegang

Geautomatiseerde uitwisseling van identiteitsinformatie van gebruikers tussen verschillende (cloud) systemen.

SCIM zorgt ervoor dat identiteitsinformatie van gebruikers systeemoverstijgend op de juiste plek aanwezig is. Hierdoor kunnen gegevens die niet meer in systemen horen te staan, omdat een gebruiker bijvoorbeeld niet langer in dat systeem hoeft te zijn opgenomen, worden verwijderd. Doordat dit geautomatiseerd gebeurt is relatief weinig inspanning nodig om de gewenste toevoeging of verwijdering van gegevens te realiseren. Deze standaard is gericht op het reduceren van kosten en complexiteit en het voorbouwen op bestaande protocollen. SCIM heeft als doel om gebruikers snel, goedkoop en eenvoudig in, uit en tussen clouddiensten te brengen.

System for Cross-domain Identity Management (SCIM) zorgt voor de uitwisseling van identiteitsinformatie van gebruikers tussen verschillende systemen op een geautomatiseerde wijze. SCIM wordt bijvoorbeeld gebruikt om in de cloud op verschillende plekken informatie over de identiteit van gebruikers te kunnen toevoegen of verwijderen. SCIM maakt gebruik van een Application programming interface (API) op basis waarvan een computerprogramma kan communiceren met een ander programma.

IETF

Nee

SHA-2

Secure Hash Algorithm 2

ISO/IEC 10118- 3:2016

FIPS PUB 180-4

Versleuteling

Cryptografisch hashalgoritme ten behoeve van authenticatie en integriteitscontrole.

SHA-2 (Secure Hash Algorithm 2) behoort tot de zogenaamde cryptografische hash algoritmen die uit een willekeurige hoeveelheid gegevens (bijvoorbeeld een stuk tekst) een unieke vingerafdruk (van een vaste vooraf vastgestelde lengte) kunnen genereren. Een wijziging in de gegevens zal leiden tot een wijziging in de vingerafdruk. Bovenstaande eigenschappen maken dat deze algoritmen bij uitstek geschikt zijn voor het gebruik in bepaalde beveiligingstoepassingen, zoals een elektronische handtekening.

De cryptografische hash functies zijn wiskundige bewerkingen uitgevoerd op digitale gegevens. Door de berekende "hash" te vergelijken met de bekende hashwaarde kan de integriteit van de gegevens worden bepaald. Immers een wijziging in de gegevens zal een compleet andere hash-waarde opleveren. Een belangrijk aspect is dat het een ‘one-way’ werking heeft. Vanuit een berekende hash waarde is het zo goed als onmogelijk om naar de oorspronkelijke gegevens terug te rekenen.

ISO

Nee

SSH-2

Secure Shell (SSH) protocol architecture

RFC 4251:2006

Toegang

Op een versleutelde manier; inloggen op een andere computer, op afstand commando's op de andere computer uitvoeren en het uitvoeren van andere network services tussen twee netwerkcomputers, over een onbeveiligd netwerk.

Omdat SSH met encryptie werkt, is het voor eventuele afluisteraars, die de (internet)verbinding aftappen, zo goed als onmogelijk om wachtwoorden of commando's te achterhalen.

SSH-2 is een cryptografisch netwerk protocol dat het mogelijk maakt om op een versleutelde manier in te loggen op een andere computer, op afstand commando's op de andere computer uit te voeren via een shell en andere veilige network services tussen twee netwerk computers te laten werken die via een secure channel over een onbeveiligd netwerk communiceren. 

IETF

Nee

S/MIME

Secure Multipurpose Internet Mail Extensions

Versie 3.2: RFC 5751

E-mail 

S/MIME kan worden toegepast op het digitaal ondertekenen van e-mail berichten wanneer aanvullende beveiliging nodig is.

Waar een hoog niveau van e-mail beveiliging nodig is kan S/MIME toegevoegde waarde bieden ten opzichte van de standaarden SPF, DKIM en DMARC. S/MIME waarborgt naast de betrouwbaarheid van de afzender namelijk ook de integriteit (door digitale tekening) van de inhoud van de e-mail tussen de verzendende en ontvangende e-mail applicatie ('end-to-end').

S/MIME is een standaard voor de ondertekening en versleuteling van e-mail tussen gebruikersapplicaties ('end-to-end'). De verzender ondertekent en/of versleutelt zijn mail met behulp van een certificaat dat de ontvanger op echtheid kan controleren, net als bij https en TLS.

In mei 2018 werd een veiligheidsprobleem gepubliceerd dat S/MIME raakt. Als gevolg hiervan wordt geadviseerd om S/MIME alleen nog te gebruiken voor digitale ondertekening, en niet meer voor versleuteling van e-mail.

IETF

Nee

SPF

Sender Policy Framework

Versie 1: RFC 7208

E-mail

SPF kan worden toegepast op alle domeinnamen, ook op domeinen waarvan niet wordt gemaild, én op alle mailservers waarmee e-mail wordt ontvangen.

Het gebruik van SPF verkleint de kans op misbruik van e-mailadressen doordat ontvangers betrouwbaar echte e-mails van phishingmails of spam kunnen onderscheiden.

SPF is een techniek waarmee een domeinhouder de IP-adressen van verzendende mailservers kan publiceren in de DNS. Een ontvangende mailserver kan deze IP-adressen gebruiken om te controleren of een e-mail daadwerkelijk afkomstig is van een verzendende mailserver van de betreffende domeinhouder.

IETF

Ja

STARTTLS en DANE

SMTP Service Extension for Secure SMTP over Transport Layer Security (STARTTLS) en SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE)

RFC 3207

RFC 7672

E-mail

STARTTLS en DANE kunnen in combinatie worden toegepast op ontvangende en verzendende e-mailservers.

Mailverkeer tussen mailservers verloopt via SMTP. STARTTLS in combinatie met DANE gaan, in aanvulling op SMTP, afluisteren of manipuleren van dit mailverkeer door internetcriminelen tegen. 

STARTTLS maakt het mogelijk om SMTP-verkeer tussen mailservers over een met TLS versleutelde verbinding te laten lopen.

DANE, dat voortbouwt op DNSSEC, geeft zekerheid over de identiteit van de ontvangende mailserver. Dit voorkomt dat een aanvaller zich kan uitgeven als ontvangende-mailserver, waardoor hij het mailverkeer kan onderscheppen. Daarnaast dwingt DANE het gebruik van TLS af. Dit voorkomt dat een aanvaller de opzet van STARTTLS kan blokkeren, om zo toegang tot de onversleutelde berichten te krijgen.

IETF

Ja

STIX en TAXII

Structured Threat Information eXpression (STIX) en Trusted Automated eXchange of Indicator Information (TAXII)

STIX v1.2.1

TAXII v1.1.1

Cyberdreigingsinformatie

STIX 1.2.1 en TAXII 1.1.1 kunnen worden toegepast op de gestructureerde uitwisseling van informatie over digitale dreigingen tegen informatiesystemen.

STIX en TAXII maken het mogelijk om dreigingsinformatie over een cyberdreiging of -aanval op een gestructureerde en automatisch verwerkbare manier te beschrijven en in real-time te delen met belanghebbende organisaties. Op basis van de dreigingsinformatie kunnen de betreffende organisaties indien nodig beveiligingsmaatregelen treffen.

STIX is een op XML-gebaseerde gestructureerde taal om cyberdreigingsinformatie te beschrijven zodat deze op een consistente manier kan worden gedeeld, opgeslagen en geanalyseerd.

TAXII is een protocol voor het geautomatiseerd en in real-time uitwisselen van cyberdreigingsinformatie in STIX-formaat.

OASIS

Ja

TLS

Transport Layer Security

Versie 1.3: RFC 8446

Versie 1.2

Applicaties

TLS kan worden toegepast op de uitwisseling van gegevens tussen clients en servers, inclusief machine-to-machine communicatie.

TLS zorgt voor beveiligde internetverbindingen, met als doel de veilige uitwisseling van gegevens tussen een internetsystemen (zoals websites of mailservers). Dit maakt het voor cybercriminelen moeilijker om internetverkeer te onderscheppen of te manipuleren.

TLS zorgt door middel van de uitwisseling van certificaten voor de versleuteling van gegevens tijdens het transport tussen internetsystemen. De certificaten bieden ook zekerheid over de identiteit van beide communicerende partijen. TLS kan bovenop bestaande internetstandaarden, zoals voor webverkeer en e-mailverkeer, worden gebruikt.

IETF

Ja

TOTP

Time-based One-time Password Algorithm

RFC 6238

Toegang

Het authenticeren van gebruikers door middel van de combinatie van een geheime sleutel en een eenmalig wachtwoord, voorzien van een tijdsstempel.

TOTP zorgt ervoor dat een twee-factor authenticatie mogelijk is via een eenmalig wachtwoord dat op dat moment gegenereerd wordt en daarmee nog niet in het bezit was vooraf aan de aanvraag. Hierdoor is het eenmalige wachtwoord uniek en zorgt voor een extra beveiliging naast wachtwoorden die vaker gebruikt worden om bijvoorbeeld in te loggen in een account. Daarnaast zorgt het korte tijdspad dat een wachtwoord beschikbaar is ervoor dat het eenmalige wachtwoord snel zijn waarde verliest.

Time-based One-time Password Algorithm (TOTP) is een algoritme dat een eenmalig wachtwoord genereert vanaf een gedeelde geheime sleutel. Het wachtwoord is voor een korte periode beschikbaar na het opvragen, daarna is het niet meer te gebruiken en wordt een nieuw wachtwoord gemaakt. De standaard wordt gebruikt in meerdere twee-factor authenticaties en oplossingen van leveranciers.

IETF

Nee

WPA2 Enterprise

Wi-Fi Protected Access II Enterprise

Versie 2 (802.11)

Netwerken

WPA2 Enterprise kan worden toegepast op het tot stand brengen van toegang tot WiFi-netwerken, met uitzondering van openbare netwerken voor gastgebruik.

WPA2 Enterprise maakt het mogelijk dat gebruikers automatisch en veilig toegang krijgen tot aangesloten WiFi-netwerken. Ook als deze WiFi-netwerken zich buiten de eigen organisatie bevinden. De authenticatie vindt plaats op basis van bestaande identiteitsgegevens van de gebruiker, hierdoor hoeven gebruikers niet opnieuw in te loggen. Met het gebruik van WPA2 Enterprise is ook de integriteit van de netwerkverbinding geborgd.

Bij WPA2 Enterprise spelen drie partijen een rol: de ‘gebruiker’, de ‘Identity Provider (IdP)’ en de ‘Service Provider (SP)’. Zodra een gebruiker contact maakt met het betreffende WiFi-punt toetst de SP (beheerder van het WiFi-punt) op basis van de inloggegevens bij de IdP (de thuisorganisatie van de gebruiker) de identiteit van de gebruiker. Na positieve verificatie van de identiteit van de gebruiker, wordt toegang verleend tot het WiFi-netwerk zonder dat aanvullende inlog noodzakelijk is.

De WPA2 Enterprise standaard refereert naar een aantal andere standaarden:

• EAP: standaard voor authenticatie over een point-to-point-verbinding, bijvoorbeeld tussen een WiFi-gebruiker en een accesspoint.

• IEEE 802.1X: standaard om EAP te gebruiken op een WiFi-netwerk.

• RADIUS: maakt het mogelijk om toegang te verlenen op basis van de identiteit van de gebruiker.

IEEE-ISTO

Nee

X509

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile)

RFC 5280

RFC 6818

Digitale certificaten

Authenticatie van applicaties, gebruikers, systemen middels certificaten op het internet, zoals www, elektronische mail (beveiligd), gebruikers authenticatie en IPsec, SSL en TLS.

De standaard is belangrijk voor de authenticatie van applicaties, gebruikers, systemen via certificaten op het internet. Hierbij kan het gaan om www, elektronische mail (beveiligd), gebruikers authenticatie en IPsec, SSL en TLS. Elke gebruiker kan op deze manier via bijvoorbeeld zijn browser verifiëren of het certificaat dat gebruikt wordt voor de beveiligde koppeling nog valide is of dat deze ingetrokken is en of een verbinding dus wel of niet veilig is.

De X.509-standaard (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) beschrijft een systeem van certificaten met een beperkte levensduur en de wijze waarop de intrekking van deze certificaten in een zogenaamde Blacklist (de CRL) geregeld wordt. De standaard wordt wereldwijd zeer veel gebruikt. De standaard is belangrijk onderdeel in de communicatie tussen de overheid met burgers en bedrijven. Het is overigens niet mogelijk de X.509 standaard te gebruiken zonder gebruik te maken van een aanvullende set bindende afspraken die zijn vast gelegd in een zogenaamd Certificate Profile.

IETF

Nee