Il cliente richiede la gestione delle vulnerabilità secondo gli standard BSI: cosa dobbiamo implementare concretamente in Germania?

I team piccoli di solito si fanno prendere dal panico quando sentono la parola BSI e si perdono nelle centinaia di pagine delle linee guida IT-Grundschutz. Il cliente molto probabilmente non intende una certificazione completa, ma una prova documentata dei processi operativi da mostrare in caso di audit. Se nel contratto non c'è l'obbligo esplicito di ISO 27001 o certificazione BSI fornite semplicemente la documentazione dei processi e i report di scansione, senza bruciare tutto il budget.

Per semplificare il lavoro sul fronte tecnico, integrate scanner continui per le dipendenze open source e strumenti di scansione delle vulnerabilità a livello di server. Se configurate un webhook che trasforma direttamente i record CVE in ticket, il sistemista non dovrà più gestire elenchi manuali. I revisori BSI controllano quasi sempre la presenza di server ombra non scansionati: assicuratevi di includere nel perimetro tutte le macchine secondarie del dominio.

In un progetto pubblico simile abbiamo acquistato una licenza per uno scanner di vulnerabilità a 2.200 EUR all'anno. La configurazione del sistema ci ha richiesto 3 settimane. Il nostro sistemista dedica 2 ore ogni lunedì a controllare le comunicazioni di BSI e CERT, e 6 ore al mese per la stesura dei report. Grazie a questa routine abbiamo superato gli ultimi due audit dei clienti con zero rilievi.

La cosa più rapida che potete fare già da domani: 1) Mettete giù in una tabella chiara la lista dei vostri server e delle librerie. 2) Iscrivetevi alla newsletter gratuita via email di CERT-Bund. 3) Scrivete una Policy di Sicurezza di due pagine che indichi le tempistiche di patching e fatela firmare internamente in azienda. Quando il cliente verrà a fare l'audit, sarà la prima carta che vi chiederà.

Ci siamo trovati davanti alla stessa richiesta per un bando su un software sanitario simile a Monaco di Baviera. Al primo audit ci hanno chiesto: "Quanto tempo ci avete messo a chiudere una vulnerabilità critica del kernel uscita il mese scorso, e dove sono i log?". Noi avevamo rilasciato la patch in produzione in 4 ore, ma ci siamo beccati un richiamo perché non avevamo aperto il ticket e registrato gli orari. Il vero segreto sta tutto nel tracciare correttamente i log.

Nel capitolato il vostro cliente fa riferimento esplicito al modulo BSI IT-Grundschutz OPS.1.1.3 (Patch- und Änderungsmanagement)? Se questo modulo è un requisito obbligatorio, dovete collegare la gestione delle modifiche (Change Management) al processo di approvazione delle patch.

ci siamo passati pure noi, mettete dei bot automatici di scansione vulnerabilità sul repo git. che controllino le librerie a ogni build. basta anche solo un diagramma di flusso che dimostri che non mandate nulla in prod se non è tutto verde in ambiente di test per convincere il cliente.

Essendo il vostro cliente legato al settore pubblico, è obbligato a garantire la conformità agli standard BSI anche nel contratto di subappalto. La documentazione da preparare deve includere una matrice di responsabilità (RACI), la procedura di patching di emergenza e l'impegno per un audit esterno annuale. È fondamentale che questi documenti siano approvati dalla direzione aziendale.

Bisogna fare una distinzione qui. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

È tutto, scusate se mi sono dilungato.

Come avete risolto questo? Il vero problema non è il numero, ma su cosa si basa quel numero.

Scusate, ma questo non vale in ogni caso. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Buon lavoro.

Ho lavorato a lungo su questo. Chiunque abbia fretta su gestione delle vulnerabilità bsi si blocca nello stesso punto.

Mi farebbe piacere se scrivesse il risultato. Inizia con un piccolo test, non impegnarti subito su tutto.

Lascio una nota, potrebbe servire.

Ti seguo.

C'è una parte che non ho capito. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Buon lavoro.

Esattamente così. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Se scrivete qui il risultato, sarà utile anche ad altri.

La discussione si è dispersa, la riassumo. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

La risposta varia molto in base al settore, non esiste una regola generale. Spero che le sia utile.

Ha ragione. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Un report di scansione automatica e un penetration test non sono la stessa cosa. onestamente se scrivete qui il risultato, sarà utile anche ad altri.