Disclaimer: Het origineel van deze pagina geschreven in het Nederlands. Deze pagina is automatisch vertaald naar andere talen met behulp van DeepL. Dit kan leiden tot verschillen in nuance, toon en betekenis. Raadpleeg bij twijfel altijd eerst de Nederlandse versie. Door de hoge kosten van vertalingen kan het zijn dat deze pagina inhoudelijk achter loopt met de Nederlandse versie. Wij beschouwen de Nederlandse versie van deze pagina als leidend.
Questa pagina contiene un elenco di situazioni di eccezione alle misurazioni sulla sicurezza di base. Una misurazione senza contesto sarà giudicata negativamente. Per questo motivo, la sicurezza di base prevede delle eccezioni in base al cosiddetto processo “rispetta o spiega”.
Se manca un’eccezione, contattaci. La richiesta di eccezione verrà esaminata e potrà essere aggiunta o meno alle misure. Includi i requisiti del manuale delle buone spiegazioni.
Numeri di versione
L’aspettativa è quella di non imbattersi in informazioni che un aggressore potrebbe utilizzare per portare a termine un attacco. Quindi, in generale, non ci aspettiamo numeri di versione. Queste sono le eccezioni:
- Le stringhe SSH2.0 senza commenti sono escluse perché le informazioni sulla versione fanno parte del protocollo. Vedi www.openssh.com/txt/rfc4253.txt 4.2. Ciò significa, ad esempio, che “OpenSSH_9.2p1” è approvato ma “OpenSSH_9.2p1 Debian-2+deb12u2” no. Questo perché pubblica informazioni aggiuntive (“Debian-2+deb12u2”) sul sistema. Ciò significa che il sistema non è protetto contro gli aggressori e che un malintenzionato sa esattamente di che tipo di sistema si tratta.
- Versioni principali di prodotti famosi che non dicono nulla sul livello di patch. Come ad esempio: Microsoft IIS 8.5, Microsoft httpapi/2.0, rtc 7.0, awselb/2.0. Questi sono approvati.
Certificati
Si prevede che tutti i certificati siano emessi da un’organizzazione accreditata. Questi certificati sono poi affidabili nei browser e nei dispositivi. Queste sono le eccezioni:
- G1 Certificati governativi. Questi non sono affidabili per il browser ma lo sono per il governo centrale. Ciò è indicato da una dichiarazione. L’assenza di fiducia è stata scelta per motivi di design. Il certificato che viene accettato deve includere il numero di serie 10004001, tra gli altri.
Cancelli aperti
L’aspettativa è che la superficie di attacco sia minima, ovvero che le porte aperte siano il meno possibile. Queste sono le eccezioni a questo principio:
- 8080/8443 (Cloudflare): Il firewall di Cloudflare apre alcune porte ridondanti per impostazione predefinita, come la 8080. Puoi configurare tu stesso ciò che vi appare. Se vediamo cloudflare elencato lì, ora lo approviamo con una spiegazione. In definitiva, questo non è positivo e incoraggiamo gli utenti di cloudflare a segnalare che l’azienda dovrebbe iniziare a chiudere queste porte. Questa eccezione avviene in base al contenuto della pagina web. Viene applicato un criterio come dichiarazione.
- 8443 (VPN): i sottodomini relativi all’homeworking possono aprire questa porta. Lo riconosciamo dai sottodomini (e dalle numerose varianti di): telelavoro, homeworking, workplace, workstation, extranet, intranet, remote, remote working, vpn e così via.
Trasferimento dati criptato (HTTPS)
L’aspettativa è che i siti e i servizi web siano criptati in modo che le informazioni rimangano riservate. Queste sono le eccezioni:
- Liste di revoca dei certificati: non è necessaria una connessione crittografata sui sottodomini “pki”, “crl”, “ocsp” e alcune loro varianti. Non è necessario impostare l’intestazione HSTS sulla porta 443 (non è previsto l’https).
- Non è richiesta la crittografia sui sottodomini Microsoft Autodiscover; si tratta di un’eccezione generale per i servizi Microsoft perché altrimenti tutti sono rossi…? Questo vale per i domini “autodiscover” e “autodiscover.test”.
Intestazioni HTTP
L’aspettativa è che tutti i siti web siano impostati per la sicurezza. Queste sono le eccezioni:
- Intestazioni mancanti per i tipi di contenuto SOAP/JSON/XML: Questi servizi non sono destinati agli esseri umani e quindi non hanno bisogno di fornire la protezione del browser destinata a proteggere gli esseri umani.
- Intestazioni mancanti per i servizi tecnici: Per il sottodominio ADFS, l’intestazione HSTS non deve essere impostata.
Altro
Ci si aspetta che tutti i requisiti di sicurezza siano soddisfatti. Ci sono scenari complessi in cui questo non è ancora avvenuto o non è possibile. Queste sono le eccezioni:
- I servizi Microsoft sui sottodomini di lyncdiscover, sip, enterpriseenrollment, enterpriseegistration, webmail, msoid. Questo perché questi servizi non sono destinati ai browser ma a servizi automatizzati. Allo stesso tempo, l’impatto sarebbe stato elevato ovunque e i fornitori di servizi ICT non possono risolvere questi problemi:
- Il certificato di questi sottodomini è attendibile, nonostante non sia attendibile da Qualys.
- Poiché si tratta di servizi destinati ai dispositivi e non ai browser, le intestazioni http non sono obbligatorie.
