Alcuni venditori vendono sistemi che funzionano come te descrivi. Il problema più grande è la mancanza di una cooperazione attiva da parte dei venditori; non esiste un modo affidabile per creare un elenco di hash di "binari consentiti" poiché:
-
Ciò che appare come "un'applicazione" dal punto di vista dell'utente può essere un insieme di molti file eseguibili (in larga misura, è quello che sono le DLL).
-
Qualsiasi aggiornamento software interromperà i valori hash e richiederà di ricalcolarli. Questo è soprattutto un problema con le applicazioni che si aggiornano automaticamente su base giornaliera (come è tipico di alcuni moderni browser Web).
-
Alcune applicazioni si basano su generazione al volo di file eseguibili, ad es. per ottimizzare le cose per quanto riguarda l'hardware locale (penso che Adobe Reader lo faccia). Si noti inoltre che il framework .NET viene fornito con un compilatore C # ( csc.exe ) e che il processo di compilazione può essere richiamato a livello di codice (questo è ciò che alimenta le pagine Web ASP.NET ed è piuttosto mainstream).
Quindi, in pratica, i sistemi che funzionano in questo modo sono accoppiati con una fase di apprendimento (dove vengono raccolte informazioni su quali file vengono eseguiti da un determinato utente in un "giorno tipico"), eccezioni esplicite per casi angolari e un processo semplificato mediante il quale l'utente può richiedere l'aggiunta di una determinata applicazione alla whitelist.
Tieni presente che se applichi un sistema del genere, i tuoi utenti ti odieranno a fondo, perché sentiranno che si tratta di un'intrusione intollerabile nel loro mondo privato. L'odio degli utenti ha i suoi costi, in termini di sicurezza (la sicurezza funziona molto meglio quando gli utenti collaborano volentieri), quindi è meglio controbilanciare un guadagno netto dal sistema di whitelist.
Inoltre, considera che il malware non è necessariamente un file .exe o .dll. Il virus macro di Word è un esempio ben noto.