Articolo da Dossier On Demand del 03 e dell'08 giugno 2010

Ecco i documenti per la sicurezza che le organizzazioni devono aggiornare e verificare

Ecco i documenti per la sicurezza che le aziende devono aggiornare e verificare periodicamente Le procedure di sicurezza che le aziende dovrebbero adottare e verificare periodicamente sono, come noto, elencate e regolate dal DPS (Documento Programmatico sulla Sicurezza) che è stato a suo tempo un tormento per tutti gli IT Manager e per questo motivo molto spesso è stato quasi rimosso dagli impegni professionali obbligatori per legge. Questo deve essere aggiornato periodicamente ed in particolare con le disposizioni rilasciate alla fine dello scorso anno. A parte quanto prescritto e richiesto dal DPS, la sicurezza in ogni caso richiede un processo d'aggiornamento continuo che necessita di essere supportato da precise documentazioni sulle procedure e modalità operative introdotte nel tempo per assicurare la protezione delle informazioni essenziali per il business svolto dall’impresa. Ecco le documentazioni che, secondo gli esperti, non dovrebbero mancare in ogni azienda che vuole competere seriamente sul mercato: - Settore crittografia e mantenimento dei dati in forma crittografata: una documentazione deve definire in che modo sono protetti la riservatezza e l'integrità dei dati all'interno delle applicazioni. - Procedure di amministrazione e monitoraggio dei sistemi aziendali: un documento deve definire gli step necessari alla corretta amministrazione ed al monitoraggio di tutti i sistemi aziendali nei quali sono contenuti dati di natura critica (ad esempio di tipo personale, finanziario, etc..). Una corretta gestione degli asset può agevolare la rapida identificazione di situazioni anomale e salvaguardare lo stato dei dati. - Procedure di backup aziendali: un’apposita documentazione deve definire quali procedure sono in essere per il backup e secondo quali tempistiche. Il documento deve anche specificare le procedure per il ripristino dei dati e quali criteri permettono di candidare un sistema per il processo di backup. - Procedure d'aggiornamento: un documento deve dettagliare quali sono le procedure d'aggiornamento dei sistemi e delle applicazioni. La presenza di software obsoleto o non aggiornato rappresenta ancora oggi una delle cause principali d'accesso non autorizzato ai dati. - Policy di sicurezza & hardening dei sistemi aziendali: un documento deve definire le regole, le misure di hardening e le impostazioni di base inerenti la sicurezza, da applicare ai sistemi aziendali secondo lo specifico livello di criticità. Policy fallate già nelle fondamenta rischiano di compromettere pesantemente la sicurezza di tutta la struttura informativa aziendale. - Procedure d'analisi dei file di log generati dai sistemi di sicurezza aziendali: le informazioni generate dai sistemi di sicurezza, dai server e delle applicazioni che ospitano dati di livello critico, devono essere periodicamente controllate. Questo documento deve pertanto definire le procedure, le modalità ed il perimetro entro cui tali analisi sono espletate. - Procedure cautelative di post intrusione: questo documento deve definire le misure ed i piani cautelativi da applicare a salvaguardia dello stato della rete e dei dati aziendali, a seguito del rilevamento di intrusioni o attacchi informatici. E' importante riprendere quindi in mano periodicamente queste documentazioni sia allo scopo di aggiornarle sia per valutare le attività da svolgere per migliorare la sicurezza complessiva dei dati e delle procedure del sistema informativo aziendale indipendentemente dal fatto che si effettuino operazioni automatizzate oppure manuali. Le aziende che fossero interessate al download gratuito di ulteriori articoli e informazioni su questo tema possono accedere al portale “Security” (link sottostante) dove sono presenti articoli, news specifiche del settore e atti dei Convegni Duke Italia, tra cui l’ultimo dello scorso mese. http://security.duke.it/

Guida al Disaster Recovery

Per comprendere l'importanza di ciò di cui andremo a parlare, quando vi troverete nel vostro CED provate a guardarvi intorno ed immaginate che niente sia a voi disponibile, solo i computer: se il vostro compito fosse quello di recuperare il più presto possibile la maggior parte del lavoro eseguito precedentemente, che è però andato perduto, che cosa fareste? Il solo riflettere su questa problematica costituisce il primo passo nel processo di un disaster recovery: tale processo rappresenta la capacità di rendere nuovamente operative e disponibili tutte le funzioni delle macchine presenti nel centro dati dell'azienda, nel modo più veloce possibile. Per Disaster Recovery (brevemente DR) si intende l'insieme di misure tecnologiche e processi organizzativi atti a ripristinare sistemi, dati e infrastrutture necessarie all'erogazione di servizi di business a fronte di gravi emergenze (incendi, allagamenti, furti, attacchi di virus, guasti hardware, errori umani ecc...). Sono disponibili in rete i dati di una recente ricerca per capire se e come i dipartimenti IT siano in grado di affrontare eventi disastrosi, ovvero come gestiscano il Disaster Recovery. Il campione è costituito da IT Manager direttamente responsabili della gestione delle strategie di Disaster Recovery all'interno di grandi aziende italiane. I dati emersi (su fonte Veritas Software) sono: - il 91% delle aziende italiane rivede periodicamente i propri piani di Disaster Recovery; - ben il 48% delle aziende interpellate ha ammesso di essere stata costretta a rivedere la propria strategia di Disaster Recovery in seguito a un attacco di virus; - il 43% vi è stato invece indotto dal verificarsi di un evento disastroso; - messi di fronte all'ipotesi del verificarsi di un evento avverso, il 52% degli intervistati ha dichiarato di non essere in grado di indicare il tempo necessario per riprendere le proprie normali attività di base. Allo stato attuale, la tecnologia offre la possibilità di realizzare varie soluzioni di continuità e Disaster Recovery, fino alla garanzia di fatto di un'erogazione continua dei servizi IT. In pratica i dati ed i sistemi considerati vitali vengono ridondati in un sito secondario (detto anche “sito di Disaster Recovery”) per far si che, in caso di eventi che compromettano l'operatività (terremoto, inondazione, attacco terroristico ecc...) tale da rendere inutilizzabili i sistemi del sito primario, sia possibile trasferire la normale operatività sul sito secondario al più presto e con la minima perdita di dati possibile. Chiaramente quanto più stringenti saranno i livelli di continuità tanto più alti saranno i costi di implementazione della soluzione. In particolare, i livelli di servizio sono usualmente definiti dai due parametri: 1. RTO = Recovery Time Objective. In un sistema di analisi di Business Critical (ad esempio implementazioni di politiche di Disastery Recovery nei Sistemi Informativi) il Recovery Time Objective, in un determinato sistema o processo organizzativo, rappresenta il valore, inteso come tempo disponibile, per il pieno recupero dell'operatività del sistema o del processo. 2. RPO = Recovery Point Objective. In un sistema informativo che implementa politiche di Disaster Recovery il Recovery Point Objective quantifica l'entità massima della perdita di dati che può essere subita seguito di un evento critico. Il dossier completo (7 pagine in formato pdf) a cura di Giuseppe Moschese può essere liberamente scaricato nella rubrica “In Primo Piano” – quinta posizione – del portale “Continuità, Alta Disponibilità” al link sottostante. http://continuity.duke.it/