Disclaimer: l'originale di questa pagina è scritto in olandese. Questa pagina è stata tradotta automaticamente in altre lingue utilizzando il sito DeepL. Ciò può comportare differenze di sfumature, tono e significato. In caso di dubbi, consulta sempre prima la versione olandese. A causa dell'elevato costo delle traduzioni, questa pagina potrebbe essere in ritardo rispetto alla versione olandese in termini di contenuti. Consideriamo la versione olandese di questa pagina come principale.
La Internet Cleanup Foundation ha un codice di condotta che stabilisce i principi di base sulle misure da pubblicare o meno.
Questa pagina approfondisce questo aspetto con esempi pratici.
Misure pubbliche con uno scopo pubblico
In linea di principio, Basic Security misura la sicurezza a livello di base. Questo può essere pubblicato liberamente senza aumentare il rischio di abusi oltre a quello che già c’è. Considera di misurare i punti in cui le misure di sicurezza comuni sono carenti.
Il database di Basisbeveiliging.nl contiene oltre 10 milioni di misurazioni uniche. Tutte le misurazioni contenute nel database possono essere pubblicate integralmente in qualsiasi momento, oppure trapelare, senza creare nuovi rischi che un aggressore possa sfruttare.
Un’organizzazione con una politica di sicurezza adeguata sarà sempre verde per quanto riguarda la sicurezza di base: le misure di per sé non sono una novità o uno shock, ma la mancanza di applicazione a volte può esserlo.
Le misurazioni della sicurezza di base rientrano nell’area dell’ethical hacking e dei test di sicurezza. Ci sono forti somiglianze con le prime fasi dei test di sicurezza professionali, come la mappatura della superficie di attacco. Si tratta di domini, porte e software. Si tratta di informazioni pubbliche che è facile raccogliere su larga scala. Ci sono molte aziende che lo fanno e lo offrono a costi molto bassi o addirittura pubblicamente e gratuitamente.
Basic Security non pubblica mai vulnerabilità gravi o critiche. Lascia questo compito ad altre organizzazioni, come le società di test di sicurezza professionali come Secura e Zerocopter o le organizzazioni volontarie come il DIVD.
Risultati pubblicabili
La Internet Cleanup Foundation pubblica informazioni sulle vulnerabilità e sulle misure di sicurezza mancanti. Lo fa con l’obiettivo di risolvere queste vulnerabilità. In base al codice di condotta, si stabilisce se una vulnerabilità può essere pubblicata. In questo caso si tiene conto dell’interesse pubblico, della proporzionalità e della sussidiarietà.
Le vulnerabilità pubblicabili sono pubblicamente disponibili per tutti sul sito web della sicurezza di base. È possibile accedervi anche in modo automatico.
Le vulnerabilità pubblicabili sono classificate in base al rischio. Si tratta di una classificazione del rischio diversa da quella comune nel mondo della sicurezza perché lo spettro delle misure è diverso. Lo spettro della sicurezza di base è composto da quattro gradi che sono scalati in base a ciò che potrebbe potenzialmente andare storto. Questo è in contrasto con i normali test di sicurezza, che contrappongono gli stessi risultati a cose che stanno realmente andando male in questo momento. Se la sicurezza di base attribuisce a qualcosa un valore “alto”, in un test di sicurezza professionale questo viene classificato come “info”, “basso” o, in un caso particolare, “medio”, a seconda dello scopo del test.
Le gradazioni sulla sicurezza di base cambiano nel tempo, per alzare lentamente l’asticella della sicurezza di base. Se quest’anno una misura è arancione, l’anno prossimo potrebbe essere rossa per attirare l’attenzione su di essa. Ad esempio, l’applicazione di security.txt non è obbligatoria fino alla metà del 2023, quindi in quel periodo non tutte le organizzazioni applicheranno questo standard. Tuttavia, entro la metà del 2024, ciò sarebbe inaccettabile perché le organizzazioni avranno avuto un anno di tempo per applicarlo. Per saperne di più, consulta la politica di misurazione.
Queste sono le quattro gradazioni che applichiamo:
Rosso: rappresenta una vulnerabilità ad alto rischio. In questo caso si tratta di un’imperfezione che deve essere risolta. Consideriamo, ad esempio, una crittografia debole. La fuga di informazioni sulla versione (che indica a un utente malintenzionato cosa eseguire) e simili.
Arancione: spesso riguarda le istituzioni e le carenze amministrative. Inoltre, nuove misurazioni che alla fine dovrebbero essere rosse, ma che vengono classificate come arancioni per essere introdotte: per rendere la misurazione visibile e perseguibile dalle organizzazioni responsabili.
Verde (basso): Una misurazione che comporta una deviazione sulla sicurezza che ha un impatto molto limitato (per ora) perché sono poche le persone che potrebbero riscontrare questo problema, e in tal caso sono spesso già esposte a una vasta gamma di problemi più gravi. Questo livello viene utilizzato anche per le misurazioni che potrebbero comportare obblighi legali in futuro, ma che oggi non sono molto comuni.
Verde (ok): Misura corretta: in questo punto la sicurezza è garantita.
I risultati sono sempre corredati da documentazione, riferimenti e, ove possibile, da un link per una seconda opinione su cui effettuare un nuovo test. Queste informazioni sono contenute anche nella politica di misurazione. In questo modo è possibile conoscere la rilevanza di una nuova scoperta e verificare immediatamente che la vulnerabilità sia stata risolta.
Esempi di vulnerabilità pubblicabili sono: crittografia mancante, DNSSEC mancante, security.txt mancante, posizione fisica del servizio, applicazione di RPKI, informazioni sulla versione pubblica.
Tutte le informazioni contenute nei siti web, comprese le misure, sono soggette al nostro disclaimer. Pertanto, agire in base a queste informazioni è sempre a tuo rischio e pericolo. Facciamo del nostro meglio per pubblicare sempre misure corrette e aggiornate; per saperne di più, consulta la politica sulle misure.
Come vengono pubblicate le nuove misure
Prima che una nuova misurazione venga pubblicata, viene annunciata alle organizzazioni di riferimento in modo che queste possano intervenire. A quel punto, i risultati della misurazione stessa spesso non sono ancora perspicaci. Almeno un mese dopo, la misurazione diventa visibile e pubblica.
Seguirà un periodo di prova durante il quale la misurazione sarà valutata al massimo arancione. Durante questo periodo di prova, tutti possono reagire alla misurazione e quest’ultima può essere resa più severa. Questo periodo di solito dura un mese o due. Al termine di questo periodo, la misurazione viene ridimensionata ed eventualmente impostata su rosso.
Esempio di scenario di vulnerabilità pubblicabile
Un’organizzazione ha bisogno di un sito web. Il sito web viene realizzato da un’agenzia di sviluppo. Questa agenzia di sviluppo utilizza un software standard e si concentra principalmente sulla funzionalità e sulle informazioni.
Il sito sta per essere pubblicato, ma la sicurezza non è ancora stata affrontata. Ad esempio, il sito non è ancora accessibile tramite una connessione criptata (1: https), non ci sono garanzie sull’appartenenza del nome di dominio all’indirizzo ip del sito (2: DNSSEC) e c’è un pannello di gestione pubblico (3: pannello di login) che mostra che si tratta della versione software 7.0.2 (4: informazioni sulla versione).
Questo caso offre all’aggressore ogni tipo di appiglio che può essere facilmente evitato. Un aggressore ha bisogno di uno sforzo minimo o nullo per trovarli e ha automatizzato a lungo e ampiamente questa conoscenza per fare il maggior numero di danni possibile in questo modo.
In questo caso di studio, un aggressore può sfruttare le vulnerabilità nei seguenti modi: può leggere insieme al traffico Internet sulla stessa rete come un hotspot Wi-Fi perché manca l’https (1: https), sulla stessa rete l’aggressore può reindirizzare il traffico a una pagina falsa (2: dnssec), si può tentare di accedere alla pagina di gestione in qualsiasi parte del mondo (3: pannello di login) e cercare e applicare vulnerabilità pubblicamente note in qualsiasi parte del mondo (4: informazioni sulla versione).
Gli aggressori dispongono già di queste informazioni, quindi è importante che le abbiano anche le persone che devono difendersi. In tutti questi attacchi, c’è una base di apertura e di buona professionalità.
Quando i framework e gli standard di sicurezza conosciuti vengono seguiti con competenza, tutte queste vulnerabilità non sono presenti. Pensa a ISO27002, NEN7510, Baseline Information Security Government e simili. Si noti che questi framework non sono pratici e lasciano che ognuno misuri e misuri le proprie soluzioni. Di conseguenza, nella stessa situazione, un principiante scriverà un piano diverso in termini di contenuti rispetto a un professionista. Per quanto riguarda la sicurezza di base, stabiliamo una certa soglia che è rilevante in tutti i casi. Per alcuni questa soglia è troppo alta, per altri è troppo bassa. In ogni caso, è la base.
Vulnerabilità non pubblicabili
La sicurezza di base si concentra sui requisiti di sicurezza fondamentali.
Anche i volontari della Fondazione a volte trovano gravi vulnerabilità. Si tratta di un sottoprodotto e non dell’obiettivo della fondazione. Ecco come ci comportiamo. Le ricerche attive di vulnerabilità gravi vengono effettuate dall’organizzazione amica DIVD. Quindi la sicurezza di base non cerca mai attivamente vulnerabilità gravi.
Nel caso in cui dovessimo accidentalmente trovare una grave vulnerabilità, ecco come affrontarla.
Quando si sospetta una grave vulnerabilità, viene preso in considerazione, caso per caso, l’approccio che garantisce la massima sicurezza nel più breve tempo possibile. Vengono prese in considerazione diverse opzioni:
- Se si tratta di una nuova vulnerabilità non ancora nota (non un CVE), ci sono diverse opzioni. Dipende da dove è stata identificata la vulnerabilità e dalla sua gravità. Vengono presi in considerazione i seguenti percorsi:
- Consegnalo all’Istituto olandese per la divulgazione delle vulnerabilità. Loro hanno l’infrastruttura per identificare le vittime di questa vulnerabilità e avvisare della fuga di notizie. Questa azione è la nostra opzione preferita.
- Quando il creatore del software ha un processo di divulgazione coordinata delle vulnerabilità, questa vulnerabilità viene trasmessa direttamente al creatore. Questo avviene solo quando è possibile farlo in modo riservato.
- Le regole di base per la divulgazione coordinata delle vulnerabilità vengono applicate per notificare la parte vulnerabile.
- Quando si tratta di una vulnerabilità nota, vengono seguite le regole di base per la divulgazione coordinata delle vulnerabilità. Si esamina se l’organizzazione dispone di un processo di questo tipo.
- Se non esiste un processo di CVD, viene contattata l’organizzazione di sicurezza a cui appartiene. Si tratta, ad esempio, del Servizio di Sicurezza Informatica per i Comuni o del Centro Nazionale di Cyber Security per il governo nazionale.
- Si sta valutando la possibilità di inoltrare la segnalazione attraverso la linea diretta per la sicurezza.
- La comunicazione relativa alla vulnerabilità grave sarà considerata in base alle regole di base della CVD. Poiché trovare e pubblicare nuove vulnerabilità non è il nostro obiettivo, la comunicazione sulle nuove vulnerabilità, se mai avverrà, avverrà probabilmente attraverso la parte a cui è stata segnalata, la Hotline di sicurezza, il DIVD o un’organizzazione simile.
Esempi di vulnerabilità non pubblicabili sono: SQL injection, cross-site scripting, utilizzo di password deboli, password trapelate, esecuzione di codice remoto, buffer overflow e CVE.
Esempio di scenario di vulnerabilità grave
Questo esempio si basa su uno scenario reale e su una vulnerabilità nota: la disabilitazione di un modulo che rendeva i file contenenti password direttamente leggibili sulla prima pagina di un sito (disabilitando PHP). Si tratta di un errore di configurazione.
Un volontario sta consultando le informazioni su basicsecurity.it. Il volontario vede un sito: “oud.belangrijkeoganisation.nl”, che potrebbe quindi avere una sicurezza debole. Il volontario si interessa e visita il sito.
Quando si visita il sito, sembra che qualcosa non vada nella configurazione: si vede il codice sorgente del sito, invece di un bel sito web. Questo codice sorgente contiene la password di un database e link a file sensibili.
Il volontario sa che non è questa l’intenzione e si consulta con gli altri volontari su cosa sia più saggio fare. Si tratta di una vulnerabilità individuale e nota, le regole del CVD vengono seguite.
Il volontario contatta l’organizzazione di sicurezza appartenente al sito web. Le informazioni sulla vulnerabilità vengono scambiate e l’organizzazione segue i processi interni associati alla CVD e alla risoluzione delle vulnerabilità.
L’organizzazione ha risolto la vulnerabilità in tempi prevedibili. A volte l’organizzazione sceglie di ricompensare il reporter con un premio o con l’inserimento nella hall of fame.