Deze pagina bevat een lijst met uitzonderingssituaties op metingen op basisbeveiliging. Bij een meting zonder context zal dit negatief worden beoordeeld. Daarom voegt basisbeveiliging uitzonderingen toe volgens het zogenoemde “comply or explain” proces.
Mocht een uitzondering ontbreken, neem dan contact op. Deze aanvraag tot uitzondering wordt dan beoordeeld en al dan niet toegevoegd aan de metingen. Neem hierbij de eisen van de handleiding voor een goede verklaring mee.
Versienummers
De verwachting is geen informatie tegen te komen die een aanvaller kan gebruiken om een aanval uit te voeren. Over het algemeen verwachten we dus geen versienummers. Dit zijn de uitzonderingen daarop:
- SSH2.0 strings zonder comments zijn uitgezonderd omdat de versie-informatie onderdeel is van het protocol. Zie www.openssh.com/txt/rfc4253.txt 4.2. Dat betekent bijvoorbeeld dat “OpenSSH_9.2p1” wordt goedgekeurd maar “OpenSSH_9.2p1 Debian-2+deb12u2” niet. Dat komt omdat hierin extra informatie (“Debian-2+deb12u2”) wordt gepubliceerd over het systeem. Dit betekent dat het systeem niet is gehard tegen aanvallers en een aanvaller precies weet wat voor systeem dit is.
- Major versies van bekende producten die weinig zeggen over het patch-level. Zoals: Microsoft IIS 8.5, Microsoft httpapi/2.0, rtc 7.0, awselb/2.0. Deze worden goedgekeurd.
Certificaten
De verwachting is dat alle certificaten worden uitgegeven door een geacrediteerde organisatie. Deze certificaten worden vervolgens vertrouwd in de browser en apparatuur. Dit zijn de uitzonderingen daarop:
- G1 Overheidscertificaten. Deze worden niet vertrouwd door de browser maar wel door de rijksoverheid. Dit wordt aangegeven met een verklaring. Het niet vertrouwen is nu design. Het certificaat dat geaccepteerd wordt moet o.a. het serienummer 10004001 bevatten.
Open Poorten
De verwachting is dat het aanvalsoppervlak minimaal is: dus zo min mogelijk open poorten. Dit zijn de uitzonderingen daarop:
- 8080/8443 (Cloudflare): De cloudflare firewal zet standaard een aantal overbodige poorten open, zoals 8080. Je kan zelf inrichten wat daar komt te staan. Als we daar cloudflare zien staan keuren we het nu goed met een verklaring. Dit is uiteindelijk niet goed en we stimuleren cloudflare gebruikers om aan te geven dat het bedrijf deze poorten dicht moet gaan zetten. Deze uitzondering vindt plaats op basis van de inhoud van de webpagina. Hier wordt een policy op toegepast als verklaring.
- 8443 (VPN): Subdomeinen die te maken hebben met thuiswerken mogen deze poort open zetten. Dit herkennen we door subdomeinen (en vele varianten op): telewerken, thuiswerken, werkplek, werkstation, extranet, intranet, remote, werkenopafstand, vpn en dergelijke.
Versleuteld dataoverdracht (HTTPS)
De verwachting is dat websites en webdiensten versleuteld worden aangeboden, zodat informatie vertrouwelijk blijft. Dit zijn de uitzonderingen daarop:
- Certificate revocation lists: Er is geen versleutelde verbinding nodig op subdomeinen”pki”, “crl”, “ocsp” en een aantal varianten daarop. De HSTS header hoeft niet gezet te worden op poort 443 (we zouden geen https verwachten).
- Er is geen versleuteling nodig op Microsoft Autodiscover subdomeinen, dit is een algemene uitzondering voor Microsoft diensten omdat anders iedereen rood staat…? Dit geldt voor “autodiscover” en “autodiscover.test” domeinen.
HTTP Headers
De verwachting is dat alle websites zijn ingericht op veiligheid. Dit zijn de uitzonderingen daarop:
- Ontbrekende headers voor SOAP/JSON/XML content types: Deze diensten zijn niet bedoeld voor mensen en hoeven dus ook niet de browser-bescherming te bieden die bedoeld is om mensen te beschermen.
- Ontbrekende headers voor technische diensten: Voor het ADFS subdomein hoeft de HSTS header niet worden gezet.
Overig
De verwachting is dat men zich aan alle veiligheidseisen houdt. Er zijn complexe scenario’s waarop dit nog niet gebeurd of mogelijk is. Dit zijn de uitzonderingen:
- Microsoft diensten op subdomeinen rondom lyncdiscover, sip, enterpriseenrollment, enterpriseregistration, webmail, msoid. Dit is gedaan omdat deze diensten niet bedoeld zijn voor browsers maar voor geautomatiseerde diensten. Tegelijkertijd omdat de impact overal hoog zou zijn en ICT dienstverleners deze problemen niet kunnen oplossen:
- Het certificaat op deze subdomeinen wordt vertrouwd, ondanks dat deze geen vertrouwen krijgt vanuit Qualys.
- Omdat het diensten zijn die bedoeld zijn voor apparaten, en niet voor browsers, zijn de http headers niet verplicht.