Andrew Hay ha recentemente contribuito, con un interessante articolo su Dark Reading, alla questione che 'Grande quantità di dati' sia un'espressione diffusa dagli agenti di vendita SIEM per attrarre l'attenzione e devo dire che sono piuttosto d'accordo sull'essenza della sua conclusione.  Gli agenti di vendita SIEM (e la gestione delle sessioni) in presenza di architetture di sistemi datate di dieci anni, dichiarano che una 'Grande quantità di dati' è quella che probabilmente essi non possono consegnare fino al momento in cui non avranno familiarità con la tecnologia e i concetti delle 'Grandi quantità di dati'.  Ma non penso che con questo la questione sia terminata.

 

Mentre i concetti delle 'grandi quantità di dati' possono essere utilizzati per analizzare qualsiasi settore, dalla finanza alle previsioni del tempo, la maggior parte di voi sarà - con tutta probabilità - più interessata al significato della situazione in cui il capo vi chiede che cosa fate a proposito della 'grande quantità di dati' (probabilmente subito dopo l'ordine, da parte dell'azienda, di un nuovo array).  Per cui, parliamone.  Una 'grande quantità di dati' in campo IT, può essere utilizzata per la gestione di problemi di sicurezza, questioni prestazionali delle applicazioni, oltre che per individuare degli aspetti del business che trascendano le tendenze di base e delle questioni operative, prima che queste diventino problemi operativi.  Tutti questi punti meritano gli impieghi della tecnologia e probabilmente il vostro tempo, ma determinare questi vari aspetti a partire da una 'grande quantità di dati' non è poi così semplice.

 

Sono due i problemi fondamentali per arrivare al valore intrinseco partendo da una 'grande quantità di dati'.

  1. È necessario raccogliere tutti questi dati, come Andrew ha evidenziato nel suo articolo su Dark Reading, laddove sono svariati i problemi presenti nei sistemi la sui struttura risale ad una tecnologia datata di un decennio.  I problemi si pongono sia in termini dei sistemi di memoria, come Andrew aveva puntualizzato (vale a dire, il database), sia in termini della struttura organizzativa utilizzata per mantenere ed analizzare i dati (vale a dire, tipo transazionale nei confronti degli schemi OLAP).
  2. È necessario analizzare e individuare i problemi, per poi automatizzare tale identificazione per il futuro. Si tratta di un punto veramente difficile, dato che la "grande quantità di dati" non è accompagnata da una "guida di assistenza", ma se ne devono immaginare i vari aspetti. È richiesto qualcuno con un'effettiva esperienza nel campo della conoscenza informatica per trovare l'ago nel pagliaio e sapere che tale elemento ha un significato per il proprio business.  Inoltre, una volta individuato, non è chiaro se lo stesso sistema utilizzato per l'analisi sarà di una qualche utilità per l'automazione e il rilevamento in tempo reale.  In effetti, è probabile che si tratti di applicazioni come minimo differenti.

 

Per molti di voi, questi due fattori possono rendere una 'grande quantità di dati' un lusso scevro di aspetto pratico ma, se proprio desiderate rendere sicura la vostra rete o se volete veramente assicurare un'elevata disponibilità, forse vorrete proseguire nella lettura.   Avrete a disposizione qualche opzione:

  • Tuffarvi: costruire un sistema basato su tecnologie di 'grandi quantità di dati', quali Hadoop e Google MapReduce, o addirittura un numero ancora maggiore di prodotti orientati alla piattaforma, quali Splunk, assumere il vostro scienziato informatico e proseguire nel cammino.  Non è impossibile: date un'occhiata a quest'analisi di studio
  • In alternativa, potrete ricercare un prodotto che vi possa fornire un certo numero di altri strumenti pratici.  Per prima cosa, assicuratevi di poter raccogliere dati sulle macchine e di agire su tali dati in tempo reale.  Se state trascrivendo i dati verso il database, rendendoli quindi disponibili ad un motore di analisi, questo non vi aiuterà a reagire con sufficiente rapidità ad una minaccia nel campo della sicurezza. Secondo punto: ottenete un prodotto che possa offrirvi alcuni strumenti di visualizzazione dei dati, fattori quali "cloud", mappature ad albero, diagrammi a bolle, istogrammi e via di seguito vi aiuteranno ad avviare un esercizio di esplorazione dei dati. Questo vi aiuterà a definire gli obbiettivi della ricerca: la ricerca IT di per sé non eliminerà questa necessità. Terzo punto: assicuratevi che la definizione di regole sia facile; nessun linguaggio di interrogazione redatto a mano, per favore, dato che siamo nell'epoca del trascina-e-rilascia.  Ultima fase: assicuratevi che il vostro sistema possa intraprendere azioni, se tutto quello che può fare non è veramente di aiutarvi ad arrestare il problema, ma semplicemente di aiutarvi a sapere che sussiste un problema: si tratta di una grande differenza.

 

La 'grande quantità di dati' è presente per restare, ma il mio consiglio è di essere pratici, se non sapete quello che volete fare in caso di arresto dei dati.  Ma, se sapete bene quello che fareste in tal caso, trovate allora una soluzione che vi procuri le parti chiave del valore, senza dover assumere il vostro scienziato informatico particolare.