Scansione di sicurezza da alcuni avvisi aziendali su diversi problemi non esistenti. E ancora peggio: i loro risultati non sono coerenti. Come gestisci queste cose? Solo due esempi:
Solo perché una scansione automatica restituisce un risultato, ciò non significa che sia un 'controllo'. È solo una scansione.
Per qualsiasi risultato, deve essere
Ai fini della documentazione, è una buona idea annotare queste 4 cose in modo che i risultati futuri possano essere confrontati e le giustificazioni, le attenuazioni e i rischi possano essere rivisti in futuro per assicurarsi che rimangano rilevanti.
Quindi, per i tuoi due risultati, riconosci che il modulo esiste ma non pone alcun rischio perché non è attivo e conferma entrambi i risultati su entrambi i server come veri o no (ci sono tutti i tipi di motivi per cui una scansione mostra risultati diversi sulla stessa configurazione)
Ho un problema con il tuo uso del termine "falso positivo"
alerts for Apache mod_lua module even when this module is not active
Non attivo? Cosa significa? Se non hai bisogno di mod_lua, i file .so non dovrebbero essere sul filesystem a meno che tu non possa rimuoverli senza rompere qualcosa. Se il tuo server web sta caricando il modulo ma non lo sta usando, allora questo è un problema che dovrebbe essere risolto.
alerts for different things on two webservers with identical configuration
O i sistemi che pensi siano identici non lo sono, o forse la società di scansione non sta facendo il proprio lavoro nel modo giusto. Il primo non è difficile da controllare.
Anche se sei assolutamente convinto che la compagnia che fornisce questo servizio sia inutile cowboy, il tuo primo punto di riferimento è quello di assicurarti di avere una solida base per confutare i risultati.
Innanzitutto, le scansioni di sicurezza sono solo strumenti automatici. In quanto tali, i falsi positivi sono piuttosto comuni.
Ogni vulnerabilità segnalata dovrebbe essere analizzata, il che significa che un analizzatore umano dovrebbe prima confermare che ha senso, quindi valutare il livello di rischio e infine definire la riparazione appropriata con la giusta priorità. Questa analisi deve considerare il contesto tecnico e funzionale.
In realtà, i falsi positivi sono facili da gestire in quanto dovrebbero essere semplicemente eliminati nella prima fase dell'analisi. Alla fine la difficoltà è confermare piuttosto questo è un falso positivo oppure no. Si noti che è possibile affrontare problemi simili con i veri-postivi, ad esempio immagina che una vulnerabilità di divulgazione di informazioni sia giustamente riportata ma che riguardi solo informazioni pubbliche - il che significa che il livello di rischio è intorno a zero. Si noti inoltre che i falsi positivi o i rischi nulli possono evolversi in termini di tempo e contesto: il modulo vulnerabile disabilitato potrebbe essere attivato in un secondo momento, le informazioni sensibili potrebbero essere archiviate e quindi la vulnerabilità della divulgazione diventa improvvisamente sensata.
Quindi, un modo per gestire i falsi positivi consiste nel registrarli per semplificare le future analisi dei risultati della scansione. Ma, in ogni caso, l'analisi umana è l'unico modo per avere una valutazione completa dei rischi. Evitare sistematicamente il tipo di vulnerabilità.
Il punto è probabilmente quello di segnalare la decisione riguardo alle vulnerabilità segnalate: se sono false o vere e positive e perché, livello di rischio valutato, rimedi da intraprendere. I miglioramenti della sicurezza iniziano con un'analisi appropriata.
Vedo i punti di entrambi schroeder e symbbean. Questo è quello che ho discusso con i clienti negli ultimi 15 anni circa.
Solo perché lo scanner delle vulnerabilità dice che qualcosa è vulnerabile, non significa necessariamente che lo sia. Lasciami spiegare.
Nel tuo esempio, gli avvisi su mod_lua sono molto probabilmente basati sulla versione di Apache installata e non sul rilevamento effettivo di mod_lua caricato in memoria. Al meglio, sa che il modulo è installato e caricato in memoria. Tuttavia, la tua applicazione web effettivamente la usa?
Un grosso problema è che la maggior parte degli scanner di vulnerabilità sul mercato fornisce poche informazioni sul metodo di rilevamento, per non parlare dell'effettiva evidenza.
Anche se questo spiega perché hai dei potenziali falsi positivi, non risolve il tuo problema. Onestamente, se questi sono i server della tua azienda, spingere per eseguire una scansione delle vulnerabilità con credenziali. Avrai dati molto più precisi su cui lavorare.
Quindi, cosa succede se esegui una scansione credenziale e vedi ancora la vulnerabilità mod_lua?
Una parte del programma di gestione delle vulnerabilità deve includere l'utilizzo della metodologia di valutazione del rischio per valutare se è necessario attenuare (correggere) o accettare il rischio di tale vulnerabilità.
Che cosa succede se non si dispone di una metodologia di valutazione del rischio?
Lo fai ... lo fanno tutti. Potrebbe non essere documentato e l'intera azienda potrebbe non condividere la propria metodologia, ma intrinsecamente, si prendono decisioni basate sul rischio ogni giorno. Se la tua azienda non ha un programma di valutazione / gestione del rischio formale, suggerirei ai superiori che è un risparmio di tempo e denaro. Se strutturato bene, impone ciò che viene affrontato e in quale ordine.
Torna a mod_lua. Se mod_lua è sul server, aggiorna. Meglio ancora, se il sito web non usa il linguaggio di scripting Lua, rimuovi il modulo dalla configurazione di Apache e mod_lua.so dal server.
Leggi altre domande sui tag audit