La prevenzione fa perno sul database

Gli analisti di Yankee Group ne sono certi. Il Security event management non è solo l’ultimo acronimo in materia di sicurezza, ma una necessità delle imprese moderne. E poggia sull’Rdbms per centralizzare le informazioni e garantire un approccio “intelligente” alla sicurezza.

Un database della sicurezza per ridurre i rischi e migliorare l’accessibilità ai dati. Si tratta di un nuovo approccio alla protezione, che permette alle organizzazioni di normalizzare e correlare tutti gli eventi (attacchi, tentativi di intrusione o altro) e i log che si generano dai diversi dispositivi di sicurezza utilizzati (come firewall o sistemi di prevenzione delle intrusioni). Questo permette ai responsabili It di centralizzare la gestione di tutti gli apparati, riducendo il numero di falsi positivi e falsi allarmi, immagazzinando le informazioni relative. In realtà, questo comporta un incremento esponenziale di storage ma si tratta di procedure che, spesso, sono ormai obbligatorie per legge.

Benefici consistenti


Le imprese dovrebbero, tuttavia, valutare i benefici offerti dal Sem (Security event management) per il governo delle proprie infrastrutture It. Questo approccio sembra stia guadagnando consensi, almeno stando a Yankee Group. L’analista stima che, per l’anno in corso, il giro d’affari mondiale legato al Sem si attesterà intorno ai 330 milioni di dollari con ampie prospettive di crescita in futuro. In realtà, questo approccio distingue due diverse tecnologie, una che si focalizza sull’identificazione delle minacce e sul tentativo di rispondere efficacemente alle stesse; l’altra che si specializza sulle esigenze di supervisione e reportistica. A queste si affiancano ulteriori requisiti nel caso in cui si vogliano perseguire obiettivi di presidio delle minacce interne. Ciascuna di queste esigenze richiede un approccio diverso all’immagazzinamento e richiamo dei dati. Nel caso della risposta agli incidenti, occorre predisporre degli agenti in grado di normalizzare (cioè rendere omogenei) correlare e filtrare gli eventi prima che questi vengano inseriti all’interno dei database. La correlazione in tempo reale avviene sulla memoria, perché le query sui database generano latenze. Questo significa che occorrerà sfruttare l’intelligenza dei dispositivi e degli agenti, così che il sistema sia in grado di rispondere prontamente, cosa questa che è sicuramente apprezzabile nel caso in cui l’obiettivo sia di reagire prontamente alle minacce ma che risulta non ottimale per le attività di reportistica. Infatti, proprio in virtù del fatto che i dati sono filtrati prima del loro inserimento nel database, è più facile che vengano "smarriti". Le necessità di uniformarsi agli obblighi di legge dovrebbe far propendere, al contrario, per un sistema che preveda il non-filtraggio a priori delle informazioni. Questo, però, renderebbe lungo il processo di richiamo (query) dei dati, cosa non ammissibile se si vuole utilizzare il sistema per rispondere rapidamente alle minacce.

I colli di bottiglia


Si tratta, quindi, di esigenze contrastanti, specie se si tiene conto dei limiti dei database relazionali. Anche nelle migliori condizioni, infatti, sono in grado di gestire al più 1.000/2.000 inserimenti al secondo. I dispositivi di protezione utilizzati in azienda generano, invece, decine di migliaia di eventi al secondo e il database finisce, quindi, per diventare il collo di bottiglia di tutto il sistema. Inoltre la maggior parte dei dati relativi alla sicurezza (come i file di log) sono file di testo o, in generale, file destrutturati che un database relazionale non è in grado di gestire al meglio. L’esplosione dei dati potrebbe portare all’incremento dei costi di questi sistemi, legati allo staff tecnico e alla necessità di consolidare in data warehousing le informazioni sparpagliate tra i diversi database, allo scopo di costituire un valido supporto alle esigenze di analisi (come illustrato in figura).

LASCIA UN COMMENTO

Inserisci il tuo commento
Inserisci il tuo nome